Originally published in March 2018 here

Developing software is hard and requires a different approach than developing other projects. This is the lesson all organisations had to face when they tried to apply the traditional “waterfall” method to software development. Luckily in 2001 a methodology emerged: “agile” in which the team is empowered to constantly adapt to new learnings and change the plan accordingly. Sounds good but there are 1000 different ways to do “agile”. In this article I want to give some recommendations in which situation to use which type of agile software development. Totally non-scientific, purely based on personal experience and opinion. Happy to discuss :)

The first choice you have in almost every software project is if you want to use Kanban or SCRUM as a general approach. In my opinion the biggest difference simply is how much planning ahead you are doing. So when will which feature be done/available/released? Here is a quick overview:

• Waterfall: Plan ahead the full project in detail. Exactly “know” when what is available. Fail because you are not superhuman and nobody can plan ahead that well in software development ;)
• SCRUM: Plan ahead the next sprint (e.g. 2 weeks) in detail. Rest is planned only on a very high level. Have short term plan fixed. Be prepared to change long term plan.
• Kanban: Don’t commit to feature availabilities at all. Just agree on order/priorities of Todos. They are done when they are done.

Since we all agree anyway that Waterfall is not a suitable approach to develop software, I will concentrate on SCRUM vs. Kanban in the following discussion. Both of those approaches have their pros & cons:

SCRUM Pros:

• Team commitment towards sprint deliverables ideally leads to a “let’s get this done” mentality in the team which magically increases productivity in the last few days of every sprint.
• Often you have launch dates and/or other (external) milestones. SCRUM makes it easier for Product Management to track if the team is on track to deliver towards that goal
• Since management can easily see & test outcome, it can be less hands-on in individual team management. As long as the sprint goal is met there won’t be any discussion if engineers can go home early, leave for a conference or whatever. As long as the team delivers on the result, management does not need to care about HOW they achieve it.
• Ideally leads to the engineers making suggestions to scope the feature down and achieve the same user value in an even simpler form

SCRUM Cons:

• Sprint Planning & estimation can take a long time. Pretty big overhead - up to 1 day needed to plan & commit to a sprint goal.
• Even for a shorter times like 2 weeks it is really hard to plan properly - this is also one of the reasons this may be stressful for the teams. Especially if the venture has high technological risk or an inexperienced team.
• Less flexibility. Especially in earlier phases of a new project things still change a lot and having a fixed sprint for 2 weeks may lead to management “opening up” the sprint and then missing the point of SCRUM. Also if your design team is 2 weeks ahead of the engineering team you need up to 4 weeks to implement a feature.
• If teams miss the first few sprint goals (and get pressure from their PM due to that) they will not like it. (Pro tip: always start with “small” sprints and let the teams feel the success of achieving a sprint goal).
• Only works good with teams of up to about 10 people. If your team is bigger you need to split up teams and need a “CPO team” which coordinates. (Rule of thumb: if your standup takes more than 10-15 minutes you need to split up teams!)

Kanban Pros:

• More flexibility - new learnings can be immediately put into new priorities
• Easier not to fall into the trap of viewing engineers as an “execution” department. You have more interaction with designers & PM on a daily basis. Easier to do “feature teams”.
• Less overhead planning - you can just start working - you get stuff quicker through the door
• Less overhead - you can use simple tools like Trello (and not more complex ones like JIRA)
• Better for fine tuning & bug fixing phases of a venture where things to be done pop up on a daily basis.
• Does not need a super capable PM who can plan good SCRUM goals.
• Allows for more iteration on product if things pop up while you are working on it. So theoretically you can have better quality
• Scales better than SCRUM teams with more people on the team

Kanban Cons:

• Harder to plan ahead and to know when features will be ready. Yes you have a velocity but it requires a lot of discipline on the PM side to keep an overview. The beauty of SCRUM is also that it also forces the PM to plan ahead properly.
• No final spurts towards the end of sprints in the teams. Very easy to lure itself into sleep. Less sense of accomplishment “achieving” a sprint every few weeks.
• Very easy to miss the big picture. You do one small ticket after the other and keep iterating features (but miss building the greater overall roadmap)
• Very easy for management to micro-manage team. Since team does not commit to outcome/deliverable, management will have tendency to try to control how time is spent.
• Since engineers don’t have a fixed deadline for completing features they may end up overengineering them

