Once the official Scrum Guide introduces the basic ideas and values behind the framework, the practical part opens with the Scrum Team. Similarly, when talking about the basic structure of Scrum and the early days, Jeff Sutherland tells how it all started with the Team. The reason for this is very simple - the Scrum Team is at the core of the entire Scrum experience and all the Events and Artifacts are there to aid and support the Team in delivering value.
The basic organization of the Scrum Team (size, roles, responsibilities) is well-known and (usually) followed closely so as to provide a solid cornerstone for the Scrum practice. However, as most Scrum practitioners can testify, there is more to it if the Scrum Team is to be successful.
A Scrum Team needs to find the balance in how its members fulfill their roles and manage their interactions - a balance that will enable the underlying Scrum ideas to have as much beneficial an impact on the Team’s work as possible.
Scrum Master is one of the two individual roles in a Scrum Team and it is no surprise it is crucial for the Team for the Scrum Master to fill their role well. This requires an immense amount of balancing in order to still provide the support the team (and the organization) needs but without going overboard and actually hindering it.
For example, one of the Scrum Master’s main responsibilities according to the Scrum Guide is removing impediments to the Development Team’s progress. This reads straightforward enough, right?
In real-world cases, however, this is sometimes understood in the sense that the Scrum Master is supposed to notice and single-handedly remove every single impediment the Development Team encounters. In such an environment, the Development Team can easily end up over-pampered, never challenged and actually denied the chance to grow as a unit.
In other words, a Scrum Master will want to balance so as to still help the Development Team with the impediments they encounter, but still empower the Team enough to handle some of them on its own.
Another common responsibility of the Scrum Master is to ensure that external stakeholders understand which interactions with the team are beneficial and which are disruptive. This is especially common in large organizations with plenty of traditional structures and practices still in place.
Sometimes, a Scrum Master’s answer to this will be to act as a shield to the Team, deflecting the majority of interactions in the belief that the Team has to be protected against these intrusions at any cost.
While this is warranted in certain cases, it can also backfire by promoting a certain kind of isolation of the team, turning it into a silo, one of the things Scrum is supposed to prevent. This isolationist approach can also lead to a feeling of mistrust within the organization.
Once again, a Scrum Master needs to balance out protecting the team from truly intrusive behavior from outside and avoiding siloization by providing opportunities for external stakeholders to get insights into the Team’s work.
The Product Owner role is very clearly defined in the Scrum Guide and the responsibilities and the interactions are theoretically very straightforward. In practice, however, finding the balance that will work for the better of the Team can be difficult.
For example, a Product Owner may struggle with finding the best way to express Product Backlog items, either providing too little information or too much. In such situations, the Scrum Master and the Development Team should get involved and provide assistance.
Another thing that the Product Owner needs to balance out is the value of inputs when ordering the Product Backlog - whether to put emphasis on the business requirements or to heed the input from the Development Team which might call for alternative prioritization.
In some real-world situations, most commonly in organizations where traditional software development processes had preceded the Agile approach, a Product Owner may find it difficult to move away from control-heavy behaviors that have no place in Scrum. Similar problems may arise in situations when the formal Product Owner is not the member of the same organization as the rest of the team (e.g. in software development outsourcing).
In such situations, it is essential to have a balanced approach to this so as not to sour the relationship between the Product Owner and the rest of the team. The Scrum Master should take the lead on this and find the best way to educate the Product Owner in question.
When we talk about the Scrum Team as a unit, we cannot separate it from the Scrum Events whose purpose is to provide a framework for internal and external interactions.
We wrote earlier about the different meetings that the Scrum Team will hold as part of their practice and we covered the basics. What we didn’t get to discussing was the innately sensitive nature of these meetings and the potential of doing them all wrong. In keeping with the theme of our article, finding the right balance is usually enough to prevent this from happening.
There are a number of ways in which the Daily Scrum meeting can go off the rails. For example, team members may lose their focus and ramble on incessantly about issues that are not supposed to be discussed at this meeting. Sometimes, the teams go the opposite way where everyone just rushes through their own thing while others wait for their turn and no one listens to anyone else.
Finding the balance between the two is crucial for a successful Daily Scrum. People should be engaged and ask for help if they need it, but it should not turn into an hour-long meeting where people discuss technicalities or plan the rest of the Sprint.
Anyone who has spent more than a few months in a Scrum environment will know that a Sprint Review without stakeholders’ involvement and input is all but pointless. Maybe not entirely, but definitely close.
On the other side of the spectrum, there are also Sprint Reviews where the Scrum Team is jumping through hoops and being interrogated by the stakeholders. It is safe to say this is not the healthiest Sprint Review atmosphere either.
Which, once again, brings us to the question of balance where the stakeholders would be engaged and involved, but where they would not turn into overseers who are constantly denigrating and pressuring the Scrum Team.
The good news is that the majority of stakeholders are not like that, anyway.
As the most “personal” of Scrum meetings, the Sprint Retrospectives require quite a bit of balancing so as to unearth the team members’ true observations and feelings about how the team performs.
For instance, it is not that uncommon to encounter Sprint Retrospectives that conclude that everything is great and there are absolutely no problems. This, in itself, is a problem and there are innumerable reasons as to why this is happening:
- the team is just not engaged enough
- team members don’t feel comfortable speaking up about problems that are due to someone else’s actions
- the team needs a more formal way of documenting the impediments
While these can be addressed, it is important not to go the other way and turn the Sprint Retrospective into a battle royal-type event where people are at each other’s throats and where negativity dominates.
It is also important to bring some structure to Sprint Retrospectives, but without turning them into these artificial ceremonies where team members go through the motions simply to check them off the list.
Like we mentioned, quite a bit of balancing to be done with Retrospectives.
There is no good Sprint without a good Sprint Planning and in order to do it well, the team needs to walk a very fine line.
For example, when discussing the objective that the Sprint should achieve and the Product Backlog items that they are recommending to accomplish this, the Product Owner needs to find that balance between giving the Development Team some breathing space while still challenging them (especially if the Scrum Master believes the team can handle the challenge).
Negotiations on the amount of work that will be pulled into the Sprint should also be handled carefully and, above everything else, empirically. Everyone should back their opinions with existing data and find an arrangement that works for everyone.
Once the Sprint Backlog is agreed-upon, the Development Team will want to have a very clear picture of how they intend to work on the Product Backlog items that were accepted to the Sprint, but they have to be careful not to go overboard and try to plan out every single minute of every single day in the Sprint.
Instead of a Closing Word
At the very core of Scrum, we find transparency, inspection and adaptation. When practiced correctly, these will help the Scrum Team facilitate their search for the balance which will, in turn, allow the team to excel.
It should also be pointed out that even when the team believes it and its practices are in perfect balance, there is always room to improve it.