3 Things We Commonly Forget When Implementing Scrum
It’s time to remember why we keep failing.
When it comes to Scrum, no doubt, below are the facets of the Scrum framework, as written by our great ancestor, The Scrum Guide.
Okay, we have all the Scrum roles, events, artifacts, and we’ve been running for few sprints. What are we missing?
There is more that is not stated than what is already in the Scrum guide. Our great ancestor has done this intentionally as the details of the implementation lies in the team’s approach, dynamics, priorities(the list goes on) based on the problems they faced.
This thinking opens doors for Scrum’s potential to solve problems outside of just software development. At the same time, this also opens doors for disaster, chaos, panic, and burnt-out teams if implemented very differently.
Based on my little personal experience, there seems to be a pattern and commonalities on why few Scrum implementations were struggling to become successful. Here are a few things I noticed we commonly forget to focus on:
#1 Is it ‘Done’ or is it ‘Done Done’?
Definition of Done, also known as DoD, is like the underrated sidekick that didn’t get much attention for the value it can potentially unlock in the success of Scrum.
Ever had to consistently spend a sprint just to handle technical debt that has been accumulated from the previous sprints?
You may want to opt for having a definition of done with the team moving forward.
The definition of done is already implemented, but technical debt is still accumulating?
Perhaps it’s time to relook at the definition of done. Commonly, it’s either:
- The definition of done is not accurate enough to ensure code quality at every stage; or
- There is a lack of using the definition of done as part of the team’s daily activities. Eg: only used to present during sprint planning.
Our great ancestors have also stated the importance of the definition of done under their Artifact Transparency section. Primarily, it is used as one of the artifacts to boost transparency while ensuring every feature built is following standards and guidelines set.
#2 Minimum Viable Proof
It was our last sprint together, we’ve had few successful releases, the team is motivated to keep innovating on features, our product owner and users were happy with the product and wanted more of it. Everything seems to be going in the right direction, and we were confident with the outlook of preparing on a new contract for the next phase.
When preparing for the new contract, the management team asked:
How do we know this next phase is worth our investment? Where’s the proof that it was successful back then and it can potentially be successful later?
Right at that moment, everything started to fall apart.
Our working software is our proof, right? The value we bring to our customer is our proof, right? How do we show proof that we have improved the ways of working?
We had questions more than answers. We tried a few methods; however, all the proof we’ve prepared was just not strong enough for the management to justify the investment they would be making. This eventually led the next phase opportunity to a closed.
Learning from this, let’s not forget to be well prepared to handle situations outside of just the Scrum team but are still within the product perspective.
Our great ancestor may not have written it in their guide, but it’s worth checking out the Evidence-Based Management Guide for a start. The guide covers realized value, unrealized value, ability to innovate, and time to market. Their appendix section shared a few examples of how we can further prepare our minimum viable proof in such a situation.
#3 Scrum only works with highly-motivated individuals
Yes, you read that right. It only works with highly-motivated individuals. Reason being:
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
- Our Great Ancestor, the Scrum Guide
Scrum requires self-organizing teams, and a self-organizing team requires the motivation to proactively perform their best work rather than being directed by others.
When implementing Scrum, we tend to forget that it’s not just about delivering the best value to the customer, but it’s also developing a self-organized team that’s able to sustain the product in the market through their continuous innovation.
How do we build that culture?
If we are already in a Scrum team, this leaves us with a few common options:
- Only keep highly-motivated individuals in the Scrum team.
- Train all the members to be highly-motivated individuals.
- Get the team to chant the mantra “we are highly-motivated members” daily. Kidding.
Realistically, we would usually be with option #2. To build that intrinsic motivation for all team members is one of the most challenging tasks considering every member has different priorities, personalities, and working styles.
Luckily for us, there is a common pattern that may help us with this. Although every team members have different working styles, all of them essentially want the same thing — to do a good job. This means:
- If the sprint sucks: let them know it’s okay; let’s do better next time.
- If the team wrongly estimated their work: let them know it’s okay; let’s do better next time.
- If someone made a mistake and accidentally brought the whole system down: let them know it’s okay; let’s do better next time.
Chances are, all they were trying to do is a good job. Keeping a mental note of that and giving positivity may highly motivate team members to do better next time, indirectly boosting their self-organizing skills. Having this skill goes a long way when it comes to sustaining a product in the market.
That’s all, folks.
Let’s not forget to prepare a definition of done, metrics of minimum viable proof, and building a highly motivated and self-organizing team as much as we focus on bringing valuable products to ensure sustainability.
Some may say it’s the Scrum Master or Product Owner’s responsibility to initiate these activities.
Did you know that anyone can initiate these activities?
It may be the primary job of specific roles to own them, but as a team, we all have the choice to make a difference or leave it be. If you feel there’s value in trying out some of the stuff mentioned, dare to share it with the team and see how it goes.
This has been based on my little experience with the Scrum framework, and hopefully, it been helpful for those in a similar field.
Till next time.
