I guess I am doing a series of posts on Scrum and the latest Scrum Guide from 2020. Lets take a look at the Scrum Team. These are my thoughts and interpretation of Scrum as of today and the conversations and implementations of Scrum I have experienced both good and bad.
Scrum Guide 2020
“The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”
“Developers” in the Scrum context are the makers/creators of the product and is not restricted to a specific skill set. Coding, testing, UX/UI, deployment, documentation and anything else that is needed to complete a product increment is covered by the Scrum Team.
Scrum Guide 2020
“There are no sub-teams/hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”
This is not “in theory” or “not in the real world” jargon. This is literally stating that a team is not a Project Management, Design, Development, Quality and Deployment departments throwing work back and forth at different phases.
Scrum is stating that when using Scrum, the unit of the team work together to achieve a single objective/goal at a time. That objective/goal is not “Get all this stuff done in this Sprint.” I find myself saying often that “More faster is not a product strategy, nor is it development strategy.” If this means that the team slows down to focus on a single story until it is done before moving onto the next to learn how to work as a team, then that is what needs to happen. As the team learns more about how they work best together, more increments of greater quality will be created with greater frequency. This is not a forever increasing “velocity” and a team will find a flow that is predictable over time. Once the team is producing quality software increments, do not use their velocity as a weapon for more work faster, this only leads you back to the division and silo working style. The inability of proper prioritization is usually the culprit to that, but that is another post.
Scrum Guide 2020
“Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.”
“Scrum Teams have all the necessary skills”, does not mean they use those skills in silos, or that they are not permitted to learn another skill. Slack time is key with teams in learning organizations. Also, just think about it this way when using Scrum, can you “Sprint” forever?
The other part of this is letting the cross-functional team decide how to get their work done. They do not need managers assigning work tasks or dictating how they will get things done. This is often a trust issue in an organization. In order for this to work, the organization has to trust the people within the organization to do the work they were hired to do.
Scrum Guide 2020
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration,
verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.”
Again, a cross-functional team with all the skills they need and are not siloed off from one another and are responsible to handle all of these aspects. There is no PMO that tells them what and how to build. Just like there is no set of developers that do not test or offer better solutions. Just like there are no Quality Assurance people that only perform manual testing after a developer is done building it playing gotch-ya and acting as gatekeepers to production. Just like there is no manager dictating who will do what and when.
I want to call out this piece “Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.” A sustainable pace requires slack time. Remember, these are not teams of machines, these are people, and people need to be treated humanely. I have often voiced my displeasure with very many aspects of Scrum, but in this instance they are at least trying to say, albeit very poorly, that a sustainable pace is necessary. But again, you can’t possibly Sprint forever. There are many teams that have taken an approach to building in slack time either in the Sprint itself or taking a week off from Sprinting occasionally to do whatever they wanted to do. This could be for the product they work on, or just to come up with something cool to share with others. The only restriction is that it needs to be done by the end of that week off from Sprinting.
Scrum Guide 2020
“The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”
I will try and lay the reasons out for this section a bit more straight forward.
- “Typically 10 or fewer people.”
- Fewer lines of communication to maintain
- Small teams are able to focus by keeping WIP (Work In Progress) limited to a single objective at a time.
- Management doesn’t burden smaller teams with excessive amounts of work. Well, not any sane management would do that.
- “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams.”
- This should be something the Scrum Team recognizes and decides what to do. Management should not be relied on to tell people which teams they will work on.
- Large groups typically are no longer a Team. These groups tend to thrash to get done too much, too soon, and struggle with communication and collaboration.
- “Each focused on the same product, Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” – I have some issues with this…
- Organizations with a lack of ability to prioritize often split large groups into smaller teams but no longer share a Product Goal since each team is aligned with a separate functional area or user experience of the system they work on. If there is no Product Goal, there can be no alignment across these teams, and each team will be focused on what is the next thing for their functional area which often times impacts the other teams and prevents them from working towards the things they think are most important. This leads back to teams divided in their work to support other teams in the product to get something done.
Scrum Guide 2020
“The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.
This does not say their is not testing or testers. This is saying the “Developers” are any member of the team that build the product increments towards the Product Goal. That is collaboration, coding, testing, necessary documentation, deployment, anything that supports the Definition of Done of a product increment. And the team is accountable to each other.
The slippery part here is when things enter the Definition of Done that really have no impact on the product increment or are what is referred to as anti-patterns. Here are some examples:
- Approved in Sprint “Demo”
- Ready for UAT
- Ready for Testing
- Staged for Release
- Project Roadmap/Gantt Chart Updated
- Budget Adjusted
- Velocity Report Updated
- Capacity Report Updated
- Linked to Application Architecture Diagram
- Linked to Systems Architecture Diagram
- Approving Architect Signature
- Developer Task Work Breakdown Attached
- Assigned Developer Listed
- Assigned Tester Listed
- Dependendency outline attached
The Scrum Team and how it is applied when using Scrum to work in an agile way can be actively destructive and dysfunctional when it is not supported by the organization. Scrum is a framework for a way of working, and it does allow teams to work in an agile way when applied as originally intended. Most often with larger organizations, the many layers or organizational hierarchy and bureaucracy that accompanies it cause any attempt at creating truly cross-functional Scrum Teams almost impossible. If this is the case, then I still say let the teams decide what is the most effective way for them to work together. If it works for them, that’s great, but beware the old trappings of “we need to do more faster” which solution is usually to have a large group of people all focused on separate tasks building and testing separately and the round robin game of “Get the requirements perfect up front”, “We need to have a testing phase for all of this work”, “the requirements changed”, and “this group has so many people, you should be able to do more”.
Again, I am not saying you must use Scrum, and I am not saying you are not “agile” if you don’t. There are plenty of teams and organizations that don’t use Scrum that are far more agile then many Scrum teams I have seen. What I am saying is, if you are going to use Scrum as your framework towards agility, you would be best served by at least trying it first, before saying “that won’t work here” or “no real successful organizations work with developers and testers on the same team.” Once you say that, you lose all credibility as someone who has done any research or had any experience with Scrum or Agile.
I will add one thought here since I am aware that it sounds awfully like I am stating “all teams using Scrum must do Scrum exactly as stated in order to be agile.” I am not saying that. Maybe a better statement on my position is “I am not interested in helping Scrum Teams follow the Scrum Guide. I am interested in Teams working together and working in a healthy way that they decide.”
As always, I am open to people commenting and sharing their own thoughts and experiences with anything that I write. I have been wrong before and will be wrong again. That is part of the fun after all… Learning…
Chris Pipito 