Accept Software Resource Library

Scaling Agile - The Devil?s Triangles Traps

Agile purists would argue that “scaling” and “Agile” should not go in the same sentence because the whole point of Agile is to deliver a working system in small increments, so you cannot get more scalable than that. Who can argue with that? Yet, I keep seeing organizations that love the value of sprints and cross-functional teams, but struggle to apply it to more complex software and products built across distributed teams.

Agile Fail Points - I have found similar challenges across disparate industries such as software, energy, consumer electronics, and internal IT. Next are some real-world examples. We delivered the system on time, but somewhere we dropped a critical requirement and that delayed a big payment milestone. Each team did their sprints on time, but a delayed architecture piece caused latency to everybody. The priorities we were setting at the team level got out of sync with the release priorities. The user stories we get are too high-level, we do not understand what the customer really wants. Priorities change all the time and yet we are still on the hook to deliver.

Devil’s Triangles Traps of Agile – The more I look at the issues, the more I see them boiling down to two tiers of traps. To describe them, I’d like to borrow from Michael Krigsman’s excellent blog the idea of a devil’s triangle, and I want to redefine it a bit and expand it to two triangles.

 

The inner triangle is the dynamic between key team stakeholders: user/customer, product owner, and developers. While things tend to work fairly well in a team with co-located members, when you have distributed team members or difficult “politics” (both of which happen a lot) things “disappear” in the vortex of this triangle: use cases are ignored in order to get things done; user stories are not detailed enough; the context for prioritization is lost; customers change scope and priorities.

The outer triangle is the dynamics introduced by more complex systems and programs: the need to sync up sprints across release trains; manage dependencies between trains and architecture work; and have a shared view of prioritized backlogs at the release, feature, and user story level. In most cases this synchronization doesn’t happen with obvious and painful consequences.

It's Not About Agile - If we define Agile as just running development sprints, all this scaling discussion has little to do with it, and everything to do with the structure and management around it. I hear this argument a lot, but in the end the distinction is a moot point: a good engine is not going to get you to your destination without the rest of the car – Agile development alone will not prevent the dynamics of the devil’s triangles to suck precious life from a project. What matters in the end is how we address these real challenges and ensure that the products we create and the projects we run deliver the value they were intended to generate.

In future posts I plan to discuss in more detail the challenges of the two devil’s triangles of Agile and ways to tackle them. In the meantime, I’d love to hear how this relates to your experience.