"Why", I love this word and it is probably my most favourite question to ask. It is also a curse at the same time, because if it is not followed by a satisfactory answer I can easily find myself in an unhappy situation.

This summer I decided to look for a new career opportunity and as such I went through many job interviews with various technology companies. Being a big fan of agile methodologies I was keen to learn exactly how their teams work and which processes they follow. Surprisingly, I often heard the same answer. A development manager or CTO would very proudly explain to me that all their teams work in Scrum. I however, was not very impressed with this answer.

All teams work in Scrum? Why?

Do all their projects really have the same requirements?

I doubt it. My guess is that all the teams work in Scrum because of the unfortunate circumstance that Scrum has become the unchallenged prime example of agile methodologies. The issue I have with this is that Scrum does not make you agile automatically. It can be agile when applied appropriately, but only if it's strengths match your requirements, otherwise it might be an impediment on its own.

Essence of Agile

Agile means to move quickly, be flexible and adaptable to rapid change.

If you didn't know anything about Scrum, would it sound very flexible to you if all teams have to follow the same rigid process?

Probably not and hence I ask myself how agile is such a company after all?

Sometimes I hear that an organisation invested a lot into implementing Scrum and therefore is unlikely to change their process any time soon. But hang on, someone invested a lot into becoming more agile and then they are averse to change? I find it a bit strange, because to me agile is all about change.

Fear of losing control

Self organising teams may seem daunting to a traditional manager. This is because managers are generally in charge of a team's process which puts them in control. Luckily Scrum is very heavy in process.

When waterfall became unpopular it was easy to find love for Scrum. It promises to be more agile, but also introduces a lot of new processes such as roles within a team, repetitive meetings, velocity based release planning, monitoring burndown charts and defining sprint goals.

I can see how a traditional manager felt very comfortable with the volume of processes and consequently implemented it across the entire organisation.

Self organising teams

Rolling out Scrum to all teams, making everyone follow the same iterations and maximising consistency in the process leaves very little to no room for self organising teams. At the end of the day there is nothing left to self organise and a team follows the same rigid patterns and reporting schedules as they did before, but now under the hat of Scrum.

Alternatively a much better, or in my opinion a more agile approach would be to say "I don't care how you work". Provide a team with enough coaching to understand the differences in agile methodologies and empower them to pick the right tool for themselves.

The manager can stop worrying about all the boring semantics of a process and focus on more relevant and exciting parts of the business - mainly the results. Additionally this will force a team to make success measurable, which is key in agile software development.

The power of trust

There is nothing more powerful than delegating responsibility to a team. It triggers a higher sense of ownership, pride in one's own work, intrinsic motivation and increase in productivity.

The team is responsible for it's own process and will take any action required to make it as smooth as possible. Situations where a team leaned back and waited for someone else to fix an issue belong in the past!

Scrum is not a silver bullet

Ultimately there is really no reason why every team should follow Scrum. The methodology of choice should meet a project's requirements rather than a manager's capability to control teams horizontally.

This also means that one team may change its workflow if the project changes or if the team switches to a different project.

So which project types are actually benefitting from Scrum?

When to use Scrum

Scrum is expensive

Scrum is a time consuming process. It takes a long time for a team to align their story point estimations and base velocity. Every day stand-up meetings, frequent backlog refinement and sprint planning meetings come with a price as well. A sprint is a fixed commitment and does not allow for any change or interruptions. Highly skilled people spend a lot of time doing secondary tasks which is not very cost effective either.

However, Scrum really pays off for projects which:

• have stakeholders who frequently change their minds
• require a quick feedback loop
• use stakeholders' feedback to prioritise the next sprint
• don't get many interruptions from everyday business
• have a cross functional team

Scrum is great for projects with little baggage

Greenfield projects and projects in their early days are great candidates for Scrum. Stakeholders may have busy schedules and cannot afford to see a team every day. Regular 2-4 week sprint review meetings give them an opportunity to view the latest deliverables, clarify new requirements and define or change the scope of the following iteration.

The project is new, which means there is almost no maintenance work and the team can focus on a few shippable features every sprint. The team is also less worried about filling up the sprint with as much work as possible. Instead they commit to a couple of features which they are confident to present to the stakeholders at the end of a sprint.

The team gets a full iteration to produce value without any interruptions. Anything after that may be subject to change. This is where a sprint really lives up to its name.

