Working Agile: Scrum Behind the Scenes
If you work in tech, you have probably heard about Scrum and have also tried it or are using it. There’s a chance you know people struggling to adopt it. And, at some point, those people raised concerns regarding Scrum being good in theory but not working in practice.
Well, each case is different. There is no magic formula. I’m here to give you a perspective on how you can approach and adopt Scrum. Forget the events, roles, and artifacts; those are important tools and instruments, but the core of the framework is its values!
“Successful use of Scrum depends on people becoming more proficient in living five values” -Scrum Guide
The Values
According to the Scrum Guide, there are five values that compose Scrum: Commitment, Focus, Openness, Respect, and Courage.
Let’s take a look into each one of them. We’ll discuss their meaning, possible ways to apply them with the rest of the framework, and I’ll share some common mistakes that you can discuss with your team/group.
Commitment
One major requirement in industries is being able to forecast. People try to create project plans with hard deadlines, breaking down months or years of work into smaller pieces from the start. A Standish Group report compares projects of all sizes between Agile and Waterfall methods. Overall, Waterfall represents 89% of failure or challenge, while Agile method reduces it to 61%. And if the focus is on small projects only, Agile methodologies achieve an awesome success rate of 58%.
So, how does Scrum help with this? Well, commitment of course!
With Scrum, all plans and timelines exist only to provide guidance. The development teams are the ones committing with goals focused on outcomes. They are the ones saying what they can achieve. And they do it for the next step, not for the uncertain future.
You might be familiar with the Sprint Planning event. People look to it as an event to fill the sprint with planned capacity. But that’s a common pitfall. The Sprint Planning event is a great opportunity to apply the commitment value; to have the team committed to deliver the agreed outcome (Sprint Goal). If you can do it with a bit more or less effort than the planned capacity that’s OK, as long as the team commits to that work.
And commitment goes a long way. It is incremental. Teams that start with Scrum tend to commit with work units, then they evolve to Sprint Goals, passing through the outcome-focused Sprint Goal, and eventually they reach the point where they commit, and deliver, a product increment in every Sprint.
There is another critical aspect of commitment that greatly contributes to a successful and healthy team: the commitment to work as a group. To support and put each other accountable; to be there for the team.
Signs that your team has Commitment issues:
- Failing Sprint goals.
- Ending the Sprint with a large amount of stories/effort left.
- Changing the scope of the Sprint (indicator of poor planning). Note that the team should not commit with work that isn’t refined. That is why a Definition of Ready is a good practice.
Suggestions to adopt Scrum:
- To have a team committed, you should give them more autonomy and allow them to define their goals and work for the Sprint.
- If you believe the team can do more, plan for the next Sprint Retrospective.
- Try to detect as a group what can change to enable group commitment and focus on Sprint goals that will represent product increments.
Focus
Focus time is one of the most common requests in development teams. The same request is present in Scrum teams, which is ironic since focus is one of the Scrum values. If you want a team to be able to commit to sprint work, then you have to give them the time to focus on it. Don’t interrupt.
Signs that your team has Focus issues:
- Frequent scope changes.
- Elevated work in progress (a work load in progress so big that the team can’t focus on closing a specific value increment).
- Team working on things that aren’t reported in the Sprint.
- Too many Sprint goals.
Suggestions to adopt Scrum:
- When calculating capacity, plan for the unplanned.
- Take a percentage of their capacity for meetings and other things that might pop up.
- Try to tackle things outside of meetings as much as possible, but when they are necessary keep them short and consider how many people you need to stop making that decision.
- Define work in progress (WIP) limits to avoid multitasking and blocking the flow.
- Measure how work flows in its multiple stages to detect bottlenecks in efficiency.
- Coach the team in working right to left so that you deliver value sooner by starting to stop and stopping to start.
Openness
Many times we see development teams raising awareness of working on initiatives where the reasons and goals aren’t clear or even communicated.
We can’t just work on cool stuff and there are good reasons for that. From time to time, we will have to work on an initiative just because it increases revenue or reduces costs. Other times to focus on value only for a specific customer. Every so often, features will not be challenging, but the company has agreements with customers that requires feature implementation. More senior developers know this is a reality and a need; they understand the nature of a business and commit even if in disagreement.
Scrum is an iterative process based on openness and transparency. Thus, the main thing is to stay open about our reasons to work in something. If we don’t do that, we can’t expect the teams to adapt to the needs.
We can only commit to something when we are honest about why we ask for commitment.
Signs that your team has Openness issues:
- Constant complaints about the work chosen.
- Receiving feedback that differs from the feedback received in the Sprint Reviews.
Suggestions to facilitate Scrum adoption:
- Openly talk about mistakes or wrong assumptions (tip: the retrospective event is the ideal opportunity to do this, but don’t let it be the only moment).
- Be open to receive and provide feedback and help.
- Establish clear moments for the previous decisions.
- Be transparent about progress (initiative, metrics, directions), regardless if it is good or bad, as it shows you trust people to correctly, and positively, read the data shared.
Respect
In Scrum, Respect represents handling our interactions with the belief that everyone involved is capable. And that’s not only for execution — that’s not even the main point of respect! If you believe someone is capable, you will hear what they have to say, even when you don’t agree with the content. You’ll respect your team members, value their contribution and them as a person.
Respect means everyone works together. Different roles are not there to fight, but rather to work as a team to achieve a goal in the most efficient way possible.
Signs that your team has Respect issues:
- Not believing a goal is achievable depending on the person that picks the work. Such constraints should be clear and included in the estimations used for Planning.
- Micromanagement is also a sign of lack of trust, thus lack of respect.
- Things that are said only in certain forums, as people are not comfortable in raising them in Retrospectives or during our daily work.
Suggestions to adopt Scrum:
- If you are not part of the development team, don’t look at their Sprint. Focus on the Sprint Reviews for goals analysis and suggest input for their Retrospectives.
- If you are part of the team, be open about the constraints for execution, and ensure you include them in the Planning event to enable commitment.
- In Retrospective events, agree on a way to allow everyone to talk (raise hand for example).
- If you notice someone doesn’t feel comfortable or that their opinion is being dismissed, follow up in a one-on-one.
Courage
Teams often try to balance the value of commitment with courage.
The courage value represents our willingness to tackle the hard stuff. That is not, in any way, a requirement for us to tackle things blindly. This is a value where we need both a growth mindset and a clear discovery process. You can increase your confidence in the initiative with strategies such as spikes, PoCs, or other long-lived experimentation. Being courageous is tackling the challenge of reducing the risks instead of accepting things as they are.
Signs that your team has Courage issues:
- No time for innovation or plans for it in your product or processes.
- Team fights back in an emotional way to a new direction just because it is different from the status quo.
Suggestions to adopt Scrum:
- Work as a group to define a clear process for discovery. Train the team in a growth mindset and in how to conduct a good experimentation.
- Tackle the problems and suggestions in the backlog with a positive attitude towards analysis.
- Challenge the initiatives and your own biases (tip: they might be unconscious) before rejecting work. Who knows, you might have a surprise.
Conclusion
“Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions” - Scrum Guide
Scrum is about relationships and interactions. It is about following common values in a work group environment, and its individual’s behaviors.
At OutSystems, we love Agile methodologies. Even our product is directed to bring value in the same way (fast, simple, iterative, adaptive).
For more information:
Originally published at https://www.outsystems.com.
