The Last Sprint

In 2018, I shared some thoughts on efficient and proven project management practices in “ 90 Sprints for Capital Markets”. It’s a series of 4 articles worth taking a look at — everything there still holds true.

A short recap:

• Remote work does work,
• Stand-up is hard and is the second most important meeting after retrospective,
• As a leader, your goal is to work yourself out of your job,
• Agile means: good planning, documentation, requirements and architecture design ready upfront, but still Agile,
• Backlog, like Earth, is not flat,
• What is „Ready”, „Done” and „Ready for release” is not obvious, the Team has to define it,
• The time that is worth tracking, is the time wasted!

In the series, you’ll find multiple examples, details and different approaches, as well as a general idea for continuous process improvement and adjustment.

Staying true to this process, several new things occurred to me throughout a year of project work:

• In reality, releases don’t usually fit into sprints. Some of the sprints were divided between work for the current and next releases.
• The sprint board is actually a Kanban board but covers only a part of the process. The pre-planning and release preparation part is outside the Sprint board.
• Epics that don’t fit into Sprints have to be tracked separately outside the board.
• People never finish work on the last day of a sprint. Day or two before the end of the sprint people start working “on items for the next sprint”, before the actual planning.
• Teams quickly learn to handle work items in a way that makes velocity stable.
• Estimating 2 sprints ahead does not help much long-term, instead, perform product estimation and plan for many releases ahead.

The Sprint metaphor, which brings to our mind a very quick and exhausting run, does not fit to software engineering. It’s more like a marathon.

Are Sprints considered harmful then?

It depends. For young teams and organisations that are beginning their Agile transformation, Scrum, with its concept of Sprint, is a relatively simple and well-defined framework. Introducing a time constraint helps the team and the stakeholders focus on a single goal and maintain a cyclic procedure.

However, for a mature team, a Sprint might just be a speed bump. The last Sprint in the project mentioned in “90 sprints…” was actually THE last sprint for my teams. A deep retrospective showed that the concept of Sprint does not solve any problems anymore.

To be clear: we kept working the same way (well, almost):

• Backlog priority buckets are merged into a wide Kanban board covering the whole lifecycle from raising a new item to a release.
• Different columns are used for Stories (more) and Epics (fewer).
• Recurring (e.g. weekly) Product Backlog Refinements still happen to make sure that the Next and the To-Do columns never “dry out”.
• Definition of Ready is still applied to the To-Do column just like in Sprint planning.
• Work In Progress (WIP) constraint is put on each column to make sure that the flow of work is fluent.
• Demos are still there whenever an Epic is ready to show.
• Nothing changes in daily Stand-up meetings as well as the Retrospective.
• Milestones are planned to fit actual releases rather than a time-boxed schedule.
• Rather than Team Velocity, we track Lead Time (time needed for an item from design start to release) and time tickets spent in each column.

We still keep a waste log!

As an outcome of the continuous improvement of Scrum, a highly customised Kanban was born. Some sources call this Scrumban, which means taking the best of both worlds.

The only problem was that we were not able to find a new name for a “Scrum Master” in this process so far.

Keep improving your process and don’t hesitate to question the status quo. You may be able to find better ways of doing things.

Originally published at https://www.linkedin.com.