Getting into shape after Scrum

Trying Kanban

A Kanban board is a very simple concept. The team identifies the major stages any work item passes, and visualizes those stages as columns on a whiteboard. The work items — represented by post-it notes — pass from one column to the other as the work progresses. Whereas Scrum is dependent on upfront planning and estimates, Kanban is more flexible in this respect. Also, Kanban encourages an ongoing rhythm in the team’s process, whereas Scrum with its sprints features fairly slow starts with pressure mounting as the end of the sprint comes closer. The steady pace encouraged by Kanban seemed to be a better fit for our team as it can better accommodate urgent issues: there is no sprint to be cancelled or goal to be missed.

An introspective

Rather than put the blame solely on Scrum or Kanban, let’s list our own faults as well. Why were they impeding on our perceived productivity and how did they contribute to rising frustrations?

Dependence on individual people

Many work items were of such a nature or complexity that only 1 or 2 people knew enough about the subject matter to resolve the issue. Looming deadlines and fear of the unknown lead to unjust amounts of pressure on these people.

Necessity for clear-cut specs

Work items were often entered into the administration system with the absolute minimum of information. This left enormous room for interpretation, often resulting in development that missed the mark and thus rework.

Inaccurate estimates

When asked how much time a certain development would need, the team consistently underestimated the work. Even bug fixes that were marked as a single day’s work often needed 3 or 4 days.

Unpredictable, ad hoc release cycle

There was no clear cadence to releases. Instead, we often hurried a release when the moment called for it.

Understaffed team given the ubiquity of the product

Our main product is used for and with nearly every project our company has. It’s even the very backbone of our projects, yet the team’s size did not reflect this dependence.

Under-representation of support tickets

Incoming 3rd line support tickets (or even 1st and 2nd line) were never given proper attention at the beginning of sprints, so they were always disrupting.

Hitting our own stride

In our efforts to achieve a stable, continuously improving product with a steady and predictable release cycle, clear focus during development, room for both innovation and upkeep without getting lost in a project-versus-product discussion, we envisioned a method that would give us flexibility like Kanban, structure like Scrum and room for growth.

Know what to build…

The very first stage we pass through is where we gather context: problems are fully analysed so we know what it actually entails. With this knowledge, we aim to find and specify the solution. Only then can we fully understand and communicate what needs to be built. Looking back at our earlier efforts, this is very reminiscent of our blueprints. It stands to reason, then, that the very first stage of our iterative cycle involves a supercharged blueprint or, put more professionally, a functional feature specification. A small but important part of these specifications is their worth. The council does not estimate how much time a certain feature needs to be built: they decide how much time it is worth. This number comes into play when the feature is picked up.

… then take the time to build.

We have experienced first hand how a work item that is not finished in its sprint has a cascade effect on the subsequent work items, impacting their planning as well as their quality. In order to build a feature first time right, there must be given ample time. Therefore, just like Shape Up, we use 6 weeks of full-on development time: this is our Focus Mode. The Feature Council & General trust the development team (or Squad) to develop the features in time, and will not inquire or attempt to influence the result of Focus mode.

A tale of two cycles

The two paragraphs above made it clear that there are two separate tracks at play: a formative track where the Feature Council designs and specifies features, and a hands-on track where the Squad realises these features.

Hold the door

In many ways, the Gatekeeper is similar to Scrum’s Product Owner. However, unlike a Product Owner, a Gatekeeper is an integral part and representative of the Squad instead of an outside force ”managing and expressing business and functional expectations for a product”. Ideally, he or she has experience as an architect but it can really be anyone with enough technical background to participate as a full member of the Squad. In fact, we actually switch who’s the Gatekeeper with every cycle.

Synchronous versus asynchronous work

Priorities change. As a result, any planning made prior goes out the window to accommodate the shifted priorities until the priorities shift yet again. That’s why Rhythm doesn’t rely on planning, but allows the priorities change freely. It is only during the negotiation between Feature Council and Gatekeeper that a plan for the upcoming 6–9 weeks is established. Any planning beyond 9 weeks is — as far as the Squad and Gatekeeper are concerned — non-existent. The Feature Council is responsible for prioritizing the work we know we have to do at some point in time and offering it to the team before it is due. This is the synchronous work: known work that follows the steady momentum of analysis, design, specification and development.

Keeping the quality

The start of Cooldown is the moment when QA people (fancifully dubbed the Monitors) start testing the results of this cycle’s development work. They have 3 full weeks to find issues with the work and report it to the Squad to fix. Fortunately, since Cooldown means a period of relative rest for the Squad, they’ll be able to address these issues immediately and iteratively with an immediate feedback loop back to QA. At the end of Cooldown, the Squad will have a new release with new features fully tested and approved.

Wrapping up

We tried to take the best of each product development method we tried or investigated, and molded it into someting that should work for us.Instead of trying to shoehorn ourselves into a widespread method like Scrum “because it’s the thing to do and everybody uses it”, we formed a method around the practices that demonstrably benefitted us and our industry.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Max Steenbergen

Max Steenbergen

Design lead for marine automation and product management enthousiast