Add to Google
The Agile Enterprise Acid Test – Updated
Posted on October 13, 2008 by Dean Leffingwell in Agile Executive, Team PracticesIn a prior post, I referred to a post by Paul Beavers of BMC (Is it Possible to be Half-Agile?) which gave his perspective on the agile acid test- the quintessential test of whether or not an organization is truly achieving agility at enterprise scale. In my post, I also provided my viewpoint on the subject. Recently, I tested that viewpoint with a few others. As a result, I’ve modified my version a bit as you see in the graphic below:
Agile Enterprise Acid Test
As amended, the three elements of my version of the Agile Enterprise Acid Test are now:
Variable scope. Fixed quality.
- Can the teams vary scope? – Does the team have the authority to vary scope even as the release deadline draws closer?
- Is quality acceptable and fixed? – You can’t go fast building on crappy code. Agile accomplishes little without the requisite code quality which must be built into the process through TTD, continuous integration, test automation, coding standards and the like. If you see your teams iterating or sprinting with a primary objective of working down code-level defects, then you are not truly agile.
Incremental Value Delivery
- Is software delivered incrementally? – If your teams are sprinting but there is no feedback until the final delivery (one form of “waterscrumming”) then you are not achieving agility as there is no meaningful feedback to drive the solution to an acceptable outcome
- Is it valued and evaluated? – Demos are great, but you need real value delivery to assure fitness for intended use and early and continuous ROI. If the incremental code is not being actually used, you are not very likely to get the results you seek.
- Is feedback continuous? – In addition to customer feedback, product owners, product managers and other stakeholders have a responsibility to continually assess the current result. This is achieved through story-level acceptance and iteration-level demos.
Empowerment and Accountability
- Are the teams empowered? – Are the teams truly empowered and able to modify and improve their own software processes? Do they self organize and self-manage? Are resources routinely moved to the most critical bottlenecks?
- Are they accountable for results? Empowerment and accountability are two sides of the same agile coin. Are the teams delivering reliable quality code in incremental fashion? Do you they commit to iteration and release objectives, subject to responsible scope management?
- Do they regularly reflect and adapt? – Do the teams adhere to Agile Manifesto Principle #12? – At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Does management eliminate impediments? – is management also engaged in continuous improvement? Are impediments routinely surfaced, addressed and eliminated.
That’s my current definition.
–Dean
Note: Readers may also want to note Jon Strickler’s view on this definition, perhaps from a somehwat “leaner” perspective, in the comments on this post below.
I agree with what you’ve written. I am going to get picky here, so read at your own discretion… Perhaps, I’d rearrange the sub bullets under different main headings. For example, as I compare this to my definition, I wonder whether the test for customer alignment should be more explicit?
I also notice my definition does not explicitly dictate variable scope or even iterations. To me, scope size is more about keeping lean and ensuring flow than a test itself. Effective workload management enables many benefits. If a company demonstrates rapid delivery, regular inspection, adaption, customer alignment and quality by other means (eg: kanban, FDD, etc.) then they pass the test. I’d perhaps change this to “Can teams effectively manage workload?” which allows for more flexibility in how scope gets managed. Test should be for the result, not necessarily for a specific means to that result.
Jon,
Thanks for your comments. On your second point above, I basically agree but the lean paradigm you’ve described represents a fairly advanced stage of agility for most new-to-agile enterprises. I’m afraid that for many teams “can effectively manage workload” can be interpreted by their management into “that’s their workload, they should effectively, agily manage it” -:).
So I’m still comfortable with the message of “Variable Scope.” It’s explicit and hits the fixed-scope-time-resource bully right on the nose. If you can’t vary scope at the get-go, it’s pretty hard to become agile, much less truly lean.
I suspect that we certainly agree that if teams aren’t empowered to continuously manage scope they will be neither lean nor agile.
–Dean
[...] The Agile Enterprise Acid Test – Updated « Scaling Software Agility " * Variable scope. Fixed quality. * Incremental Value Delivery * Empowerment and Accountability " (tags: development code test agile acid) [...]