Evolutionary Stages

Application development involves a number of different activities ranging from requirements gathering to development to governance. Each of these, in turn, can inhibit or engender IT's responsiveness to changes in the business environment. 

For example, consider how the way in which requirements are gathered impacts IT responsiveness. At one extreme, a big up-front design does not allow {sidebar id=1} for much flexibility in functionality once the project has begun. At the other, having requirements spontaneously expressed as end-to-end statements of functionality that include a formal measure of business value delivered, and storing requirements in a global repository to be acted upon opportunistically, can provide maximum flexibility. 

Identifying polar extremes is useful guidance: e.g., does an organization tend toward one extreme or the other? Beyond that, extreme perspectives raise questions and concerns as an organization considers how it is to improve:

• If neither extreme describes current state, how does one recognize the strengths and weaknesses of what the team is currently doing?
• For those closer to the least agile state, bridging the gap to the greatest agile state is not going to happen in a single step. How does one progress to a greater state of agility without trying to go too far, too fast?
• For some organizations the "extremely agile" state may present economic disincentive. Is there is no middle ground?

Clearly, having a presentation of stages of affinity would go a long way to answering these questions. 

Prescriptive Agile?

Before going any further, the objective of this approach is not to propose an assessment-cum-"agile certification." Nor is it to define absolute stages of evolution through which every project, department or organization will mature. It is meant to provide a way to recognize the relative strengths and weaknesses in how work is done as well as the inhibitors and enablers to business-IT alignment. Defined across a complete set of IT activities, such a model would allow for assessment of "agility" to be more fact based and less a matter of opinion.

Consider again the example of requirements gathering.  From least to most agile, progression might look something like this:

• Least agile: development tasks extracted from voluminous, frozen requirements artifacts.
• Production of lightweight artifacts (e.g. panel flows) to drive high-level requirements development.
• Mapping granular requirements into high-level user requirements.
• Marshalling use cases into discreet, team-oriented (a.k.a. stove-piped), bounded statements of functionality that can be delivered in time-boxed development iterations.
• Developing expressions of end-to-end functionality, including testable acceptance criteria and a statement of value ("stories").
• Spontaneous story development provided by the business for in-flight projects. Stories are not derived from extant sources but are immediate expressions of customer demand and need.
• Most agile: Global repository of functional requirements for stories developed by business for any business requirement, including a formal measure of the business value to be delivered by each requirement.

With this level of detail, current and future state and the gap separating them become easier to map.

Multiple Dimensions

In addition to requirements gathering, a complete maturity would include other activities which inhibit or engender agility, including:

• Testing - the extent to which testing is integrated into day-to-day development activities.
• Collective code ownership - how aggressively people pair and can commit code anywhere in a system.
• Collaboration - the events and frequency with which developers, management and customer interact and communicate.
• Assurance/governance - the degree to which management activities integrate directly into development tasks.
• Simplicity - the extent to which developers are locked-in to a technical design or have freedom to refactor with each new requirement.

There are organizational considerations and inter-dependencies to consider. For example, consider a department of "stove-piped" teams, each working on a largely technical slice of an application but not working on the whole. In this case, an end-to-end, testable statement of functionality would span teams and therefore not be executable. Here, the organization very likely needs to be restructured to engender greater collective code ownership and very likely simplicity of design as well. Clearly, a restructuring will take more effort and if handled poorly could be a traumatic event, completely inhibiting development activity. 

The now more complex task of restructuring a department should not preclude making incremental progress. For one thing, there are benefits of being in an intermediate state of requirements gathering: marshalling tasks into bounded, granular, portable statements of work engenders better estimating, scheduling and tracking leading to greater operational transparency. For another, incrementally maturing toward collective code ownership, simplicity of design and requirements gathering introduces practices that enable that restructuring.

Plotting a Course and Measuring Progress

A more thorough collection of maturity flights allows an organization to take better informed decisions as it tries to become more agile. Specifically:

• A current state assessment is easily mapped into the model, answering the question "where are we?"
• The target future state or goal of the organization in different areas is similarly easily mapped into the model above, answering "where do we want to be?"

In addition, each level can be numbered, for example from -1 (inhibits agility) to 5 (greatest enabler of agility). Once assigned, progress can be periodically surveyed and visually represented, tracked and reported (see Figure 1).

Figure 1: Sample Skill Maturity

Seeing the gap and interim stages clearly defined allows other critical questions to be answered:

• First, what is the business benefit to where it is we want to be? Seeing different stages allows an organization to more clearly identify the impact those practices will have on the overall business and help to prioritize the order in which the processes are/should be changed. 
• Second, how do we get there? Knowing the different stages of maturity allows transition events - for example, a reorganization or retraining to facilitate greater IT-business collaboration - to be defined and staged.
• Third, how much will it cost? Identifying the transition events enables a cost model for continuous improvement to be defined.

Fully applied, this model facilitates development of a business case including an organizational change plan, costs and benefits for Agile practice adaptation.

Conclusion

This "agile maturity model" is not intended to be prescriptive or authoritarian. It is an attempt to create a simple, flexible, fact-based assessment of the degree of agility in fundamental IT practices and, subsequently, in an organization. With this framework, an organization can quickly assess how its current processes enable and inhibit responsiveness and can determine what it should be doing. Fully applied, an agile maturity model also helps identify what teams must change to be able to achieve responsiveness and then structure a business case for making those changes. 

Comments (0)

Write comment

Show/hide comment form