In 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:
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.
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.