Agility? We tried it! Does not work! – Part 1
Why that can be true: An overview in several parts
I’m sure you’ve heard of that “agility” or “agile” (sic!) everyone’s talking about. Maybe you have even tried “it”. And maybe you also have the feeling that after years of euphoria the voices of critics and skeptics are getting louder again lately? So was everything just hot air, just another one of many management methodes that come and go?
Personally, I am convinced that agility is more than that. But where does this current headwind come from? Why do many companies fail to become more agile?
There are many reasons why “agility” does not work in companies or does not bring the desired success. And it’s worth taking a closer look: Is it because agility is simply the wrong approach for the respective situation and the desired result? Or is it because agility would be the right approach, but the parameters or mistakes in implementation led to failure?
Attention: Under certain circumstances this insight can be vital for the survival of your company!
If you discover that agility is (currently) not helpful for your company, then you can tick off the topic in good conscience (for now) and turn to the more important things for you – which, by the way, is in itself an important aspect of agility: focus, focus, focus and topics quickly complete!
If, however, you realise that your company seems to need to become more agile in order to (continue to) be successful in a changing market, you might want to tackle it again. You can rejoice: You have won a second chance! Use it! Learn from your previous failure, agile. And maybe you will also find some inspiration in this article.
Apropos – maybe you noticed it in the title: This is the beginning of a small series, currently I have three articles in mind. I would like to discuss some typical misunderstandings, problems and obstacles that I experience in practice, and give one or the other hint how you can do it better. But – you may suspect it – there is not one universal solution, no “best practice” and no recipe for a successful agility! If such a thing existed, these articles would not be needed and I would not have so much to do as an agile coach and companion of transformations. 😉
You back the wrong horse, Part 1: Agility can’t do you any good!
Simon Sinek spoke “Start With Why!” and this also applies to the question of whether it makes sense for your company to rely on agility. So why should you focus on agility or what is agility the right approach for? And why not?
Agility in general and Scrum as the most widespread agile framework in particular, are approaches for successful handling of high complexity, high dynamics, ambiguity and uncertainty. Some also call this situation “VUCA“.
So if your company is in a highly complex/dynamic environment, or if there is a danger in the foreseeable future that your market environment could develop in such a direction, then agility becomes a success factor and perhaps even a prerequisite for survival in the market!
Conversely, if your company is in a stable market environment, if you can predict well which products will be successful, if you can plan quite reliably and if success depends above all on price, then agility is not the right approach for your company.
And agility as an end in itself or “because everyone is doing it now” is, in my opinion, not only doomed to failure, but pure waste and can even be harmful: Functioning processes are disturbed, productivity drops and because nobody understands why this change is necessary, the motivation of employees drops.
Worse still, if your situation changes in the future and you realise that you need to become more agile, then you will find it doubly difficult to resist the memory that “agility didn’t work anyway” when you tried it out.
The difficult thing is that the bigger your company, the greater the likelihood that you won’t find a clear answer. With some products you will be able to navigate in calm waters and plan for the long term, with other products you will constantly have to navigate through rapids, and some previously calm waters will suddenly be shaken by an earthquake.
You’ll probably have to differentiate for better or for worse: Use agile approaches where agility is particularly important and effective! (But be careful: this is also dangerous! In one of the following articles I will go into more detail.) And stay alert, the situation can change at any time!
How does that work? What can help? Above all: Talk about it! Regularly!
Often, many employees have had a gut feeling for a long time that long-term planning is less and less effective and that “the impacts are getting closer and closer”, but you don’t talk about it, at least not with the decision-makers, you don’t change anything, you just keep going… until it’s perhaps too late. Then one says: “Well, it was clear to me for a long time …!”.
This must be avoided! And that requires practice, different perspectives and openness!
And there are a number of models and thinking tools that have proved their worth as a basis for working together on this important issue: The Cynefin model, the Stacey matrix and the PAVE matrix. In the following I will use an image based on the Stacey-Matrix for visualisation.
You have false hopes: When efficiency becomes a dead end!
When I hear sentences like “We introduce Scrum to become more efficient” from decision-makers in companies, I regularly get goose bumps. And I understand where this desire and this conviction come from. After all, the title of a very popular book by Jeff Sutherland, one of the inventors of Scrum, is “Scrum: The Art of Doing Twice the Work in Half the Time”. That’s probably not wrong, and who wouldn’t want to: “do twice as much work in half the time”? In my opinion, however, this objective leads straight to the black ice.
In highly complex/dynamic situations, in ever faster changing markets, with ever more inscrutable buyer preferences, with ever new competitors with completely new business models and technological innovations (keywords: digitisation and platform economy), the first thing to do is “the right thing”, i.e. to first find the successful product (the “what”)! And as quickly and cost-effectively as possible! It is first and foremost about effectiveness! And only in second line it concerns efficiency!
What use is it if a company brings a new Smartwatch onto the market at a very favourable price because it has organised development and production in a highly efficient manner, if nobody wants to buy Smartwatches anymore? Perhaps in the meantime it has been discovered that Smartwatches “radiate” and cause chronic wrist arthrosis? Or perhaps a new edition of the Google Glasses came onto the market unexpectedly and “everyone” now wants to have such glasses?
In the face of complexity and high dynamics, the following applies: “effectiveness eats efficiency for lunch” [Eric Wilde]
Of course, agility “incidentally” also ensures efficiency, but that is not the subject of this article.
In fact, maximum efficiency under high complexity/dynamics is also maximum risk. If maximum efficiency means that all employees are consistently working to create value, if everyone is always under load, then an organisation is hardly in a position to react to disruptions. Dynamically microbusy organisations maintain buffers and redundancies and thus the ability to adapt to new unforeseen situations.
You back the wrong horse, Part 2: Agility is more than Scrum!
So let’s assume that your company has to act mostly or often under high complexity, dynamics, uncertainty. Agility therefore seems to be the most promising approach. And you are also aware that under these circumstances you should first and foremost pay attention to effectiveness.
Super! So introduce Scrum across the board and look forward to a rosy future?
That can work. But that would be a coincidence.
First: Scrum is a framework that still needs to be filled. Scrum is very lightweight. The current Scrum Guide contains only 20 pages of content. That’s a great base. But it would be naive to assume that these 20 pages are enough to fully describe how different companies and teams organise their work on products. You are not spared from filling this framework with specific solutions for your context.
A small example: The Scrum Guide states that at the beginning of the sprint, the development team will make a forecast about the functionality to be developed in the sprint. The Scrum Guide doesn’t say how the development team will make this prediction, how it will estimate the scope and content of the sprint. The term “Planning Poker” cannot be found in the Scrum Guide. Planning Poker is just one of many possibilities.
And it is worthwhile to take a close look at these 20 pages, especially if you are not sure about the concrete design. Also a small example: I very often meet experts who are convinced that the product owner has to write the user stories – and on request: only the product owner! That’s not quite right … (Apart from the fact that the “User Story” is only one of many ways to describe entries in the Product Backlog, the Scrum Guide doesn’t prescribe any concrete technology).
Second: Scrum is not always the best choice!
Also here the Stacey-Matrix can help as a thinking tool: If the goal or the customer needs are unclear or if the requirements change dynamically, then I should choose approaches that focus primarily on validating the “what”: Design Thinking, Lean Startup, Effectuation or Business Model Generation could be mentioned.
It would be crazy to start directly with product development without finding out who the customers and users actually are, what problem we want to solve with our product or whether our target group really has this problem and whether this problem is really relevant for them? Is it? And yet it happens every day! Most innovations fail because a lot of time and money is wasted on developing products that nobody will use, let alone pay for.
Kanban is a special case in many respects! On the one hand you have to distinguish between Kanban in lean manufacturing and Kanban for software development (and change projects). On the other hand, Kanban is even lighter and therefore more variable to use than Scrum. A typical application of Kanban is the control of less complex tasks in a standardised process. Another scenario arises when (former) Scrum teams replace the sprint cycle with continuous development and delivery. Or Kanban is used to control the collaboration between teams and in the overall portfolio.
And to make it even more complicated: All this can be combined with each other! Of course, Scrum teams can also use a Design Sprint to quickly learn about customer needs and develop a prototype for a new idea. You can use pretotyping at any time to validate hypotheses without much effort. You can use effectuation tools according to the situation and, for example, set up a joint inventory of resources in order to find new approaches on your own. Many Scrum teams work in predictable sprints on product development and use Kanban in parallel to organise unplannable ad hoc tickets. Etc.
As sorry as I am: Unfortunately there is no one-size-fits-all. Every organisation is unique and complex. And there can be no best practices. Not even with Scrum. I think Scrum is a very good starting point for gaining experience and finding your own solution step by step. You are also welcome to be inspired by other organisations. However, if you simply copy solutions that work well in other companies (such as the so-called Spotify model), you shouldn’t be surprised if your own organisation squeaks and creaks and worse.
Another tip: Whenever you are unsure whether a method, a technique, a change etc. is still “agile”, look into the Agile Manifesto and talk about it.
Outlook
In this first article, the main question was whether agility is the right approach at all and if so, which concrete approach could fit which situation. I hope I was able to give you some helpful impulses.
The next articles will focus on typical problems with the implementation and design of the implementation and use of agility.
Notes:
Here you will find additional parts of articles on Agility? We tried it! Does not work!
Agility? We tried it! Does not work! – Part 2
Agility? We tried it! Does not work! – Part 3
Agility? We tried it! Does not work! – Part 7
