| The overwhelming success of initial Agile projects - simultaneously achieving a high degree of collaboration, technical quality, and operational transparency - quickly leads stakeholders to look for ways to roll-out Agile practices across the organization. Unfortunately, the consultant coaching or "trial and error" models common to initial Agile projects do not scale beyond small teams. For one thing, it is difficult to leverage individual "practice leaders" across multiple teams, geographies, and projects. For another, simply rolling out better development practices doesn't improve organizational responsiveness. To successfully undertake a large-scale "program of change" an organization must look for ways to leverage skills and experience, monitor practice adoption, align staff recruiting, and measure results.
Collaborative Infrastructure
Agile practices are, fundamentally, a set of best practices performed by people and teams. The introduction, reinforcement, and mastery of those practices take time. Leveraging the knowledge and skills of experienced practitioners is therefore critical to success, especially in large roll-outs. Two core infrastructure components enable this:
- Creating a communications channel for Agile. To clearly communicate what is meant by "Agile practices," use a Wiki or similar collaboration environment to provide definitions of key Agile terms, answers to frequently asked questions, and examples or case studies of different adoption patterns. Although it's a passive way to communicate, it provides reinforcement and fosters consistency that prevents large-scale roll-out from devolving into a process free-for-all.
However, infrastructure is only as good as it's used, and does not substitute for experience. Therefore, this infrastructure must be community-owned and evolved. That is, as experiences accumulate, people must be able to post their findings and experience to this organizational knowledgebase. Within a department, this provides "incubation" material for new staff. In federated {sidebar id=1} organizations - geographically isolated teams working on independent projects - this knowledgebase provides a common foundation that reconciles variation to address local or team-specific needs.
In sum, simple, community-owned infrastructure both establishes adoption and evolves with it, making implementation less vulnerable to staff change and increasing the likelihood that Agile process adoption will be durable over time.
Facilitating Best Practice Adoption
Agile practices will be adopted in different ways by different teams. For example, one team may be producing short shelf-life solutions that have significantly lower quality requirements than a team developing long-term transaction processing. Most likely, the investment in unit tests will not yield as much for the prior team as it does for the latter. To that end, the intent is not to achieve a uniform state of adoption across all teams, but for each team to get into the state that best serves its business objectives.
This is why an Agile Maturity Model (AMM) is particularly valuable: it allows the current and future state to be mapped out, and allows teams to plot their course through adoption. The AMM is not meant as a top-down compliance monitor, but a tool to be applied - with practice - in facilitated self-assessment. From this, the adoption pattern can be tracked and projected within a team or department.
In this example, the elements of the Agile Maturity Model are stratified into managerial and technical categories, with initial, current, and target states plotted to show whether adoption trends toward Managerial or Technical practices. The size of the orb reflects the sum of the Managerial and Technical indices for each state.
The purpose of this is not to certify adoption, but to recognize that skill acquisition happens over time and is greatly influenced by circumstance. Applied properly, it should help identify the least-invasive adoption pattern and make clear each teams' priorities for adoption.
Raising the Bar
While training is an important way to improve organizational capability, becoming an "agile organization" isn't an exercise in skill acquisition. There is more to success than familiarity with new practices. An agile team - that is, a team responsive to changes in the business environment - requires people with a high degree of professional awareness (e.g., are networked to open source communities), and that prefers to work with business and technical peers in a collaborative environment. To identify and develop these capabilities, this typically means changes to recruiting and assessment practices.
In most organizations, recruiting efforts focus on technical acumen and, sometimes, business domain knowledge. There are often not recruiting practices which identify either collaborative aptitude or professional awareness. To correct this, human resources staff and IT teams should introduce screening tools and interviewing techniques so they can more easily identify people with appropriate values.
Teams should also assess their own capabilities. Using a facilitated, peer-review approach, teams should anonymously self-assess their technical skills, professional awareness, and collaborative qualities. This provides teams with a vehicle through which to independently recognize and act on shortcomings. Executed frequently, it provides a critical data set that enables continuous improvement.
Monitoring Success
The only reason to take on Agile practices is to improve IT effectiveness; it is important, then, that bottom-line impact be constantly assessed. This means measuring the extent to which IT solution delivery is more effective. This requires metrics and reporting of the extent to which teams are:
- Delivering highest-priority / highest-value to the business,
- Delivering to a high standard of quality, and
- Managing to their business case of scope, budget and time.
Fortunately, Agile project management lends itself to the non-invasive capture and consolidation of execution data. From this, delivery status dashboards tracking status and improvement over time can be easily constructed.
But bottom-line results don't tell the whole story. The extent to which practices are being adopted, skills are improving, and customer satisfaction is increasing indicate the success of the program of change. To this end, a Balanced Scorecard showing financial performance, delivery execution, organizational learning, and customer satisfaction clearly shows the complete satisfaction of program goals. As with effectiveness data, the collection of process data should be non-invasive to Agile teams.
The combination of assessing that the program is delivering value for money and that the work is meeting complete expectations forms the basis of sound IT governance. That Agile practices seamlessly integrate with good governance strongly indicates that Agile will heavily influence IT governance.
Success Factors to Making Change
There are several key success factors in large-scale programs of change.
Have unambiguous business goals for making change. Everybody must recognize the need, the destination, and the path of a change program. The goal must not seen to be adoption for sake of adoption, but to achieve demonstrably better results. This provides a sound business basis for measuring success, and also means people are less likely to treat it as a passing fad of management.
View becoming "agile" as organizational - not just IT-oriented - in scope. Building an agile organization affects the entire business. Making application development more efficient is useless if it over-runs IT infrastructure or the business. Solutions delivered quickly that can't be reviewed by business users creates latency in feedback, idle staff time and broken feedback loops. Solutions delivered that can't be put into production create delays in realized business value. In either situation, solution delivery is still characterized by a lot of waste. Thus, a move toward Agile process adoption on a large scale must be considered in the overall capability of the business to become agile itself.
Take an iterative approach to change. Just as iterative techniques reduce risk in delivering IT solutions, so, too, does taking an iterative approach reduce risk in process change. This allows frequent consideration, adjustment, and assessment against bottom-line results to maximize the impact of change.
Invest in management and governance. The need for change might be recognized by everyone, but change can't be led by everyone. There needs to be an owner responsible for program execution, working under the aegis of a governance body. Initiating process change without management and oversight creates a polyglot of initiatives but few leveragable investments and little demonstrable improvement. Similarly, a program needs oversight if it is to reconcile results and objectives to business needs. In serious change programs these are not high ceremony committees, but are action-oriented bodies.
So, This DOES Scale Up
Achieving organizational responsiveness through the disciplined execution of best practices presents a dichotomy: a coarsely-grained vision of business impact on the one hand, finely-grained reality of individual contribution on the other. Bridging the gap and successfully adopting these practices across the organization requires collaborative infrastructure, greater recruiting breadth, and oversight and governance of the change. It also requires an organizational and not just an IT commitment, with results of making the change clearly tied to business impact. This creates consistency, proficiency and durability in the way work is performed and charts a clear path to organizational agility.
About the Author
Ross Pettit has 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He is currently consulting to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement, as a consultant with ThoughtWorks.
{mos_sb_discuss:8}
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form