Scrum Guide Decomposition, Part 2
Scrum Guide Decomposition, Part 2
In the second part of this series, we continue to break down some of the essentials of Scrum and compare fact to fiction.
Join the DZone community and get the full member experience.Join For Free
This is the second part of the Scrum Deconstruction. You can find part 1 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org’s PSM I exam that I took back in October last year. I have made updates based on the newest version of the Scrum Guide, November 2017.
Here I share in the hope that someone finds it useful.
Sections in italics will be taken from the Scrum Guide. I’m not going to do a cut and paste, but re-type out what is present. Therefore, there may be mistakes.
Sections in normal print will be me rephrasing or my interpretations of the paragraph. This I would like to think of as the positive aspects of Scrum.
Sections in underlined will be the negative aspects that I see, or have been told, read or anything else negative. Sometimes these will sound silly (and probably are) as I find it difficult to find negative aspects, and this is where I ask for help. If you have more constructive negative feedback about a paragraph, please let me know in the comments.
Side Notes are in underlined italics.
Now, let's get on with the deconstruction.
The Scrum Team
The Scrum Team consists of a Product Owner, the Development Team, and the Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
By letting teams self-organize rather than being told what to do, they are given ownership and authority over their workload. Studies have shown that when you have a high sense of control over your work, you are less likely to suffer from stress and actually be happier. You also work harder. You have more control over your destiny.
Self-Organizing! Teams would not do anything. People are lazy if they are not told what to do. The work will never get done.
Cross-functional teams have all the competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
In the enterprise, it would be difficult (but not impossible) to have a team with all competencies to do all the work simply because teams are siloed into specific competencies. For example, DBA’s, Middleware, specific back-end systems like SAP, and so forth. The enterprise's unwillingness to break apart these silos may hinder them from fully getting the benefits of Scrum.
By having team members that are cross-functional, but not necessarily proficient in all competencies, you can avoid delays when someone, for example, is sick or on leave. Someone can continue the work. The team can also share the workload. No single person is carrying the team because they are the only person who knows that competency.
The term “Jack of all trades – master of none” comes to mind. Good luck finding people who know everything.
It is the team as a whole who becomes the masters. Not individuals.
The Scrum Team has proven itself to be increasingly effective for all the earlier stated users, and any complex work.
A team of 3-9 people working together towards a common goal.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.
You are able to seek feedback sooner. Make corrections earlier and thus reduce the chance of going too far building the wrong thing. Thus reducing wasted effort saving time and money.
Just get the damn specs right in the first place. Get it locked down and signed in blood. Then it becomes the customers' fault if they got it wrong in the first place.
The Product Owner
The Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is responsible for making sure that the development team optimizes its work to produce value. This can be done by…
- Prioritizing work based on value.
- Communicating the backlog to the development team so they understand what needs to be developed.
- I’m also getting ahead of myself.
Yes – if you used Scrum to build a house, you would build the roof first as that gives the most value, then the walls, then the floor.
Side note: Yes – someone has used that argument with me before.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and;
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner needs to make sure the Development Team has enough information to hit the ground running when they start on an item. This may be before the sprint (preferable) or during – the "when" is the Product Owners responsibility.
So what does the Scrum Master do? Seems like the Product Owner does all the work!
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee.
This is so that one person’s vision is fulfilled. Not a bunch of random requirements from different people. RoboCop II comes to mind where his directives were done by committee. RoboCop pretty much couldn’t do anything without violating something.
The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
What happens if you get a Product Owner who ignores the committee – or the users?
This is a risk – in which case it is for the committee and Product Owner to work out.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.
This is actually to minimize the chopping and changing of tasks for example when a developer is asked by 5 different managers to get their little piece of work done.
But how does anything get done? Manager A needs his thing, Manager B needs his. I have mine. It all needs to be done and it all needs to be done now!
The Development Team
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.
Basically, treat each Sprint as a mini project. You do not have projects where you do only documentation or a project that only does testing. You do everything and at the end of that project, you release. At the end of your sprint, you need to be in a position to release if needed! This then puts the decision to release on the Product Owner (The Business) and is not hampered by the development team not being ready.
But we are not in a position to release at the end of the Sprint! There is too much work to be done!
You have taken on too much work for the Sprint.
- Slow down, sometimes you need to slow down to speed up.
- You need to break down the work more.
- You need to make sure the Increment provides some (Doesn’t have to be a great deal) value.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
The Team chooses the work they do and how they do it. By “empowered,” the Development Team has the authority to accept or reject work as they see fit. If an item on the backlog does not have enough information for the development team to work on, and it's not coming any time soon – or the Development Team is uncomfortable doing the work, then they have the authority to say "No."
The team also works out the best way it can get the work done.
But what if the Development Team gets it wrong? They completely screw up? They need to be "told" what to do and how to do it so it doesn’t happen.
Yes, the team can screw up. Although the team cannot be "told" what to do, they can be guided. If they screw up, then the team learns what did and didn’t work. Instead of wasting months with traditional development, only a sprint (up to 1 month) is wasted.
This is a chance for all on the Development Team to learn.
Development Teams have the following characteristics:
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into increments of potentially releasable functionality;
- Development Teams are cross-functional, with all the skills as a team necessary to create a product increment;
- Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
- No Senior Developers
- No Architects
- No Testers
- No DBAs
Who leads the team if there is no senior?
It is an egalitarian structure. Everyone has a say, everyone is equal.
That would be anarchy!
This is why the team is made up of “professionals,” and not animals.
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
All for one and one for all. Everyone needs to look out for one another.
Development Team Size
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decreases interaction and results in smaller productivity gains.
If you have 1 or 2 developers, the interaction between developers is already there. Scrum could actually decrease that interaction because of the formal times. This causes the productivity gains to not be as much as for larger teams.
So you see, Scrum doesn’t work for smaller teams.
Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment.
Too few people may not have all the required skills, but not always.
Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for the empirical process to be useful. The Product Owner and Scrum Master roles are not included in the count unless they are also executing the work of the Sprint Backlog.
The more people you have, the more communication channels there are. We as humans can only support so much at any one time.
The equation is:
communication channels = n(n-1)/2 where n is the number of people.
So for 5 people, n = 5 we get
5(5 -1)/2 = 10 channels.
for 9 people, n = 9 we get
9(9 – 1)/2 = 36 channels
for 10 people, n = 10 we get
10(10-1)/2 = 45 channels
At this point (and most likely lower) our brains cannot keep up with the number of people at once.
See – Scrum doesn’t work with large teams either. Only a specific set. Business doesn’t work that way. It might work well within a startup for a web application but not Enterprise.
An enterprise may be looking at it the wrong way which is why they are having troubles keeping up with Smaller Agile companies/teams and why they are scrambling to keep up.
The Scrum Master
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules and values.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
The Scrum Master:
- Helps the team understand Scrum
- Helps them stay within the Scrum Framework. Without a Scrum Master, practices may slip back to what is comfortable, which is the process already known. For example,
- Standard Command and Control Management
- or worse, cowboy development in the name of Agile.
The Scrum Master does this by not being in charge, but by guiding the team.
A servant-leader is on that coaches to get you to your best. They are not there to tell you what to do, but to help you make the right decision.
Who is in charge then? If the Scrum Master does not direct, then developers will do nothing.
It's the inmates running the asylum, and the Scrum Master does nothing.
Scrum Master Service to the Product Owner
The Scrum Master serves the Product Owner in several ways, including:
- Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
- Finding techniques for effective Product Backlog management;
- User Story Mapping
- Impact Mapping
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- The more clear the team is on what needs to be built, the less time is wasted asking silly questions or getting stuck or building the wrong thing.
- Understanding product planning in an empirical environment;
- Don’t plan everything up front. Do a bit, evaluate and plan the next move.
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
- Draw out from the Product Owner what he could use now, not at the end of the project.
- Understanding and practicing agility, and;
- Facilitating Scrum events as requested or needed.
- Help the Product Owner become more available to the team.
Scrum Master Service to the Development Team
The Scrum Master serves the Development Team in several ways, including;
- Coaching the Development Team in self-organization and cross-functionality;
- Guide the team to make good decisions without making the decisions for them.This is easier said than done as the team will make mistakes. The trick is to let the team make the mistake, have them recognize the mistake and let them correct the mistake.Also have team members work in areas that are not their specialty. This can help the team become more cross-functional.
- Helping the Development Team to create high-value products;
- Don’t ignore quality
- Reduce waste
- Get the team better at their skills.
- Removing impediments to the Development Team’s progress;
- Anything that stops the team from completing a task. Could be related to people, processes, or technology. Need to identify impediments early to reduce their effect.
- Facilitating Scrum events as requested or needed; and,
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
- Try to prevent the team from reverting back to their old ways. Especially during the difficult transition period.
Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including;
- Leading and coaching the organization in its Scrum adoption;
- Planning Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact Scrum and empirical product development;
- Causing change that increases the productivity of the Scrum Team; and,
- Find ways and experiments to help increase productivity. Research different methods.
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
- Collaborate together
- Share ideas
- Not everyone wants to do Scrum. Don’t force it down my throat!
- Hence, the Scrum Master needs negotiation skills.
- Not everyone can work under Scrum, this needs to be taken into account.
This is it for Part 2, part 3 is coming soon, or check out the original source if you can't wait.
Published at DZone with permission of Holger Paffrath, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.