Recognize Agile Failure Pattern in Organizations

Source: https://age-of-product.com/agile-failure-patterns-in-organizations/  and https://www.youtube.com/watch?v=-RXQLVhIuJg

I recently encounter some articles discussing what makes an agile successful for a certain team/organizations while not very successful for others. This provide provides a good summary. Check out the youtube video as well. Hope it is insightful!

• 

1. Not having a (product) vision in the first place, note that: If you don’t 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 hypotheses testing; the management define/dictate 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.
6. The organization is not optimized for a rapid build-test-learn culture, and thus departments are moving at different speed levels.
7. Management is not participating in Agile processes despite being a role model. If managers do not display agile mindset and behaviors why would the teams change?
8. Not making organizational flaws visible. No open discussion about what is not working and how to fix things.
9. Product management is not perceived as the “problem solver and domain expert” within the organization, but as the guys who turn requirements into deliverable (project executor).
10. Other departments fail to involve product management and team from the start. Typical behavior in larger organizations is a kind of silo thinking, often driven by individual incentives, e.g., bonuses. (Personal agendas are not always aligned with the company strategy.).
11. The sales/business organization guards access to customers, thus preventing teams from learning.
12. Responsibilities of product management are covered by other departments or many other different roles.
13. The product management team size is not balanced by comparison to the size of the engineering team. More “managers” than developers.
14. Engineering teams are not free to choose “their” tech stack.

Advertisement