Is Agile the common sense we lost when building perfect plan/build/run silo organizations in the past? In contrast, Agile Cargo Cult – blindly following Agile frameworks – is common too. But without any sense. Agile is so easy and difficult at the same time.
Agile and New Work have gone many BS directions in the past. Because the marketing label „Agile“ sells on the market, it can be anything. To the joy of many Agile Dislikers, because this BS gives Agile a bad name.
People often forget that Agile is nothing new at all: Agile, as the ability to be adaptive, to continuously reflect & learn and to take responsibility as a team for a product or service, the customer in the centre. The point is simply that Agile has become much more relevant for success in a VUCA world (Volatility, Uncertainity, Complexity, Ambiguity) and more important, in a world where employees find motivation in purpose and autonomy. Agile principles and frameworks (which have decades of history, too) can help us adults to avoid total chaos, by providing some minimal structures and guidance around that. They can help balancing stability and flexibility on a very high level. But they are nothing worth without the right growth mindset in place and continuously reflecting & adapting your own structure to make Agile work for you.
Time to bring back some common sense to Agile!
Common sense is not so common
Sometimes we have to learn things the hard way. So do I. Five years ago, when giving a product owner training to a mid-sized bank, I asked the following naive introduction question to the participants:
„Whom of you belongs to BUSINESS, whom of you to IT“?
Of course this was a catch-22 question, but then something unexpected happened. „This is not our way of working. Business and IT are usually both in the same team, we are one team, taking jointly accountability for a product with close collaboration and short feedback loops„. Needless to say they where very successful with that model and had a pretty clear governance behind it, but not bound to functional silos.
They really got it. This is how it should be. Agile common sense. This is what I was thinking to myself afterwards. One problem of my naive question was of course, that I presumed a common sense (the one of a traditional bank), which did not apply in that case. My first learning; Be cautious with common sense. Or as the brilliant French philosopher Voltaire said „Common sense is not so common“. Second: They effectively adapted one aspect of Agile, as a means to make an impact as a company: Close collaboration and feedback, one team culture, end-to-end along a product and the value stream behind it. Motivated people with purpose, because they are directly bound to what creates value (product/service) instead of being the functional purposeless cog wheel somewhere in the company.
Many facets of Agile common sense – all about customer and employee value
So what is Agile common sense? Above example shows just one aspect. But there are many other examples:
- It’s common sense to show something early to a customer if he doesn’t know what he wants. Early feedback and doing the right things early or otherwise loose millions of $$$
- Having plans is good, but sometimes you have to change these plans. Makes sense, right?
- What is the right way of working for us? It’s common sense to regularely retrospect the past, drawing learnings from it and apply changes to the future. Theoretical concepts will not survive first reality check, but can be a first step.
- Sometimes we don’t know what is beforehand the „right way“. But we have a hypothesis and need to and validate it, through experiments. There is no other way to find out.
- Leaders can’t know, too. But they can give a vision what we want to achieve and work with hypothesis.
- Motivation is a multiplier for performance an it makes sense that you organize people & teams around what motivates them: Autonomy and purpose, as endless studies from the last years show. Therefore autonomous product teams instead of functional silos, which have maybe perfect processes, but no individual purpose, many handovers and no flow.
- Agile does not stop at Development, it’s common sense that we should look at how value is created end-to-end. From inception to Operations, with feedback loops incorporated everywhere. This is also where DevOps comes in. For some reason, many people still think Agile is limited to software development.
- Besides all the autonomy, it’s common sense that we have to align, where autonomy is suboptimal. E.g. bring together all the Product Owners on a regular base, to develop good practices, that work in your company.
Implications for a successful Agile Transformation
Transformations are hard, take time and real culture change comes last. Looking at Agile, in a common sense way, can help you to be successful with that.
Start with the Why – in a tangible way. Include the „What’s in it for me?“
Starting with the Why is an advice you might already have heard of. It’s easy to do it the wrong way. Although many companies start indeed with the „Why are we doing this?“, I read often sentences such as „Agile will help us to succeed in a changing world“. This is just too generic and not tangible enough. It’s not common sense enough. Think about the examples in the bullet points above, adapted to your environment and with examples of the past where you missed that, with negative impact. This will make it tangible and senseful for everyone. What exactly is the customer impact and value you want to make with Agile? Agile is a means to an end.
What makes sense for the company as a whole doesn’t necessarely make sense for the individual employee. So „What’s in it for me?“ is a question most companies miss to answer. Will it make my daily work better? There are many fears around around that. Think about purpose and autonomy, which I mentioned already and are btw the #1 motivators, why employees come to work – according to many studies during the the last years.
You can only change culture through action. Common sense action.
At the end, nice words will not change culture and the way we work . It’s „doing things“, experiencing, seeing the benefits and learning from them, which change culture over time. People don’t resist change, they resist being changed. And people don’t resist their own ideas. This is the key for successful transformations and I found in particular the following instruments useful:
- Promote desired behaviour through servant-leadership and asking the right questions, instead command-control. People will come up up with the rights answers by themselves.
- Hold people accountable. Autonomy and purpose in form of self-organized end-to-end product teams is a privilege, but also an obligation. People have to show Skin in the game – no „this is not my responsibility“ anymore.
- Establish a sense of continuous learning. Most people think here about regular formalized retrospectives, but it can be any opportunities to reflect the past and make improvements real. On all levels – individual, team, program, leadership.
- Immersive experience in a „safe-to-fail“ environment: For example through an Agile or DevOps Simulations. People experience by themselves to retrospect, apply agile ways of working and see the results directly.
- Going with small steps in the transformation and incorporate learnings. Yes, you can make the transformation itself agile, too. Good practice comes from experience. Experience comes from bad practice.
Understand how to use agile Framworks the right way
As part of my job I give all kind of trainings, even with certification. I could now tell you they will solve your problems, but I won’t. Agile transformation is mainly a cultural thing. One thing I learned over time is that agile frameworks are mainly here to build some structure around our wish to be agile. Otherwise there will be total chaos and inefficiency. Scrum has here some good examples; Although the backlog is open for change at any time, the sprints should be rather protected. This helps to balance flexibility and stability. Same for the need of a clear product vision, which gives some long-term boundaries. Imagine this would not be the case – things would just change every day. Some call this Agile, I would call it chaos.
Look at agile Frameworks as a starting point – methodically. Adopting & adapting them is key, continuously. For example, Scrum and Kanban are different starting points methodically, but you can end up at the same point after a while.
When things get more complex – focus on reducing complexity, not managing complexity
Successful transformation is supported by the top and grows from the bottom. It’s a journey and you will face many challenges and obstacles on it’s way: All kind of dependencies, monoliths, an so on. One fallacy is that we often try to manage complexity instead of reducing it. Putting all kind of processes, handovers and heavy governance „on top of Agile“. You will end up where you have been before, loose all Agility and the impact you wanted to achieve originally. The famous „Water – Agile – Fall“ is just one example. Instead, build the whole system in a way that this becomes obsolete: Decoupled architecture (business and it architecture), infrastructure as code, the rule of small teams and scaling agile principles program and portfolio level. A topic on it’s own!
Finally, I hope this article gave you some new insights and helped you to regain some common sense. Looking forward for feedback!
Do things that make sense. And hey, Agile is just one means to and end. It’s impact that matters 🙂
