On November 5 there will be the 2nd Agile Leadership Day here in Zurich which will be another excellent chance for senior management and other leaders to learn about the agile movement and the benefits that agile brings.
I recently came across an organization who had declared „Mission accomplished“ for becoming agile. I found – let’s say – a few anti-patterns why that was far from the case.

Slow down innovation with a waterfall-like process

Every organization needs some guardrails to understand how the organization works. These guardrails are sometimes called rules, guidelines, workflows, or processes. And they are needed. Defining when these guardrails have to be kept and when they should be circumvented is the challenge for any organization. Only the organization itself knows how flexible it wants to be. Outsiders usually do not understand that.

When setting up a new organization, don’t ask a business process consultancy to help you define the processes because you will get strict waterfall-like processes that slow down your organization and slow down innovation.

Hinder employees from thinking for themselves by defining a workflow having strict interfaces

In today’s organizations, every employee believes that (s)he has too much to do and too little time to do it. They will fight for themselves because no one else does. They will believe that the process thinks for them and that it allows them to avoid any additional work by thinking in their own personal best interest. They will start to not think about what would be best for the organization but what is best for them.

When setting up your organization don’t define a process that has to be followed strictly and don’t define strict paths on which information must flow. Instead foster a sprit of thinking differently and provide employees with the right and time to think about what would be best for your organization.

Overburden employees with lots of roles

All employees of an organization don’t understand why there have to be managers for every single task. Most organizations and employees do not understand the difference between roles and real people.

When setting up your organization, don’t define lots of roles. The result will be that for every role there will be at least one person. Instead, define only a few roles and give them more tasks to do.

Confuse employees with lots of manager roles

There is a tendency to have more and more manager roles compared to the number of normal employees actually adding value to the organization. When I asked such a manager about the difference between a requirements engineer and a requirements manager, he told me that the manager manages and the engineer works. He did add a smiley, though, but really believed that the requirements manager manages demands and not requirements.

When setting up your organization reduce the number of manager roles to as little as possible. It will greatly affect your organization to become less stiff and more agile.

Overcomplicate the workflow with lots of roles

In the organization in question the product managers give their wish to a manager managing the necessary change, who gives it to the business analysts. After they have defined the business requirements, they give them back to the manager managing the change, who places a demand with the key account manager of the developing organization. The key account manager places the demand with the requirements engineer who does an early analysis and gives that to the manager managing all application releases who reserves the resources and checks for the potential release. The demand is then made into one or more orders by the manager managing the order who gives it back to the requirements engineers to specify detailed requirements for each affected application. Once that is done, the technical architects take over and prepare the software development.

When setting up your organization with as little of roles as possible, you give the employees flexibility and freedom to innovate. If you don’t then any small change to the already agreed plan will have to be discussed with all of these roles and employees again slowing down your organization.

Declare only the programmers to be agile

There seems to be a misunderstanding that agile is Scrum and Scrum is agile. This results in the misbelief that only the programmers have to be agile for the organization to be agile.

When setting up your organization every part of it has to become agile not just the programmers doing some form of Scrum.

Declare the first role outside of the programmers‘ teams to be the product owner

The programmers ask for a product owner because they want to have only one person taking the decisions. That is a valid wish for any team – not just the programmers. In a hierarchical process they will ask for the role just prior to their task to be their product owner. In this case it would be the technical architect of the application.
Let me quickly quote Wikipedia for the definition of the product owner: „The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog.“

When looking at the defined process (above) it becomes clear why the technical architect shouldn’t be the product owner of the programmers.

Let the technical architect write user stories

The programmers asks for user stories because that’s what you do when doing Scrum. Since the technical architect is the product owner for them, they ask him or her to write user stories.

That would be fine if there weren’t product managers, business analysts, and even requirements engineers included in the process who should have already specified the application in such a detail that user stories would be three steps backward.

Think about costs instead of investments

The major challenge are the managers who always want to know exactly what an idea will cost instead of saying how much they are willing to invest into it. Estimating the cost results in defining the scope. A defined scope must be fully delivered in order to make a project look successful to them.

Welcome back, Waterfall!

Don’t live and breath agility as senior management

Scrum believes that change will be initiated by the development teams. For any large organization to become agile, the decision will be made by the senior management. Any enduring change must come from the top not from the bottom. My guess is that the senior management of large organizations have made their fortune by sticking to hierarchies, rules, and processes.

More than others, senior management has to be well-informed and knowledgable about agility. Understanding that their own mindset has to change completely and to learn about agility is the first step to change themselves. There are multiple ways to learn. Talking to one expert is the start. A better investment is to visit a conference to exchange experiences with lots of experts who have already learned their lessons. In Zurich alone, there are a multitude of these opportunities available, e.g. the Agile Leadership Day.

I hope to seeing you there!