There's been a lot written about what agile development and scrum should do for a team. After a team has been maturing for some time, it's easy to become blind and insensitive to phenomena that hinder its effectiveness and restrict its potential. Let's call them “scrum smells”.
Some teams are just starting with scrum adoption while others are moderately matured or even experienced in it. Each level brings with it its own smells and scents. This series will focus on both basic and advanced challenges that scrum teams commonly encounter. Today, we’ll talk about the problem of irregular releases.
Inability to regularly provide releasable versions
One of the basic scrum principles is being able to provide a potentially releasable product increment as a result of each sprint's effort. I personally believe this is one of the most valuable and underrated benefits of the whole scrum world. Scrum says that at the end of each sprint, the development team should produce a piece of software which the product owner can then immediately release and put to productive us, if he so chooses. That means that the software needs to be working, regression-free and without any work-in-progress stuff. Everyone on the team needs to have the feeling that there is no debt—be it technical or functional.
In real life, however, the production builds are provided quite randomly. Every scrum team has gone through this. At the end of the sprint the team would like to provide a final version, but there are incomplete features or regressions severe enough that this version can not be put out for productive use. So in the subsequent sprint the team attempts to fix the bugs, but continues developing new features in parallel, which introduces a new source of potential problems and uncertainty. Days and sprints go by and there is always something to be fixed in the current version.
This vicious cycle pressures the product owner to finally release everything that's been implemented so far. There's the always present “almost there” syndrome, the eluding moment of problem-free release. The product owner gets nervous and it's tempting to try to sneak one more “important” thing to the sprint, because god knows when the next release will take place. Long time-to-market is a reality. So-called hardening or stabilisation sprints occur, where teams just try to fix the product into a usable state.
Aside from the inevitable demotivation and pressure that arise, this also causes problems with planning and transparency. You never know where you truly are until you have no work left on the already developed backlog items.
Preparing the ground
So how to increase the chance of regular end-of-the-sprint potentially releasable versions actually happening? This is partially about a shift in mindset. Being able to provide a working, debt-free, done software increment must be a top priority for the team during the sprint and all activities need to focus on this one goal.
It all begins with the backlog refinement. Backlog items must be broken down to pieces as small as possible in order to give the team a high degree of maneuverability during planning. Oftentimes creating really atomic user stories is necessary—that means stripping the user story to the very core of the user's needs and solving it with the most straightforward approach. All the rest just becomes another backlog item, prioritised independently. Keeping the items too big or just being too optimistic about keeping some “easy to do” nice-to-have things attached to the core user story's essence is just naivety, frequently combined with a degree of convenience.
Then, at sprint planning, the team creates a strategy to steer the risk of discovering a severe problem shortly before the end of sprint with too little time to actually solve it. It helps to start the sprint with the riskiest features first and strive to start testing even separate parts of them as early as possible. This way there's a greater understanding of how much work there is really left to be done. Low risk items (like simple text changes or UI adjustments) can be left for later into the sprint.
The development team must not plan too much work, hoping that this time “we will manage”. The team must, based on past experience, realistically anticipate extra unexpected work even on “safe” backlog items.
And of course there is the well-known Definition of Done. Each team member must understand what it takes for an item to be considered done and everyone must understand it in the same way. What is on the DoD checklist? Well, that depends on the particular team, product and technologies being used. But if a team agrees, that DoD of each item consists of code to be written, unit tests or automated tests, documentation, code review, end-to-end test and anything else needed. Nobody can claim an item done until all this work has been done. This helps to create a common standard for quality and for complexity estimates. Strictly adhering to it reduces the risk of debt accumulation. Missing or unused DoD creates a fertile ground for debts and makes planning almost impossible.
Day-to-day activities and decisions
Frequent end-to-end testing during a sprint is absolutely vital. It is a dangerous illusion to create a single version one day before the sprint's end, test it and expect that all is going to be fine. That's not planning, that's gambling.
To enable this, new builds need to be created as often as possible, even several times a day. CI/CD pipelines are a must. TDD helps a lot. Automated regression tests are a must. Basically automating as much of the manual hassle as possible removes the reasons why teams usually avoid making builds regularly. This investment into automation is usually well worth it in the long run.
Adding feature switches (or flags) help. If it's evident that the team is not going to be able finish a certain backlog item (i.e. fulfill the DoD), it is “switched off” and it doesn’t interfere with the rest of the software.
The team must also understand that one done and delivered backlog item is worth far more than ten items in progress. The daily scrum is an ideal time for the team to evaluate the sprint backlog's progress and mutually collaborate on pushing in-progress items closer to a “done” state as quickly as possible. Team needs to learn to constantly re-evaluate where everyone's present effort lies and decide if there is something more valuable to concentrate on. All sprint backlog items are the whole team's job, not individual assignments. It is all about constant re-evaluation as to where to invest the day's efforts in order to maximise the chance of achieving debt-free software at the sprint's end.
When a sprint backlog item gets risky and it seems there's not enough time left in the sprint, the team needs to decide whether it wants to invest more energy in it (to increase the chance of getting it done, e.g. putting more developers onto it) or to stop working on it altogether and focus on another item that has a real chance of getting done. Decisions to drop a sprint backlog item must be consulted with the product owner.
For more about strategies to achieve regular releases, please check out the follow up “Scrum Smells pt. 2” post for more details.
Written by: Otakar Krus @otakarkrus
Top comments (0)