A few days ago I read a really interesting article by Jan Wischweh. The topic was “The agile crisis”. (It was published on Medium.)
Jan W.’s article was spiced up with quotes by some of the agile heavyweights who back in 2001 signed the agile manifesto. Here are the two quotes, that I love the most. Robert C. “Uncle Bob” Martin says:
1. “An efficient business discipline coupled to an undisciplined engineering team will very rapidly make a mess”
2. “An Agile team will be Agile no matter how the project is managed. On the other hand, a team that is not Agile will not become Agile simply by virtue of a new and fancy project management strategy”
Isn’t that so very true?
How often have your experienced that the focus when it came to IT-projects was almost solely on the Project Manager and the project method? E.g. PRINCE2, PMI or if we are in the agile world (this is where I am most of the time) then Scrum? As if this was the determining factor of project success…
If we take a look at Scrum, the main concern of many (managers and Scrum Teams alike) is to ensure that the Scrum events are held as they are supposed to. They focus on appointing a Scrum Master and a Product Owner (often any will do), and on doing ”the mechanics” slavishly.
But I have to ask: What about the values and the mindset that play such an important part in making Scrum work, and which also, if not primarily, lies on the shoulders of the IT developers? Just to mention a few:
- Technical excellence!
- Customer focus – well, in fact just focus
- Commitment – e.g. to a sprint goal
- Assuming responsibility
Tough value-based prioritization is also ultra-important. This is where the Product Owner and the somewhat extendable concept of ”the business” come into the picture.
And while we are at it, let’s not forget “the Management”. Managers should respect the framework, support their Scrum Teams, and give their Product Owners the mandate to make decisions e.g. about priorities, as they are supposed to know best. (This is only rarely the case).
This is all about how values, mindset, culture, and all the “soft stuff” play an essential part in making Scrum work. But changing habits – sometimes very old habits – is extremely difficult. It is very hard work.
Did I mention, that I like Scrum a lot (when it works), and deliver Scrum training too?
No method (or framework) can save a poor organizational culture or prevent non-constructive behavior
But – and here comes the unpleasant truth – “the mechanics” don’t really matter, if they are all you enforce. A “fundamentalist” practice just for the sake of the practice will give you zero agility. This viewpoint is very well supported by the 2 ”Uncle Bob” quotes above.
Please, could we start increasing our focus on developer and management behavior? The sooner the better, because this is probably the most important part, if you want to get your agile motor running.
For several years I have been deeply annoyed with Scrum zealots, stubbornly insisting that if Scrum doesn’t work, it’s because ”you are doing Scrum WRONG”. This is nonsense. Scrum just doesn’t work everywhere. Neither does SAFe by the way.
In both cases there are prerequisites that must be met. Here are some of the most important points that will determine if Scrum and/or SAFe are realistic options:
- Willingness to change
- Level of competence
- Organizational structure
- The types of work you do and the diversity
- Level of quality
I love ”agile”. I have absolutely seen it work and made it work with my own hands. But it’s not easy. ”Agile” is very much a ”people-thing” and it’s a big change to move in a more agile direction, if you are not the least bit agile already.
If you do decide, that organizational agility is a realistic possibility, and worthwhile pursuing, then you should carefully examine, which path to agility would be the best choice for you. There are several to choose from, but it should be your context that determines the way.
Although you may have a desire to become more agile, the conclusion you reach regarding the above points will determine if it makes sense to go ahead, or if you might as well save your time and money. Depending on the conclusion, some agile options might work, but some will not.
A “one-size-fits-all” method does not exist. Nor does an ”easy fix”. But if you want to take the simplest (and cheapest) path, then there are some methods and frameworks you should simply avoid due to their complexity. Even if they are popular and seem like “the thing to do” because that’s what others do. It pays to not be like agile lemmings.
The only method that I – based on my long, practical experience with “Agile” (and my professional pride and integrity intact) – dare recommend for any organization, team or project delivering services and doing knowledge work, is Kanban. Kanban facilitates systems thinking, systematically manages work and options (not people), and optimizes lead times (aka flow).
Let me tell you a bit more about Kanban for service delivery:
Independent of maturity, you can start small and then sharpen the Kanban knife as you move along and get your processes sorted out, together with your dependencies, blockers, and other killers of efficiency that we all know too well. In other words, Kanban facilitates evolutionary, sustainable change.
Kanban is the “start with what you do now” method. You don’t have to change your organization or fire your Project Managers. Kanban can be combined with basically any other method including Scrum, it scales up and out, and is flexible. But of course you must follow a few (simple) rules to make your Kanban system work.
If you want to learn Kanban, the Kanban-University-way, I invite you to jump on my certification course ”Team Kanban Practitioner”. The 25th February 2020, we are going to nerd ”agile” in the middle of Copenhagen. But until then, I can highly recommend you to read about ”The agile crisis”! (It made me think KANBAN!!)
You can also subscribe to my news letter, (for the moment only in Danish). Then you will be the first to know, when I offer Scrum or Kanban certification courses, etc. And not least when I start up my new agile master class. Of course you will always receive tips, tricks and news about “agile”, and what happens on the agile forefront. No spam. I promise!
P.S. I certainly deliver my courses in English too, so let me know, if you need a company course or just a course in English. I would absolutely love to!