Agile Failure Patterns in Organizations 2.0

TL;DR: Agile Failure Patterns — Why Agile is Simple and Complex at the Same Time

Agile failure seems to be increasingly more prominent nowadays despite all the efforts undertaken by numerous organization embarking on their journeys to become agile.

The funny thing is: Who would disagree that the four core principles of the Agile Manifesto —

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

— are derived from applying common sense to a challenging problem? Moreover, that the application of those principles might be suited to fix numerous organizational dysfunctions and reduce an error-prone and complex social setting to maybe just a complicated one?

There are various good reasons to adopt Agile, for example:

• Low productivity,
• Low morale,
• Problems hiring senior people in an increasingly competitive war for talent,
• Loss of senior people,
• Budget constraints (no more funds to waste on waterfall projects), or
• The competition drives innovation at a high pace, and the traditional methodology cannot keep up with them.

However, the fact is also, that the scope of an Agile organizational transformation is often wholly underestimated. That Agile is not the quick fix for everything that is going wrong. Each organization has its own set of dysfunctions, and hence solutions dealing with them need to be tailored specifically to that organization.

Agile Failure Patterns

Analyzing my past projects, I identified the following four cross-organizational patterns that are making Agile transitions to much more harder, less effective and significantly more expensive:

I. Agile Failure At Organizational Level

1. Not having a (product) vision in the first place: If you do not know where you are going, any road will get you there.
2. The fallacy of “We know what we need to build.” There is no need for product discovery or hypotheses testing; the senior management can define what is relevant to the product backlog.
3. A perceived loss of control at management level leads to micro-management. (The ‘what-is-in-for-me-syndrome.’)
4. The organization is not transparent about vision and strategy hence the teams are hindered to become self-organizing.
5. There is no culture of failure: Teams, therefore, do not move out of their comfort zones but instead play safe. (Mathgeek on HN suggests to replace “culture of failure” with “culture of learning to get back up again after falling.”)
6. The organization is not optimized for a rapid build-test-learn culture, and thus departments are moving at different speed levels. The resulting friction caused is likely to equalize previous Agile gains.
7. Senior management is not participating in Agile processes, for example, the sprint demos, despite being a role model. Instead, they do expect a different form of (push) reporting.
8. Not making organizational flaws visible: The good thing about Agile is that it will identify all organizational problems sooner or later. (“When you put problem in a computer, box hide answer. Problem must be visible!” Hideshi Yokoi, former President of the Toyota Production System Support Center in Erlanger, Kentucky, USA.)
9. Product management is not perceived as the “problem solver and domain expert” within the organization, but as the guys who turn requirements into deliverables, aka “Jira monkeys.”
10. Other departments fail to involve product management from the start. Typical behavior in larger organizations is a kind of silo thinking, featured by local optimization efforts without regard to the overall company strategy, often driven by individual incentives, e.g., bonuses. (Personal agendas are not always aligned with the company strategy.)
11. The sales organization guards access to customers, thus preventing teams from learning.
12. Core responsibilities of product management are covered by other departments, e.g., tracking metrics, thus leaving product dependent on others for data-driven decisions.
13. Product managers w/o a dedicated team can be problematic if the product management team is oversized by comparison to the size of the engineering team.
14. Engineering teams are not free to choose “their” tech stack.

Agile Transition — A Manual from the Trenches

Download the latest, 212 pages strong version of “Agile Transition — A Hands-on Manual from the Trenches.”

It is available right here, and it is free.

II. Agile Failure At Team Level

1. There are too many junior engineers on an engineering team. They tend to appreciate micro-management as part of their training. Usually, they have no or little experience with Agile methodologies. Hence they hardly can live up to processes, mainly they fail to say “No.”
2. Engineers with an open source coding mentality: Tasks are discussed on pull requests once they are finished, but not in advance during grooming or sprint planning sessions. (They tend to operate in a distributed team mentality.)
3. Teams are too small and hence not cross-functional. Example: A team is only working on frontend issues and lacks backend competence. That team will always rely on another team delivering functionality to build upon.
4. Teams are not adequately staffed, e.g., scrum master positions are not filled and product owners have to serve two roles at the same time.
5. Team members reject agile methodologies openly, as they do not want to be pushed out of their comfort zones.
6. Teams are not self-organizing. That would require accepting responsibility for the team’s performance and a sense of urgency for delivery and value creation. A “team” in this mode is more acting like a group—for example, people waiting at a bus-stop—: They are at the same time in the same place for the same purpose, but that does not result in forming a team. (The norming, storming, forming, performing cycle seems to be missing.)
7. Even worse, team members abandon Agile quietly, believing it is a management fad that will go away sooner or later.
8. Faux Agile: Teams follow the “Agile rules” mechanically without understanding why those are defined in the first place. This level of adoption often results in a phenomenon called “Peak Scrum”: There is no improvement over the previous process, despite all Agile rules are being followed to the letter. Alternatively, even worse: morale and productivity go down, as the enthusiasm after the initial agile training wears off quickly in the trenches.
9. Moving people among teams upon short notice. Even if required for technical reasons, this has a negative impact on a team’s performance & morale.

II. Agile Failure At Process Level

1. Agile light: The management abandons self-organization the moment a critical problem appears to form ‘task forces’ instead.
2. Agile processes are either bent or ignored whenever it seems appropriate. There is a lack of process discipline.
3. Agile processes are tempered with, e.g., the scrum product owner role is reduced to a project manager role. Often this is done so by assigning the task of backlog ownership to a different entity at management level. (“Scrum” without a product owner makes a magnificent Waterfall 2.0 process.)
4. Stakeholders are bypassing product management to get things done and get away with it in the eyes of the senior management, as they would show initiative.
5. The organization is not spending enough time on team communication and workshops to create a shared understanding of what is to be built.

IV. Agile Failure At Facility Level

1. A team is not co-located, not working in the same room, but scattered across different floors, or worse, different locations.
2. The work environment is lacking spots for formal and — more important — informal communication: cafeterias, tea kitchens, and sofas.
3. The work environment is lacking whiteboards. The absence of whiteboards on every available wall within the office should be questionable, not having them.
4. Agile requires suitable offices to further collaboration: spacy, with plenty of air and light. However, they should not be a mere open space, which tends to get too noisy, particularly when several Scrum team have stand-ups at the same time.

What kind of agile failure pattern have you observed? Please share with us in the comments.

? Do Not Miss Out: Join the 2,800-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it is free.

Do you want to read more like this?

Well, then:

• ?? Join 15,621 peers and sign-up for my weekly newsletter
• ?? Follow me on Twitter and subscribe to my blog Age of Product
• ?? Alternatively, join 2,800-plus peers of the Slack team “Hands-on Agile” for free.

Agile Failure Patterns in Organizations 2.0 was first published on Age-of-Product.