So when to use which approach?

In short: it depends on the team working on the software and the technological/design risk of the project. There are all shades of grey in between as well but for the purpose of this article I will oversimply a little and make this bold statement:

• When you need to build a known feature set SCRUM is the better choice
• When you don’t have a known feature set yet Kanban is the better choice.

Let’s take a more detailed look at this.

SCRUM for the “Feature Build” phase

As discussed this is best used when you are in the Feature Build phase of your project/venture. In the graph above I called this a phase with “low tech / design” risk. You know what you want to build. You know how to build it. You mostly “only” have to execute it and get it done.

In the Feature Build Phase you should always create a high level roadmap with milestones / goals every 6-8 weeks. These goals are not on a ticket level (this would be waterfall) but rather on a epic/objective level. You can then break down these milestones into sprints. The upcoming sprint can be planned in detail on ticket level - the future sprints stay very rough and are continuously refined once you have learned more.

The execution of those sprints then strongly depends on the team you are working with.

A low maturity team needs deadlines to perform well. It is further defined as a team which is not really interested in (or not able to) to shape the features to be built.

• In this setup you should do a traditional SCRUM approach. Design teams are one sprint ahead of the engineering team and work mainly separated. PM acts as oversight and drives development.
• PMs specify individual tickets with acceptance criteria. Designers & engineers mostly execute.
• At the beginning of each sprint engineers & designers estimate tickets on the ticket level. This is to estimate what can be done in a sprint but also a check for PMs to see if engineers & designers understood what they are supposed to do.
• At the end of the sprint management will push teams with “crunch time” to deliver if needed.

A high maturity team likes empowerment, wants & can contribute to feature development. For this kind of team I am recommending something I call “Flexible SCRUM”:

• At the beginning of each sprint the team creates “feature teams” with engineers, designers & PM. Do feature kickoffs with everybody involved. Still designers will focus on design and engineers on developing the feature but you work closely together from beginning to end. This is worth it if the engineers want & can contribute in the design phase and can help scoping the feature. Goal: achieving a similar user value with less engineering effort.
• Engineers & Designers are mostly writing their own tickets based on the goals / objectives provided by PM (which came out of discussion with whole team).
• In Flex SCRUM it is not really necessarily to commit on a ticket level in a sprint. So you don’t expect all tickets to be completed until the end of the sprint. The team commits to the goals of the sprint to provide a certain user value (e.g. release a version of a certain feature in the best quality possible). It is then up to the team how to achieve that user value in the given timeframe.
• Therefore it is not required to do a sprint estimation on a ticket level. You can simply do a “goal estimation” only with the feature teams and/or leads of the team. This reduces one of the main drawbacks (=overhead planning costs) of traditional SCRUM.

Kanban for the “Figure out / Bugfixing” Phase

Kanban is the better choice when you don’t know yet what you want to build, when there is a high tech- or design risk involved (which makes it useless to estimate) or when you are in the finetuning & bugfixing phase where new (important) tasks pop up on a daily rate.

Independent of the type of team you are working with you should always set & communicate “focus areas” when you are in this phase. Examples can be “This month we will do Finetuning / Bugfixes”, “Optimize Onboarding Funnel” or “Optimize KPI XYZ”.

For high maturity teams you want to choose a Kanban style which gives a lot of flexibility to the team. So the team should be able to mostly pick & choose tickets on their own. The PM simply does a regular grooming session with the team to discuss priorities and is available for questions on demand. High maturity teams can be pretty much self-organized. It is much easier to do Kanban right if you have a high maturity team.

Low maturity teams require very direct & active management. You need to set expectations regularly when you expect what to be finished when. PMs will have to continuously provide acceptance criteria and work on the tickets. It is very hard to manage a low maturity team effectively in Kanban and is not recommended. Rather use traditional SCRUM then.

Summary

A typical venture/project should start with Kanban while you figure out what to build, then turns into SCRUM during the feature build phase and evolves back into Kanban when you do finetuning & bugfixing. Live Ops of software products are also mostly better done in Kanban when you don’t develop major new features anymore.

So depending on the phase of your project and your team you will end up using different approaches. Therefore it would be good to have a team management tool which supports both types properly. So what are the best tools for the job? I may write about the choice of team management tools in an upcoming post :)

‍