Imagine a big financial or telecommunications company with thousands of employees based in typical centralized services offices with hundreds of branches, and dozens of companies around them acting as clients or suppliers. In this regard, I once heard the following Tom Northup quote:
“All organizations are perfectly designed to get the results they are now getting.”
The organizations he was referring to were rarely designed based on:
Although I admit there are some exceptions, it’s rare to find a company that is both big and old that has grown and expanded its business around an internal reorganization with the purpose of maximizing customer happiness. Efficiency, specialization, optimization and economies of scale are some of the most common concepts used to justify how and why companies today are creating big groups of people commonly called functional areas or departments. Like me, you have probably been at the end of this chain, and how easy would you say it was to think about your client/customer? Not very easy, right?
What I mean is that real Agile works fine. It provides the best results when your people and your organization are aligned with your client, and when see your client as more than a revenue stream. Agile really works well when you are able to put your client’s requirements, concerns, and behavior in the same room as the people who are doing the work.
Nowadays, it is easy find business analysts/partners who are very proud because they are using an innovative technique like design thinking to come up with product innovations. However, when you closely examine this innovative way of working, sadly you realize that they use the output of workshops as the basis for spending weeks or months writing a brilliant specification of an “innovative” product to be realized in several months (hopefully not years) by the delivery teams. This is definitely not Agile.
In most of current companies, we have many people with high capabilities, skills and amazing talent writing – alone or within their own silos – tons of papers and presentations of product specifications based on, for example, knowledge, experience, market trends, etc. What would happen if we were to sum up all these skills and translate them into the capacity needed by agile teams to deliver short-term commitments – that could be verified by real users – faster?
We are not talking about understanding or misunderstanding the specifications, we are talking about the capacity to be part of product definition, validation, and experimentation within a safe environment (open and direct communication with the autonomy to take decisions also in respect of failing). This environment allows us to have people within the teams who share the same values.
True agility needs real value-driven teams, not groups of people who send emails or enormous specification documents from the building of the “business people” to the “production line”, those people working in a dark and sad basement. Well, maybe I am being a bit pessimistic, but just to sum up: remember that one of the main reasons (if not the main reason) to use an agile mindset in the software industry was the need to bridge the gap between the people asking for a system and the people building the system. The language used by these two worlds was so different that the idea of building mixed teams worked really well. I think the language in other industries or functional areas is not so different. Bringing together the people involved is just the first step; making them work like a real team is the next challenge.
Chapter 1: Enterprise Agility – Agile 4 All
Chapter 2: Enterprise Agility – No value, no party
Chapter 3: Enterprise Agility – Finding and managing business process boundaries
Chapter 6: Enterprise Agility – Prioritization, taking an economic view
Chapter 7: Enterprise Agility – Collaboration as a key success factor