Setting the scene
The agile wave has been rolling for more than 20 years now. It probably started as a reaction to the “old” bureaucratic, and heavy-weight project management methods and standards that at the end of the day could not guarantee project success despite their clear guidelines and roadmaps.
For many years Scrum has been the most widely used agile approach. Personally, I started on my own agile journey more than 10 years ago, and at that time, when someone mentioned agile, Scrum would be the next word coming up.
Back in the nineties when the agile movement started to gain momentum, Scrum was not the only method or framework, but it ended up being the one making it big on the global scene.
During the past many years, I have spent thousands of hours teaching Scrum, Kanban, and agile project management. I have written books and articles, given public speeches, and not least worked on numerous agile assignments in various roles.
I mention this to emphasize that I am not “married” to any particular method or framework (though I do have my preferences). I understand most of the ins and outs of “agile”, and I know from hard-earned practical experience that a one-size-fits-all model does not exist. Even if zealots may insist otherwise.
History repeating itself?
In the past few years SAFe has become increasingly popular, and I can understand why it seems so compelling. If you experience many of your projects failing, being delayed, or breaking the budgets, it is very tempting to start using a framework that seems to have everything covered. In SAFe most of the clever thoughts that have been thought over the past decades in the lean-agile space have been combined.
Lean, Scrum, Kanban, XP, DevOps, Lean Start-up are all part of SAFe, just as it has borrowed the Scrum Master and Product Owner from Scrum. On top of that, several new concepts and titles have been introduced. E.g. “Agile release trains”, “Solution trains”, “Release train engineer”, “Program Increments”, “Innovation and planning sprint”, and more.
This makes SAFe a highly complex model, and in fact it adds significant complexity on top of something that is already complex, namely, IT projects and programs. I would argue that this can only work in high-maturity organizations. To be honest, I still have not seen any organization applying more than a few of the elements from SAFe. They use those that are easiest to grasp.
These days I hear people asking questions about Scrum. Why is Scrum not the easy fix, that we hoped it would be? Why do we not see continuous improvement, as we expected? Why has our Scrum come to a stand-still, even though we are doing everything “by the book”? “Why do we have to go to all these meetings. We feel that we are wasting our time? Why are we still late? Etc. etc.
I have no doubt that similar questions will be asked about SAFe sooner or later, when people realize that they have bought into a wonderful but highly complex dream that cannot be put to life unless you (as mentioned before) are working in a highly mature organization.
Just as the agile pioneers turned their backs to the classic methods, I could imagine that there might be a movement away from agile frameworks that are either too loose, so you have to figure too much out for yourself or too rigid and complex, which makes it too demanding for organizations to make it work.
I am not implying that Scrum and SAFe cannot work, they absolutely can. However, there are several organizational requirements and prerequisites that must be met to get success with Scrum or SAFe. Most being of the more invisible kind such as culture, maturity, behavior, discipline, habits, change readiness, politics, values, and such. But what to do if these prerequisites are not met?
Well, luckily there are other (and simpler) paths to agility. More about that in a short while.
How do you get from feeling agile to knowing that you are?
As mentioned, IT projects are almost by definition complex. Therefore, you should do all you can to minimize this complexity, as it makes it easier to keep your projects, programs, or assignments under control. Again, this is where Kanban comes into the picture.
One of the main reasons to “go agile” is often poor project performance, and the classic way of managing projects is often blamed for this situation. However, projects do not fail because of the method you use or your Project Managers for that matter. They are probably well-trained individuals. It is more likely due to lack of organizational or team discipline, lack of needed competencies, and low project maturity, probably combined with several of the other aspects I mentioned above.
However, no agile method or framework can change or improve that. Only people can. But changing organizational culture, behavior, habits etc. is not easy. Most people would prefer to avoid changes if they could choose because it is hard work and requires conscious action. It is much easier to keep on doing what you always did.
That is why simplicity is key. It is much more likely that you will see changes happen if you take a simple path. It also helps if you are very explicit about what you want people to change. What do you want your colleagues to do tomorrow that they did not do today? The Kanban method offers this simplicity, and clear directions, and it offers a path to agility that can start small on the team level and expand to cover the whole enterprise as you become more ambitious.
On social media you often see people cheer about their agile achievements, and I have been working with quite a few agile teams that claim that now they are much more agile than they used to be. I can’t help but ask them: “How do you know? Did you measure it, and can you compare old and new results?”. Sadly, the answer has never been “yes!”.
Feeling agile is probably a rewarding feeling, but if you cannot back-up that feeling with data, there may not be so much to celebrate. If you can back it up, I will be the first to cheer with you. But how to get to the point where you know that you are moving in the right direction, and not just feeling it?
Again, I will point to the Kanban method, and let me explain why.
How Kanban can facilitate improvements in Scrum or agile teams?
I have mentioned that it is quite easy to get started with Kanban. First of all, you do not have to change your organization, and that alone makes it simpler. So, if you are organized according to Scrum or SAFe, you just stick to that organization. But you top it up by working with some (or all) of the 6 general practices in Kanban:
- Visualize
- Limit work in progress (wip)
- Manage flow
- Make policies explicit
- Establish feedback loops
- Improve collaboratively, and evolve experimentally
If you are producing knowledge work, i.e. something that is not a physical thing, you can use Kanban to control and improve your services delivery.
Let us take Scrum as an example and look at how a few of the Kanban practices can be put to use to improve performance. Scrum Teams usually work with a minimal workflow. Often: “To do”, “Doing”, and “Done”. Kanban takes the workflow several steps further and visualizes what is actually happening end-to-end.
Are you analyzing what to do before you really start working on your task? Do you have a QA or testing procedure? Does it involve your users? If yes, your workflow might look like this: “To do”, “Analyze”, “Develop”, “Internal test”, “UAT”, and “Done”. This is one example of visualization. In this case an invisible workflow has become visible.
You might also visualize what is blocking your progress, and whether you can do something about it or not. You might visualize how much time an item has been blocked, what actions you have taken etc. This also helps create transparency which in turn gives you a healthy basis for decision-making. Decisions that will help you minimize the negative consequences of your blocked items, and result in reduced lead times, which ought to be what any team or organization should strive for.
Limiting wip is also a key to shorter lead times. The fewer activities you have in progress, the quicker everything goes. You can simply complete more in less time if you facilitate focus and less task switching by limiting wip. This can be done in any kind of team, and you can still work with time boxes, such as sprints if you prefer to. That is your own decision.
The same is true for the practice, manage flow. If you keep an eye out for tasks that are sitting idle in your Scrum board or have been blocked for some time, and manage these tasks proactively, you will …. Yes, you guessed it.… reduce lead times. In fact, this is also one of the ways that Kanban manages risk.
It would be taking it too far to go through all 6 practices, but they all boil down to the fact that there is much to gain if you succeed in reducing (project) lead times. Stable velocity or good estimates that drown in organizational “dirt” do not tell you much about your performance whereas lead times do. They clearly indicate if things are moving in the right direction. In a more agile direction.
With Kanban there is no wishful thinking, no crystal balls, or wild guesses. Kanban is data-based, which means that you act on facts and with your eyes open. Facts like actual lead times, facts about how long activities have been blocked and why. E.g. when waiting for a specialist, a decision, a 3rd party vendor etc. Applying good Kanban practice to your Scrum or Agile Team will help you increase transparency and improve efficiency.
I think of it as holding a mirror up in front of your team or even the entire organization, so you can see what is actually going on. Both good and bad. This makes it possible to determine where you would benefit from adjusting your system, your behavior etc. and improve one step at a time. Evolutionary change is more likely to stick and become good new habits.
High transparency can be scary for some, and it can be difficult to accept that there will always be something to improve. Reality may show that you are not as efficient that you would like to think, but the good thing is, that now you know so you can do something about it. Ambitious agile teams should welcome transparency and be ready to fix what does not work without annoyance, finger-pointing or blame games.
A few final words
I have given you a few examples of how the use of some of the 6 general Kanban practices can help Scrum or agile teams to improve their efficiency. There is much more to Kanban than this, but it would be very efficient first steps to bring these practices into play.
It would be a powerful yet simple path to higher productivity and agility without stressing or disrupting your team or organization. Why not give it a try?
