Why Agile is Simple and Complex at the Same Time
Who wouldn’t agree that the four core principles of the Agile Manifesto —
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
— aren’t derived from applying common sense to a serious problem?
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 increasing competitive war for talent,
- Senior people quitting,
- Budget constrains (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.
But fact is also, that the scope of an Agile organizational transformation is often completely underestimated. That Agile is not the quick fix for everything that’s going wrong. Each organization has it 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:
- Not having a (product) vision in the first place: If you don’t know where you are going, any road will get you there.
- 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 for the product backlog.
- A perceived loss of control at management level leads to micro-management.
- The organization is not transparent with regard to vision and strategy hence the teams are hindered to become self-organizing.
- 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.”)
- 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.
- Senior management is not participating in Agile processes, e.g. sprint demos, despite being a role model. But they do expect a different form of (push) reporting.
- 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
- 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”.
- Other departments fail to involve product management from the start. A 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.)
- Core responsibilities of product management are covered by other departments, e.g. tracking, thus leaving product dependent on others for data-driven decisions.
- Product managers w/o a dedicated team can be problem, if the product management team is oversized by comparison to the size of the engineering team.
II. Agile Failure At Team Level:
- 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, particularly they fail to say "No".
- Engineers with an open source coding mentality: Tasks are discussed on pull requests once they're finished, but not in advance during grooming or sprint planning sessions. (They tend to operate in distributed team mentality.)
- 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 an other team delivering functionality to build upon.
- 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.
- Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones.
- Teams are not self-organizing. That would require to accept responsibility for the team’s performance and a sense of urgency for delivery and value creation. A "team" in this mode is actually more acting like a group—e.g. 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.)
- Even worse, team members abandon Agile quietly, believing it is a management fad that will go away sooner or later.
- Faux Agile: Teams follow the “Agile rules” mechanically without understanding why those are defined in the first place. This level of adoption often results often in a phenomenon called "Peak Scrum": There is no improvement over the previous process, despite all Agile rules are being followed to the letter. Or even worse: morale and productivity go down, as the enthusiasm after the initial agile trainings wears off quickly in the trenches.
- Moving people among teams upon short notice. Even if required for technical reasons, this has a negative impact on a team's performance & morale.
Share your own experience w/ the poll: What Is the Most Important Agile Challenge You Are Facing At the Moment?
III. Agile Failure At Process Level:
- Agile processes are either bent or ignored whenever it seems appropriate. There is a lack of process discipline.
- 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 actually makes a great Waterfall 2.0 process.)
- 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.
- The organization is not spending enough time on team communication and workshops to create a shared understanding on what is to be built.
IV. Agile Failure At Facility Level:
- A team is not co-located, not working in the same room, but scattered across different floors, or worse, different locations.
- The work environment is lacking spots for formal and – more important – informal communication: cafeterias, tea kitchens, sofas etc.
- The work environment is lacking whiteboards. Actually, the absence of whiteboards on each and every available wall within the office should be questionable, not having them.
- Agile requires suitable offices to further collaboration: spacy, with plenty of air and light. But they should not be a mere open space, which tends to get too noisy, particularly when several Scrum team are having stand-ups at the same time.
What Is the Most Important Agile Challenge You are Facing at the Moment?
Everyone of us is dealing with numerous issues related to becoming, improving or even staying Agile every day. I would like to learn more about the spectrum of your Agile challenges. If you invest three minutes of your time, that would mean the world to me: