Playing it SAFe, Can a Large Organization Become Agile Without Changing Anything?

We’ve noticed someone selling a prescriptive approach to large scale Agile that actually appears to be 80% waterfall.  An 80/20 waterfall/agile hybrid approach may be a positive step, but we’re concerned that this scaled agile framework confuses people about what a truly Agile approach to large scale development would be.
Let’s examine some principles from the Agile Manifesto:
  • Business people and developers must work together daily throughout the project.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
On the other hand, the easy, safe prescription for scaling seems to deliberately institutionalize some bad ideas we usually call impediments:
  • A three layer stack with proxy Product Owners in the bottom layer, enmeshed in coding teams.  Somewhere above the pseudo-Product Owners, other silos contain the stuff we usually consider Product Owner work: vision, product management, release management, portfolio management.  In our experience it’s better for self-organizing teams to work directly with the *real* decision makers responsible for the vision as it emerges.  The Scrum Product Owner was never supposed to be an artificially elevated middle manager.  According to Kent Beck, the first known XP project failed because the “Goal Donor” was not the “Gold Owner.” We want regular face to face contact between business decision makers and development teams so all learn from each other.
  • Teams contain “Developers & Testers” but UX, architecture, integration (by the “System Team”), and “release train engineering” occur elsewhere.  In Scrum, these are team responsibilities, so we want truly cross-functional teams, usually with business requirements experts, UI/UX designers, etc. right on the teams.  Scrum encourages a rigorous definition of done.  Teams will be more Agile if they learn to integrate their work with other teams. This will be difficult at scale, but coordination roles only make this worse.
  • Somewhere up in the whipped cream layer of this cake we find czars such as the “Enterprise Architect” working on “Architectural Epics” guaranteed to lead to architectural bloat.  I assume this was created to appease senior technical guys who have grown rusty at everything but PowerPoint.  One place I worked with found their (waterfall era) Architecture Center Of Excellence ivory tower to be such a huge impediment they disbanded it and put the architects right on Scrum development teams, right in the team rooms.  An assigned “architect” role is utterly incompatible with the Agile principle “The best architectures, requirements, and designs emerge from self-organizing teams.”  Scrum teams are responsible for the design of the software they build.  If we must use multiple teams on one product/portfolio and we believe in team self organization, ScrumMasters must create environments that encourage teams to coordinate with each other through communities of practice, not implementation czars.
The 20% of this that’s Agile is the stuff that’s relatively easy to change in an organization: putting testers on the teams (except not integration testers evidently), working in iterations, acknowledging that architecture will evolve, and co-opting (occasionally abusing) Agile jargon.  Maybe a couple steps forward for some orgs, but far from ideal.  I think it will appeal to companies that are concerned with keeping cozy spots for everyone, avoiding the uncomfortable ambiguity and uncertainty where real breakthroughs occur.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>