Agile and Scrum have become buzz words that are frequently thrown around. But when should you use Agile tools like Scrum or Kanban? And just as importantly, when should you not use them?
The best way to explain this is to take a look at four different situations. We’ll look at McDonald’s, a building, software, and an emergency room in a hospital.
McDonald’s is a huge brand with a very specific list of food you can order. They have a well-defined menu of things you can eat.
This methodology was developed by the ITIL framework that’s used by a number of industries. It was created by the UK government as a means to control companies providing services to them.
In this methodology, there are a number of services that you can do, but if it’s not there, you can’t do it.
One of the most important things we have about Agile is change. You start by creating something small, which is called the minimum viable product or MVP, and you take it to the customer or stakeholders to see whether you’re on the right track. If you get good feedback, you continue, if not you stop, and try something else.
This feedback is very important. If you’re not able to change something, then why use Agile in the first place? So Agile wouldn’t work in a fast-food chain.
Now, imagine a building, like a skyscraper. You draw up the plans, set the foundations and architecture so that it won’t fall, and then you build the whole thing. Afterwards the people move in, but you didn’t ask them what they wanted as you were building. These users only see it at the end.
This is called Waterfall, an old form of project management which was popular 20 years ago.
It did work and still does. Waterfall is what took man to the moon. There are projects that work very well with Waterfall. Titanic and Boeing planes were built this way. So again, Agile wouldn’t work here.
For developing software, Scrum as part of the Agile methodology is the way to go and is, in fact, how we work at Blexr. We create something small to show it to someone, we get feedback and adjust accordingly.
This is one of the main premises of this framework. I show, get feedback and adjust.
Scrum presumes you have a plan for the sprint, which (normally) lasts two weeks. You start with sprint planning where you plan your entire sprint, and you demo the product at the end of each sprint to obtain feedback. The cycle then repeats itself.
A critical skill of the product owner – one of the three roles in Scrum – is to say no, so that the team can stick to the plan without interruptions. You can say: “We’ll plan for the new idea for the next sprint, but it certainly won’t happen now.”
Since sprints are just two weeks, so they won’t have to wait long for their ideas to come to fruition. There should be very few things that cannot wait that long.
What happens if you cannot plan? Picture the help desk at an A&E hospital department. The doctors there don’t know what to expect when they come into work, be it a terrible car accident, or a woman in labour or a sick old person.
This we call Kanban. It’s Agile in the same way as Scrum, but without the planning. Here we don’t plan and we’re completely reactive. Teams which don’t have any means to planning should go with Kanban. The critical thing is to make sure that you are working according to the correct priority – just like in the A&E department. If you’re not able to change at all, then Agile is not for you.
Kanban teams tend to act as support because there are infinite responsibilities to requests which you cannot plan for. Microsoft Windows crashes and you call support to fix it, for example.
The problem is, Scrum and Agile have become a buzz-words, and everyone wants to work in this way. But the truth is, it just doesn’t work for everyone. Many of the mistakes companies make is they want to be modern and work in Agile, when in actual fact, they’ll be better off working in Waterfall. If you try put a round peg into a square hole, it just doesn’t quite fit.
The most important question to answer before embarking on any transformation from Waterfall to Scrum or vice versa, or even on a larger scale, from Scrum to SAFe, is “Why am I doing this? Is this really what I need?”.
This transformation might turn out to be useless. A couple of years down the line, you might realise this is not what your company needs to excel. So think carefully about which method of organisation will be best for whichever way you and your team like to work.
Once you are convinced that it is really the way to go, remember to regularly ask yourself “Are we going in the right direction?” In true Agile spirit, inspect and adapt everything – even your Agile transformation!
Good luck on your journey.