“Agile Failure Patterns In Organizations”

An interesting essay showed up on Hacker News, called “Agile Failure Patterns In Organizations”

Where I am, we’ve made some efforts to move to a more small-a agile iterative and incremental development approach in different ways, and I think it’s been successful in some ways and less successful in others. (Really, I would say we’ve been trying to do this before we’d even heard the word “agile”).

Parts of the essay seem a bit too scrum-focused to me (I’m sold on the general principle of agile development, I’m less sold on Scrum(tm)), and I’m not sure about the list of “Agile Failures at a Team Level”, but the list of “Agile Failures at Organizational Level”… ring some bells for me, loudly.

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 take 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.
• 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.

How about you, do some of those make you wonder if the author has been studying your organization, they ring so true?