The heavy Scrum process is vital to this type of project. Every single meeting and the restrictions of a committed sprint serve a real purpose and are advantageous to the success of a project.

However, if a project doesn't have any of the requirements listed above then Scrum can very quickly become uneconomical.

Waterfall is okay if nothing is expected to change

If your project doesn't anticipate any change then Scrum is certainly an overkill.

You might even question if an agile approach is the right tool at all?

There is no shame to consider a more traditional waterfall workflow for some projects.

If you need to migrate an old C++ library to a more modern language and the library is well documented, free of ambiguity and doesn't need any change then it might be easier to just get on with the work and not faff about with Scrum planning- and redundant sprint review meetings.

Maximum flexibility with Kanban

Kanban is great in many ways where Scrum has its limits. It is a lean system, which means one of it's main principles is to eliminate any waste. There are no iterations, no sprint planning meetings and therefore no story pointing, only one continuous flow.

Kanban is extremely flexible and suits a wide range of projects. In particular it works well for projects which:

• have reached a certain level of maturity with many business as usual tasks, defects and smaller unrelated user stories
• require maximum flexibility and frequent change of priorities
• have multiple releases per week or per day
• have many unscheduled releases
• have less cross functional teams

Mature projects

When a project enters the phase where core features have been implemented and there's naturally less ambiguity about the general course of the project then the advantages of a Scrum driven process will gradually disappear.

This is often, but not necessarily the point when a project has had its first release and customers started using the system. New changes get pushed directly to consumers and enable a new channel for immediate feedback outside of Scrum.

Business as usual tasks

At this stage the project also starts picking up many business as usual tasks such as bugs, minor improvements or 3rd line support from developers.

While these tasks are considered as noise or impediments in Scrum, they are still important and first class citizens in Kanban.

Unscheduled releases

Some tasks or bug fixes are critical and cannot wait for the next release at the end of an interation. Unfortunately Scrum does not facilitate for these cases.

I have seen and practised many workarounds, but none of them are ideal:

• Either a team plans all sprints below velocity to accommodate for the unknown
• ...or the PO cancels the current sprint to deal with the interruption
• ...or the PO removes user stories from the sprint backlog to make room for the unscheduled release mid sprint
• ...or the team simply deals with the event and shrugs their shoulders when they move half unfinished work into the next iteration

In particular when the last two circumstances become a habit then a sprint commitment loses all of its meaning and the team basically cries for a more flexible workflow like Kanban.

Less cross functional teams

Scrum is not very compatible with non cross functional teams. It either results in a lot of friction or in a waste of resources. Kanban doesn't entirely solve the problem, but is certainly a lot more friendly towards specialised roles and distributed efforts within a team.

Work tasks can be divided into several stages with different upper limits on current work in progress. This allows a team to tweak those limits to avoid blockages and optimise a smooth continuous flow.

Another benefit of Kanban is that bottlenecks are clearly visualised on the cumulative flow diagram and therefore quickly highlights inefficiencies or understaffed areas of the development cycle.

Continuous integration

Last but not least, Kanban is a perfect match for teams who aspire a continuous integration pipeline. Process flow and cycle time are key metrics in Kanban and teams iteratively improve on them to deliver innovation just-in-time to the market.

Caveats

Even though Kanban is applicable to many projects it not as widely used as Scrum. Due to it's fast pace it requires a good and robust test automation suite which makes it difficult for many teams to begin with.

Scrumban

While Scrum is a continuous sequence of time boxed iterations, Kanban has only one continuous flow. The repetition of process establishes routine and familarity. A well accustomed team could struggle to adopt Kanban and give up the routine.

This is where Scrumban comes into play, initially invented to help teams with the transition from Scrum to Kanban. In Scrumban a team primarily uses Scrum as their chosen way of work and mixes in concepts from Kanban to allow for specialised roles, work policies and a better flow.

One fundamental idea of Scrumban is to help teams and organizations develop their own set of Scrum-based processes and practices that work best for them.

Which process will you pick?

Back to my initial question, how agile can a company be if all teams have to follow Scrum? It may be possible that Scrum is the right fit for all their projects, but looking at the variety of different methodologies it is more than likely that this is not the case.

Scrum is a brilliant tool, but it is not an all purpose solution to becoming more agile. If Scrum is applied inapproriately it could decrease productivity, as well as frustrate everyone involved with it. Eventually people will end up blaming the process for the inadequacies of the implementor. Let's not stigmatise Scrum like we did with Waterfall.