How do IT departments and software development companies achieve consistency with their agile programs? Agile delivery methods make it easy to start small by winning one sprint at a time, one team at a time, and one product release at a time until organizations develop a rhythm of delivery and drive process improvement through retrospectives and self organization practices. This one dimensional scaling of an agile practice is not trivial and doesn’t happen overnight. These organizations need mechanics to maintain the backlog, develop practices to share work across multiple teams, maintain quality as the product matures, and address technical debt.

But making agile work for an entire department requires additional capabilities and practices.  For agile to work successfully across multiple business programs, or to best establish shared platforms or services, or to improve economics and speed of delivery by distributing work globally, the agile practice needs a definition of consistency and additional practices to succeed.

How Should Consistency Be Defined?

Consistency in software delivery used to be defined by whether the team delivered a project on time, on budget, on scope, and on quality often defines as the Project Management Triangle. A good Project Manager knows that you can optimize against one or two of these dimensions but hitting all three yet alone four consistently is complex because of the dependencies and trade offs between these dimensions. Then there are additional dimensions that may be important – customer satisfaction, cost to maintain, product robustness – ability to easily change or enhance, product reliability and other product or program dimensions.

Most organizations can not afford to become overly structured with formal definitions of consistency  and it’s unlikely that a “one size fits all” since different business programs have different drivers. It is more important for departments and teams to develop an understanding and a culture around the key dimensions and possibly define them as operating principles.

Start with the Basics

Here’s a hint – I’ve already covered some of the key practices in other posts. Shifting to a Market, Program, and Platform Organization is a good start and links to several posts that help move away from a project/product approach to delivery to a market/program practice. More recent posts cover agile planning sprints, leveraging data in product development, agile estimation, agile architecture, and measuring agile delivery costs.

But a good start for any IT or software delivery organization is to develop their Agile Practice Guide – a presentation, document, or even wiki that puts some formal definition around the practice. Imagine you are adding a new member of a team, or maybe a new team – how can the organization best articulate the current state of the agile practice so that new members can become productive in their role in one “learning” sprint?