Introduction to the Agile with Architecture series (1/7)
Agile has come under fire. Matthew Kern, in his “Agile is Dead” post argues that Agile as a marketing term for selling consultancy services has already peaked. His post spread like wild fire.
Matthew Kerns is showing us where it hurts. I recognize the image that is conjured up in the “Stop being so Agile” post. Agile is being adopted as a new organisational paradigm, but not because of its fundamental idea about what you want to achieve with Agile.
It makes no sense to suggest that a method alone can lead to success or failure. Cooperation between people is and always will be decisive. The idea behind a methodology can help make you aware of limitations in the way you work together and can lead to you developing a shared style of communication.
Agility is what is badly missed within organisations. Data is currently changing everything and lots of organisations are working full on to keep their heads above water. By the time a project has been delivered, its business case is no longer relevant. Reorganisation after reorganisation are taking place, with little effect. Methods such as Scrum and SAFe are being adopted out of desperation and implemented on a broad scale.
What a lot of people fail to see, often unconsciously, is that organising agility in an organisation requires a different way of thinking and acting. It is more of a cultural change than just adopting a number of rituals and procedures. I am convinced that Agile’s basic premise is of great added value precisely at this time, but also that it is very difficult for a lot of organisations to implement.
Why is it so difficult to make an organisation structurally agile? In order to find the answer to this question, you need to understand what agility means for an organisation. I think that agility requires forward thinking. Not in the sense of a crystal ball, but by constantly scanning the environment and the impulses which reach the organisation and processing them into possible alternative directions to develop in. The trick is to let a new direction go if you realise that you are on the wrong path and then to jointly find another one.
It is exactly this letting go that a lot of organisations are wary of. A decision has finally been taken based on blood, sweat and tears, a project has been set up, a course altered and then we realise that we need something else. This is no unique accident, it is a constant undercurrent.
You can also look at it differently. The ability of an organisation to re-tread its steps needs a different kind of management than we often see now.
Setting up governance for agility partly requires a change in culture and partly another way of organising responsibilities. If agile has been selected as a method, it is only ever an instrument; the real challenge is in changing the way you develop and manage your information services.
Data is the driving force for change, it has an increasingly volatile impact on information services and this requires a change in the alignment between Business & IT.
Implementing an agile method, without fundamentally changing the way you think about managing your business processes is like throwing good money after bad: it is more of the same with a new sexy job title on a business card. The change often goes no deeper than standing in front of a whiteboard every day with brightly coloured post-it notes. The governance stays the same which means so do the results of the development and business processes.
This series discusses one part of what is needed in order to arrive at another way of managing. It looks at the architecture process as part of the governance, aimed at agility and the role of the architect in it. Because, if you set to work cleverly, you will become agile, precisely because of the right governance tactics.
The way in which people work together is crucial in this. An architecture process is no aim in and of itself, but only one of the ways in which you can support the process of working together. Because even if you have set up a solid architecture, how do you then ensure that the operation is agile and effective? Future series will delve deeper into this question.
The choice of focussing on the role of architecture in an agile organisation is no accident. I’m writing about my everyday experiences. This is the work of intelligence architects who have been moulded by agile principles from their very first day at work. This series reflects my own personal and professional opinions and does not necessarily reflect the vision of Free Frogs.