How can we avoid breaking the team into micro teams?
Don’t break your team into a working group!
Don’t break your team into a working group.
The main idea behind Scrum is to maximize the outcome of a team. That means the team is bigger than the sum of the individuals. However, this is way easier said than done. But what does happen in the real world? The most common outcome has a fuzzy sprint where the team cannot work together. Therefore each team member focuses on specific tasks in a way that forms micro-units.
That said, I ask again, why does that happen? In my humble point of view is the lack of focus. Then we need to ask again, why do teams have a lack of focus, that can be a couple of causes:
No Sprint Goal
Sprint backlog divided into categories
Product Owner wants to make everyone happy
No Sprint Goal
Unfortunately, it is getting more and more common and acceptable to have a Sprint without a clear goal, because the PO cannot define it or maybe doesn’t want to fight for it. Whenever this case happens, the Sprint Backlog tends to be determined by a certain amount of tasks that are generally not connected to the main goal and not always related to each other. If this is the case, the team has no choice but to split into micro-units, and everyone will play its own game.
A Product Owner must be able to define a Sprint Goal where the team can work together; the focus must always be in maximizing the value and not only in delivering features or closing tickets. The PO needs to be able to lead the team to a common goal; this is the only way that a can get the best result of them.
If no one knows how to achieve the goal of the Sprint, how can the team be motivated to overcome a challenge that may not exist?
Christiaan Verwijs nailed this topic down in his article Myth: Having a Sprint Goal is Optional in Scrum. I need to borrow a part from it, since it is complementary to the point I want to make.
Without a clear shared goal, and feeling the pressure to complete a Sprint Backlog full of unrelated items, there is no obvious incentive to collaborate. Instead, you are likely to see members of the team picking up ‘their own’ items from the Sprint Backlog and starting work on that. Self-organization will be limited and members will remain (or become increasingly) specialized in particular kinds of items;
Sprint backlog divided into categories
Another common scenario due to “good practices” is to have the Sprint backlog divided into four specifics categories:
50% new features: focus on bringing changes to the product;
20% maintenance: focus on removing tech debts;
20% bugs: focus fixing bugs;
10% spare time: time used either for team development other unexpected events.
The numbers here vary from team to team, but the idea of this approach is to have a segmented backlog to ensure that all sides are covered. I am against this approach for a lot of reasons:
Focus: how can a team focus and work together if there are so many aspects to be covered?
Why should we save time to solve technical debts? I would be curious to understand why we are creating them and then take the required actions to change it.
It is complementary to the previous item, why do we need to plan to fix bugs? Shouldn’t we plan to improve the product quality in a way we can avoid the flaws in the first place?
Unexpected events should be treated as so and not planned.
My main objection to this approach is because, within that, the team can barely get the best of teamwork. Also, the existence of bugs or technical debts, don’t mean we need to react immediately; we should always understand what the best for the product is. What we are fighting for, and then we can define the priorities.
Software has bugs, that’s inevitable. David Hansson has a great explanation of why we shouldn’t worry about fixing the bugs we find. Based on this vision, I believe that Product Owners should be focused on the value and not on breaking the Sprint to reach useless metrics, like zero bugs.
Once we accept that simple fact that software = bugs, we can progress to understand why fixing them may not even be that important a lot of the time. The absence of bugs is simply one parameter of success in software, but not even close to the most important one (with some exception for life critical systems).
Useless software can be entirely bug free, yet remain entirely useless. Useful software can be ridden with bugs, yet remain highly valuable. Or, the value of software depends far more upon the problem it solves than the quality by which it does so.
Product Owner wants to make everyone happy
This last point is the most dangerous. Whenever the PO is a yes person, that will lead to low results achievement. Because the PO may try to prioritize a small request for everyone. Thus everyone will be happy, since then they can see that the team is working for them.
Actually, this approach leads generally too big disappointments, the team, for example, is not being challenged with more complex problems to be solved, and the stakeholders receive only small improvements or changes.
The PO should be a no person, explaining the benefits of focus and then align with all the stakeholders to come to a priority instead of trying to do everything at the same time and, at the end, doing nothing.
Robbin Schuurman describes this type of PO is the Clerk, a misunderstood stance of a Product Owner. That’s a role we must avoid, since it goes against what product Owners should be.
The Clerk is your personal waiter for all your user story serving. Gathering all the wishes, user stories and demands is what The Clerk does. (S)he isn’t focussed on achieving the product vision, nor on crafting clear goals and objectives and the Clerk most certainly never says ‘no’ to stakeholders. There’s nothing wrong with servant leading your customers and stakeholders as a Product Owner, but if your main purpose during the day is getting new ‘orders’ from stakeholders… then you’re missing the point of being a great Product Owner.
How should that be?
Product Owners own the vision of the product; if the PO doesn’t have a Roadmap prepared where he or she wants where to go, something is missing. Once the PO has the Roadmap made and agreed with everyone, planning the Sprint is not complicated, but the PO needs to be always able to define a goal and work with the team to deliver together the best result possible.
There are multiple instances of Product Owner; each one will have a better fit to each scenario. Robbin Schuurman describes the preferred and misunderstood stance in this article. My stance is the Visionary, because it embraces profound the principles of the Agile Manifesto.
The Visionary, clearly communicating the product vision, strategy, business goals and objectives with all the relevant parties. A visionary Product Owner tends to focus on the future, on changing the status quo and helping people to see what could be, instead of what is.
Don’t fall into the trap of breaking the team into micro teams, please. Less is always more. A PO must lead the team towards more collaboration!
