Push your boundaries
Are you returning to your retrospectives frequently with the same issues?
This is what you have to focus on.
Retrospectives have a key role in agile and lean methodologies. In a fixed cycle, the team members gather and inspect and adapt their way of working. In this format, they have the space to make decisions, how to use their precious worktime to achieve more value.
I often found myself in this situation, when the problems are obvious and addressed, but the things you have tried since the last retrospective had not led to real improvements. Typically, the team looks for answers for the following question:
“What do you want to improve in the next sprint?”
The team members often come up with suggestions that may have a scheme:
“We have to do more _________”
The following diagram shows an example of the proportions of activities for three sprints. The team has chosen to do more of the turquoise activity.
To be successful in the long term, constraints like the workload of a team have be respected. Although, it is called “Sprint” in the Scrum Framework, the metaphor is misguiding when you consider the long-term perspective. If one plans to run 5km, it is not possible to release the energy of a competitive 100m sprint and repeat this 50 times with the same velocity. A cycle of two-week sprints multiplied with the same factor matches approximately with the timespan of two years — not too long for a large project.
The workload of a team has to be on a level that can be maintained for an indefinite timespan. This becomes more important for products with a long lifecycle. Only a healthy team can deliver long term value with high quality. Quick fixes, phases with excessive stress and overtime can result in technical debt, frustration or even health issues. This cannot be the solution to deliver more value.
How can a team make conclusions to leverage their time in an iteration without taking too much risks for the future? Let’s ask differently:
“How can we automate _________ in the next sprint?”
Now, the goal is not to do more of something. With automation you can get rid of recurring manual tasks and free more time for the unique problems to solve. Especially software is great to be created once and executed endlessly often.
Before a solution can be automated, it is a unique problem, which has to be solved manually at first, but only once. After a solution is found it is too early to stop here. The next step is to find a way you don’t have to perform or execute this task on your own. Write the code, use an automation tool or create something physical that does this job for you in the future.
Compared to the diagram above, the effort changes. Of course, it is necessary to invest the extra time to create the automation. But it will pay off, when you save time with every execution, when you can achieve the same result with less effort.
After one thing is automated, you can pick your next bottleneck in the retrospective. This approach pushes your productive boundaries further and enhances the value of your work with each little automation without overextending your workload.
