Building a Better Agile Implementation

Agile software development is becoming increasingly popular.  An increasing number of organizations (businesses, startups, non-profits) are adopting Agile for a variety of reasons.  Whether it’s Scrum, Kanban, Lean, XP or any of the other flavors, what is clear is that Agile offers something other Software Development Lifecycle (SDLC) methodologies cant, or don’t: accelerated business value.  That’s the goal of Agile – to more iteratively, and more quickly produce a product meeting business needs.

But, like any SDLC, Agile is only as good the implementation (and adoption) plan, as well as the execution plan.

Find four steps to building a better Agile implementation.

1. Focus on the how, not the what

CIOs and adoption teams focusing on the technology are missing THE most critical dimension of Agile adoption.

The first step in shifting to Agile requires educating the organization – including the technology and business teams – about what the shift means for the organization.  Three of the four principles professed in the Agile Manifesto focus on people:

• Individuals and interactions over processes and tools;
• Customer collaboration over contract negotiation; and
• Responding to change over following a plan.

Agile is about shifting how organizations collaborate to deliver product; it isn’t about a particular software, tool or technology.

2. Define done early

One of the biggest challenges business and development teams face is understanding when work is complete.  Contrary to several trains of thought, having an enterprise minimum, an enterprise definition of done, strengthens Agile adoption and development.

Applying a consistent definition of done, including peer reviews, code scans, and other activities, provides the basis for consistent product development across the enterprise.

While Scrum, and other flavors promote self-organizing, and team-driven activity, clearly defining “done” criteria is essential to team success, and product adoption.  Using this construct, development teams can apply project/product-specific completion requirements on top of the core ‘definition of done’.  The benefit of using this approach is consistency across the technical enterprise, and smoother transition of development team members between projects.

3. Remember that business value isn’t just about coding

One of the biggest perversions of the Agile manifesto is the argument that documentation isn’t necessary.  I vehemently argue against this.  Anyone employing that view is adopting a very shortsighted view of Agile, and is perverting the second principle (Working software over comprehensive documentation).  This second principle points Agile adopters towards delivering what the business needs.  That includes both the working product, and any necessary documentation required to support and maintain the solution.

4. Proactively engage the auditors

Blasphemy and heresy, right? Wrong.  Inevitably, an Agile project will be audited.  And, if your Agile team operates like most, the focus is on pure development, and little to no focus on auditability or providing traceability.  It’s during an audit that the ‘development dirty laundry’ gets uncovered.

How do you avoid that? Engage your audit teams early.  Educate them on the goal and benefit of Agile, and how the organization needs to shift to maximize business value (remember step number 1?).

Don’t stop there – ask them for their input!  Training internal audit on the differences between Agile and your prior SDLC can be valuable.  It allows auditors to offer input on how to structure your Agile transition.  It may also provide a framework for monitoring and controling the projects.  Involving audit in decisions around the required documentation, capturing traceability (of requirements to design to development) are important considerations; if planned for early, these changes are easier to adopt vs. retroactively applying them to an established process.

Conclusion

Agile is a change in how organizations collaborate.  True Agile collaboration drives organization change in thought, practice and ultimately, in expectations. Shifting your mindset to focus on what the business needs, and preparing yourself for that transition is critical to a successful Agile adoption.

Starting focusing on how the Agile transition impacts the organization.  Center the transformation on ‘how’ the organization will change, vs. the tools or specific technological impacts of the change.  This provide the basis for effective change.

Clearly defining your ‘definition of done’ criteria provide a baseline for effectively measuring development progress and completion of development efforts.

Third, focus on business value.  Remember, there is an ultimate customer expecting to use and own whatever is being built.  Agile development teams need to center themselves on business user needs.  This has to include more than the code or technical artifacts produced to satisfy the user stories and Product Owner requirements.

Finally, remember that you have a choice on whether you want to make a friend or enemy of your auditors.  Proactive engagement signifies the recognition of their organizational value.