Scrum Masters (at least in my part of the world) are often people seeking the transition to the role of a ‘Manager’ or a management position. However, when they land into this role amongst a highly technical team, they become clueless. This is because the one thing that they were moving away from became one of the most important aspects of their work - Technology. They have to deal with technology on a daily basis.
WHY? Well, Scrum only exists in order to create and deliver value. This is ensured via creating a VALUABLE and USEFUL INCREMENT by the end of every sprint. In software/technology teams one cannot deliver an Increment without the know-how of Technology.
So what should I do as a Scrum Master in that case?
In that case, take small steps to become technology aware if not expert and focus on two fundamental aspects:
- UnDone Work
- Technical Debt.
Deliver Valuable and Useful Increment
The biggest challenge with our traditional mechanisms of software development was there was no easy way to determine if the Product being developed would be Valuable and Useful to the end user. If I remember correctly, there was a report from Gartner that stated 65% of projects developed using traditional approaches were challenged i.e. either they didn’t create desired value, or there wasn’t enough quality or they were not usable by the end user. I don’t have the access to the report now to refute or substantiate the claims of the report so you may discard that element as hearsay, if you want to.
Yet, here is one of my personal experiences that can establish that traditional approaches did not necessarily create valuable or useful increments of product.
Database Migration impacting multiple businesses in North America
A few years ago, I was working for a large MNC and we were updating our Databases to MySQL servers. Our team in India had one job, run a nightly migration for the customers so that the next day they are able to resume their work on new updated systems.
One fine day, there was an issue and migration did not complete during the allocated hours. The team started to isolate and fix the issue. Time went by and it was past midnight India Time which means the businesses in North America had already begun their work. Since, the team fixed the issue and they wanted to go home, they pushed the changes after verifying on the designated test/staging servers but somehow it failed in production and impacted many businesses across North America. The team didn’t realize this until the next day when they came back. Luckily enough, we had a team in the US as well which provided production support and fixed the production issue controlling the damage. However, by the time they fixed the issue half of the business day was already lost.
What, So What, Now What
The team believed that they isolated the issue, found a fix and implemented it. It was working fine while being tested on Dev/QA/Stage servers; yet it failed in production. The reason that was later identified was not executing an SQL query on production, which was automatically executed on all lower levels because of privileges allowed.
This small error left the business strangled for work for over half a day.
Could this be avoided? Probably yes, if we would have had a Definition of Done. If we would have a DoD with a simple pointer stating checks for necessary database queries being updated and executed on production, could have saved us from a lot of firefighting.
Definition of Done (DoD)
Definition of Done is the commitment for an Increment. A formal description, a checklist that establishes that the Increment meets all the quality standards needed by the Product. Any work item which doesn’t meet the established DoD is unworthy of release (looks like I just stepped into the Thor universe).
UnDone Work
Any work that was planned for the Sprint but doesn’t meet the Definition of Done as established by organizational standards or the Scrum Team is termed as UnDone Work.
UnDone work impacts the immediate releasability of an Increment. All the UnDone work goes back to the Product Backlog, where it is re-evaluated for its Value and may or may not be taken up in the upcoming Sprint.
Technical Debt
Technical Debt is the distant cousin of UnDone work. It’s like Loki, the mischievous brother of Thor whose intentions cannot be anticipated till the very end.
In technical terms, when a technical choice is made (which we do all the time while building a product) where Quality is traded off for Speed, it would often lead to Technical Debt. It is basically a poor technical work around made in order to gain a little speed or deliver something faster. For example: Writing a single class with over 1000 lines of code even though we already know that at some point in time it will become unmanageable.
Technical Debt can be incurred consciously or unconsciously. That is sometimes you make certain technical choices knowingly while other times it was the best possible choice given your current understanding, knowledge, experience and skills at the time.
As a result, Technical Debt does not impact your ability to make release immediately but over a period of time it would slow you down because the code is no more manageable, modular or cohesive.
Addressing UnDone Work and Technical Debt as a Scrum Master
For a Scrum Master who may not be very well versed in technical terms these two could be small steps towards gaining technical mastery. All Scrum Master needs to do is to create Transparency about the accumulated UnDone Work and Technical Debt.
Tracking UnDone work could be a task at times as it might involve manual intervention to figure out how many work items met the DoD as expected, how many did not and what happened to the ones that did not meet the DoD. However, having regular conversations with Developers and using tools like a Sprint Board might be useful.
Tracking Technical Debt on the other hand is much easier and straightforward. There are multiple tools that are available to do this. One of the tools that I have personally used and found very useful is SonarQube. Provides plugins for many different tech stacks and is easy to configure. Once configured every time a build is promoted, it will generate a nice articulate report.
Scrum Master must focus on making the UnDone work and Technical Debt as transparent as possible. Use possible BVIRs (Big Visual Information Radiators) that would keep highlighting the current amount of Undone work and Technical Debt. This will help the team to focus on high quality deliverables and thus deliver Valuable and Useful Increments every Sprint.
Conclusion:
Scrum Masters are not always expected to be experts of technology as they are supposed to focus on many other peripheral aspects of software development that can render their team ineffective. However, this does not mean that a Scrum Master should be unaware of what technical practices can make their teams more effective. It is expected from the Scrum Master that they pay attention to missing Engineering Practices in their Scrum Teams and bring some of their experiences from working with other Scrum Teams to the current Scrum Team so that it becomes more effective.
P.S. In case you want to explore how to be more effective as a Scrum Master look up for our PSM and PSM-A classes.
P.P.S. You can also subscribe to our youtube channels: Piyush Rahate / Agilemania