Where Agile Conflicts with Bureaucracy?
Let me tell you a story about a company I have once visited, based on the outskirt of the big town — a typical software house.
“We are developing product XYZ here,” a manager welcomes me.
“We have some customers, and they are increasing their demand for our work. However, we are facing a challenging situation. In the past two years, we tried to gain one particular customer, company ABC. Now we have almost succeeded, we are just about signing the contract. However, this customer will take us 60% of our production capacity. And we are unable to recruit anyone here in the area”, he continues. “So we implemented SCRUM.”
“Does it work?”, I have asked with curiosity.
“No, the people are passive. We can increasingly see they do not know as much as we would like they do. We are breaking the tasks into small pieces they can handle. And this truly overloads us”.
“Why is this?“ — my curiosity arises.
“You know, it is because they are only juniors”.
“How much time are they are with the company already?”
“For about two years,” I get the response.
“You said you use Scrum. Do you have deliveries in every Sprint?”
“No, we have issues, so we do not deliver all the tasks we have planned. We deliver perhaps about half of them. All those unfinished, we move to the next Sprint. Well, we are currently fixing the process. It is where we struggle with our people right now. They are just too passive,” continues the manager with a tired voice.
“Can I help you somehow?”, I ask gently.
“Noooo”, and his energy is back for a short while, “we do not believe somebody will help us, so we have to fix it by us. At least the most urgent parts, before we invite somebody for help. But we have a very critical deadline to meet. All our power on this right now, we can’t miss this deadline.”
“I see” — I respond sympathetically. “When is the deadline, by the way?”.
“About eight months from now….”.
(*this story is fictional)
Such and similar stories I have heard many times. When it was over fifty, I already stop counting them. There are many symptoms in this conversation. All could be interpreted with ease as a bad manager in the wrong place. True. And I have to admit, some 15 years ago, I would ask myself, what the craziness is this? Today, I see the situation differently. I am trying to understand why the organization act so poorly. I know that organization is a living organism, and therefore it is quite a complex system. The symptoms I saw in the conversation have their root causes, which need to be uncovered and understood before I can suggest some judgment or advice.
Many technology organizations today, when they are facing problems with their deliveries, they start changing their process of development. They throw on that problem a new framework or technique. They start reorganizing responsibilities or invite armies of coaches to fix it. And still, there is no long term effect. Sometimes, they achieve even production slowdown, and almost always, the payroll jumps across the roof. In the role of an external observer, I frequently ask myself whether people who caused such dysfunctions could be the same, who can fix it.
So where is the problem?
I try to look at the organization holistically. I mean beyond just software development. Every symptom, which people try to fix often lies beyond IT development in one or more places. If the root cause crosses the functional border, the hunt for it is typically ignored or given up. People take the easiest solution. Let’s go Agile!
While seeking help among agile techniques, many are forgetting the underlying principles. There are a plethora of reasons. Unfortunately, when those principles are missing, Agile remains stripped to just a bunch of processes. And the process is seldom a problem. It is people and their behavior in the process.
For an illustration, I have prepared a list of root causes which I am discovering in the organizations. Some are more frequent than other ones. Interestingly, most items we can observe in otherwise well-functioning organizations, too. It is because it takes some time before we notice that our boat is taking in the water. When we start noticing, that response is slow or maneuverability difficult, there is already a lot of water under the deck. The pumps are afloat, and it is not clear where exactly the puncture is.
Issues that I observe in the software development:
• Machine-first, man second thinking.
• Lack of engineering practices.
• Lack of interest in domain and context.
• Low and inappropriate communication.
• Lack of knowledge — a senior expert is level 3 of 5, the rest of the crew is level 5 (in big organization 2,5 vs. 4), where level no.1 is the best.
• Outdated approach to quality.
• Lack of teamwork capability.
Issues that I observe concerning people:
• Work with people cannot be delegated (even internally to HR-department), and still many do.
• No concept/no requirements for developing talent, no development programs in place.
• Requirements for talent are ad-hoc and not backed by the strategy. Approach for defining work positions is rigid.
• Deficiency in skills, competencies, and knowledge (very usual).
• Lack of managerial skills, business acumen, and intrapreneurship.
• Promotion without demonstration of skills or expertise (often political).
• Lack of performance, because nobody demands it.
• Key positions without the development of their backups.
• Fluctuation, low morale & loyalty.
Issues with how the organization functions:
• The lack of trust
• Structures that are designed by general historical beliefs — or blindly copied from others — not respecting unique product/service fit.
• Missing unifying culture — encouraging people to focus on customers and competition, not internal (politics) fights for status.
• Lack of communication.
• Toxic behavior.
• Lack of curiosity and drive.
• Activities without added value to justify bureaucracy.
Issues I observe in sales and finance:
• Obsolete or inappropriate business model.
• Value is not defined, understood, and delivered.
• Wrong goals.
• No planning, no targets, and no forecasting.
• Financial data not available for decision-makers, often secret.
Issues I observe in product management:
• Lack of people with expertise in product management, amateurish approach, or no product management at all.
• No product goals or strategy.
• People do not believe in the product.
• Financial models, prioritization, or economic perspectives are missing.
• Lack of market research or understanding of customers.
• Ideas not validated with the market where appropriate.
• Product approach ad-hoc as a result of first 1–2 customer requirements, trying to include all possible features to satisfy even most minor, yet conflicting requirements. Nobody manages the product.
• No metrics for learning & progress, nor quantification.
The list of items is far from complete. I thought to sort them according to importance or occurrence, but I failed. The order is random. If I put them on the paper discreetly, one can wonder why we cannot resolve them. It is because problems are always hidden, masked, often under strange symptoms, believes, ignorance, or low performance. They are interconnected with each other and create nets and complex bubbles. Nearly every attempt to uncover them is a local action. People try to fix a single problem with Scrum, where the root cause goes up and down across multiple departments or functions. Therefore it is impossible to address the root causes one by one, too.
How can an Agile Assessment help? Can we do something instead?
The assessment is to help uncover hidden root causes of the issues, their severity, and relations among them.
I analyze the organization or its department from the perspective of the four elements of the Agile enterprise. I observe how the team works while creating a product or service in the context of the value stream. And how the organization defines and creates value. I evaluate how the processes respond to changes or embrace ambiguity. I look at the organizational culture and people management. It is to understand how culture supports motivation and engagement of people to overcome production issues and creating value. And how culture reflects the original DNA and purpose implemented by the founders. Finally, I uncover how the organization approaches building human capital through knowledge management. The organization in the knowledge economy has difficulties competing if people in it do not possess the knowledge. Sometimes I include an assessment of the business model, overall financial management, communication, marketing, or more when appropriate.
The assessment does not screen the capabilities of a particular person. Instead, it provides a “map” or description of a landscape. It highlights the issues in it and their severity and root causes. It also provides recommendations, which are sometimes mind-changing, unorthodox, or radical. This output becomes the foundation for designing a new strategy on how to tackle the issues.
Assessing an organization may seem to be easy. It is, however, 15+ years of managerial experience in the agile domain. Every organization is different, has a different structure, people, processes, and purpose. During the assessment, it must be absorbed and understood in a short time frame, often just a day or two. For providing objective results, the important is to approach the organization without prejudices. The assessment comes out from personal experience. It is easy to get biased. I try to interpret findings the way it helps an organization and people in it to improve and act on the founding.
The assessment does not attempt to uncover every issue or every broken relation. It is probably not possible. The ambition is, instead, describe the landscape with the most critical findings. In our experience, most organizations found discoveries useful. It inspired them to change. There are some examples here, taken out of around 70 organizations, describing the range of improvements. From small ones, which improves the comfort of the operations for the people. Through the medium ones, that help to build new competitive capabilities and to innovate faster. Until the extensive organizational changes with an immediate economic impact on the organization, including its survival. I estimate assessments saved our customers €30 million and counting.
Assessment is also suitable for organizations, which are not building Agile as their way of operation. I often see in more traditional organizations that they have their processes but ignores them. Companies have a purpose yet excluded from their decisions about operations. Agile can help in the traditional organization by simplifying some activities or inspire necessary changes.
Do you like this article? Spread the word. Follow me here on LinkedIn or on Medium for more great content.
About the author: Michal Vallo builds agile organizations and helps managers to understand agile techniques, benefit from its adoption and consequently radically improve organizational performance. He is agile trainer, coach, and manager at Aguarra, a founding member of Agilia community and organizer of Agilia Conference / Agile Management Congress. Feel free to contact him if you need help with your agile adoption.