Recently i was asked a question about how we can successfully transform a team & become successful with using Scrum framework. Here is my experience & learning so for in transforming teams to scrum and also become successful in adapting scrum framework.
1. The Team tries to build a [potentially] shippable product every Sprint, starting with the first Sprint – Scrum is all about delivering product each and every Sprint. Any outcome offered by a Scrum Team that does not meet this objective should be considered a failure. I tend to view this type failure more as a learning opportunity, or a challenge, for the Scrum Team (and the organization) to figure out how we can get one step closer to that objective, rather than the means to punish people. In most cases, people are doing their best they can within the constraints of the business and it is the environment that gets in the way of this goal. Consistently I have found that Scrum tends to “stall out” when the business leaders are not committed to the process and fails to offer the Scrum Team what it needs to be successful. However, if we do not hold the Scrum Team (and the organization) accountable to deliver product at the end of each Sprint, even the very first Sprint, then lots of environmental factors that inhibits the delivery of potentially shippable product are allowed to remain. Always deliver something of value that can demonstrated at a Sprint Review no matter how small.
2. The Product Owner prioritizes – this one is really obvious, but I am surprised how often this can be troublesome for organizations starting up with Scrum. Scrum works best when the roles are fully inhabited and committed to by the participants and the business. IME, when the roles are weak, Scrum is mediocre at best and is on its way to “stall out”. The Product Owner role is the most important role in Scrum and the most difficult. It requires a great deal of knowledge and experience about how the business operates, an understanding how the product benefits the business and an awareness of the overall business trends that shape the product direction. In the beginning, it is unusual that one person will know all this information and the Product Owner should seek out Stakeholders for this input. While anyone can give the Product Owner advice on the priorities, in the end the Product Owner must have the final say on the business priorities to support their accountability and focus on inhabiting their role in Scrum. If someone else is allowed to have that final say, then in reality that person is the Product Owner, not the person doing the job or who has the title. There is only one Product Owner for the Team – everyone else is a Stakeholder.
3. Clear goals are set for each Sprint – a Scrum Team exists to deliver new value and capabilities to the business. If a Scrum Team is not providing new value to the business, it should be disbanded and the staff assigned to other more valuable efforts. The sad reality is that in many organizations, they do not have the courage to cancel a Team when the time is right and fail to offer clear goals and objectives. The common result is that Scrum Teams just “do stuff” until they “stall out”. For me the Sprint Goal – a concise, one to two sentence summary, in the language of the business, that unites all of the work the Team is doing – is absolutely essential for Scrum. For Team members, the Sprint Goal explains why the work they are doing is valuable to the business and offers greater opportunities to contribute beyond their functional duties. For Stakeholders, the Sprint Goal helps them understand how the Team contributes to the success of the organization and when the Team needs their feedback and participation. If the Product Owner cannot define the Sprint Goal they either have not thought out what they are trying to accomplish with the product or we have reached the end of the life for the Scrum Team. Do not begin Sprint Planning until the Product Owner has defined a clear, easy-to-understand Sprint Goal.
4. The Sprint timebox – again this is another really obvious constraint, but I find lots of mushy and\or porous boundaries between Sprints. Just to reiterate, a timebox is a fixed increment of time that neither expands nor contracts. In Scrum, it can be as short as a week and as long as 30 days. A key breakthrough in the adoption of Scrum in an organization is when people start “to get real” about what can be accomplished with the resources available and time allotted. This only happens when the Scrum Team finally has the courage to stop telling the business what they want to hear and ask them to make choices based on empirical data, i.e. the progress to date of the Scrum Team. The timebox supports these new behaviors in two ways. One, the Scrum Team and the Stakeholders get into a regular rhythm of communication, feedback and inspect-and-adapt. While the outcomes of Scrum may not be predictable, the touch points and opportunities to make adjustments are predictable. Two, the timebox asks the Scrum Team to make a commitments to deliver the Sprint Goal before the end of the timebox. This commitment is not pushed onto the Team by the Stakeholders, but a commitment the Team makes based on the available information at the time of Sprint Planning. At Sprint Planning, the Stakeholders review how close the Team came to meeting the Sprint Goal or not. If we keep extending the timebox by “just another day or two”, the Team will never learn what is their true capability to deliver. Never extend the timebox – when it is over, it is over.
5. Full time participation - in order to achieve the higher levels of productivity and quality many organizations are seeking with Scrum, businesses need to stop splitting people up across multiple projects at the same time. While it is easy to say someone is working on multiple projects simultaneously, the reality is there are probably just working on one or two (normally the ones they like the best) and waiting around for something to happen on the remaining efforts. If you are OK with your technical people deciding priorities, then go ahead and let them be on multiple efforts simultaneously. The rule in Scrum is that you are 100% dedicated to one Scrum Team. When I share this in class, the more courageous participants tell me, “That will never work in my organization. We have people on two or three projects at once.” My response, “Great – then don’t do Scrum. Clearly, whatever way things are organized in your business gives your the outcomes you desire. If are you are not satisfied with the way things are working out, then you might want to look at this idea later because this helps improve quality, productivity and throughput.” When confronted by this same issue when working with clients, I tell them there is no point in starting a Scrum Team unless at least 80% of the Team members are 100% dedicated. If we cannot get 80% of the people at 100%, then clearly there are other priorities in the business more important than Scrum.
6. A team small enough that everyone can keep track of each other - in textbook Scrum, your team size can range in size from 6 to 10 plus\minus 2 or from 4 to 12 people. In both cases, we do not count the ScrumMaster and the Product Owner. The best Scrum Teams I have ever worked with had five to six people.People gain a great deal of satisfaction and comfort by mastering a skill or technology and that is good. However, specialization often brings a lot of jargon which can inhibit communication which is normally not our goal with Scrum Teams. I find when the Team is smaller, their is less specialization and people tend to comprehend what all the other members of the Team are doing since the work is accessible to everyone. Sometimes they can give each other advice or offer help if they have free cycles.
7. No “my work” vs. “your work”, its our work - an important evolution with Scrum Teams is an understanding that members are evaluated and judged based on their performance as a Team. Yes – we want people to deliver technical excellence and make an impactful contribution, but not at the expense of the greater Team performance. The idea is not to reduce everyone’s contribution to the level of the lowest performer(s), but to raise EVERYONE’S contribution through peer-to-peer mentoring and cross-training. When some members of Team consistently kick ass, but other members are regularly struggling, which causes the Team to miss their deliveries, we have a real problem. If members of the Team are struggling, the entire Team has the responsibility to figure out how to help that person. Just because one person does all the work they signed-up for is not enough anymore. This is why we ask entire Team to commit to the Sprint Goal in Sprint Planning – the work of a Team member is not done until the Sprint Goal is complete. At Sprint Planning, the Team commits to delivering the Sprint Goal, not the tasks nor the estimates.
8. We work together in a Team room – when I start working with a client, I like to walk around the office space, met the Team members, observe their environment and ask them what they would like to achieve with our time together. For this one client, I noticed I was walking from here-to-there and then there-to-here and so on. I was walking a lot! When I sat down with my client at the end of the day, the very first thing I said was, “The number one thing you can do to ensure this project delivers on time is to have everyone sit together.” The next day, the entire Team were all sitting next to one another. Ideally, we would like a specially designed Team space and I can make Scrum work well in cube farms. Teams that are distributed just suck and are a fact of life in the 21st century.
9. Resolve Team internal issues within the Team - when I teach Scrum, I make the distinction that the Team is self-organzing and owns the solution and within the Team they are self-managing. Self-organzining means that within the boundaries and the constraints of the business, the Team can has the most freedom and latitude to create a solution that they feel meets the customer’s needs best. In their day-to-day interactions with one another, figuring out who does what and when, making decisions and how they resolve conflict, the Team is self-managing. In other words, it is up to the Team to decide all of the day-to-day decisions that affect the creation of the product. As a leader in the process, the ScrumMaster helps the Team in the early stages of self-management by facilitating, encouraging dialogue and assisting in conflict resolution. Over time, the ScrumMaster should transfer most of these responsibilities to the Team by teaching them practices to improve dialogue, techniques for group-decision making and tools to deal with conflict.
