Nine Ways to Ensure You Succeed with Scrum – Part II

In this conclusion of the nine success factors for Scrum, we are going to continue where we left off on our last article and discuss the remaining constraints from Michael James.

1. 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.  Your business made it this far without Scrum and we can wait.  If we have people who cannot participate full time with the Scrum Team because they have other commitment, then I usually tell them, “Finish up what you are working on now and when that priority is complete, join the Scrum Team.”  I do not want to add to the multitasking and would prefer Team members be 100% focused on our effort rather than split their  attention across two (or more) competing efforts.  You are only on one Scrum Team at a time.
2. 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.  Teams that are that size just seem to work perfectly.  In the past I have talked about the challenges related to micro Scrums, but you also have to watch out for bigger Scrum Teams.  In addition to the Ringelmann effect (when there are more people in a group, a person’s individual contribution tends to decrease), people tend to specialize as front-end, back-end, middle tier, test, DBA or whatever functional title they have when you have bigger Scrum Teams.  Nothing is wrong with specialization and mastery.  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.  Also, there tends to be greater interest by the Team members on what everyone else is doing since in smaller Teams when one person lags it has an impact on the delivery of the entire Team.  No Scrum Team over ten people.
3. No “my work” vs. “your 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.
4. 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 21^st century.  Find ways to make the distributed interactions more like the interactions described in the Team room article by Martin Fowler.  When working in distributed Teams add elements one at a time until you find the optimum set of practices for your environment. The Scrum Team sits together.
5. 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.  Very rarely should the Team, or the ScrumMaster, bring in an outside Stakeholder to resolve an internal issue related to the technical decision or the Team dynamics, without the Team first making an attempt to work through the issue themselves.  Team works to solve its own problems before asking for outside help.