IT organizations face increasing pressure to reduce budgets, improve quality, and deliver more quickly. These business demands quickly come face-to-face with current IT practices: cumbersome requirements management, opaque project management, complex architectures, and lengthy testing cycles. Recognizing the need to be "more agile" in response to these pressures, IT teams are increasingly looking to Agile practices. Because they distill the essence of IT execution into a collection of efficient, waste-free activities, Agile practices offer an intuitively appealing way of working.
However, because these practices contradict many entrenched behaviors, making the change is not a simple undertaking. In the traditional IT approach, there are long and distinct phases of activity including design, analysis, programming, testing, and deployment. These phases are linked together by artifacts such as use cases, coding specifications, or test cases. IT management controls budget and assures delivery by defining abstract gatekeepers that must be satisfied before each phase completes. Agile takes a much different approach. Design, development, and testing are continuously performed in short delivery cycles using highly collaborative processes. Activity is linked together by people, not artifacts. IT is managed by the alignment of all parties behind the successful delivery of working software and commitment for the next delivery. Clearly, "going Agile" can be a big change from the status quo.
Advertisement
The path of Agile adoption is well trod, but poorly lit. Each organization, each project, presents unique challenges and obstacles. Agile work processes must be specific enough to be understandable, defined enough to be repeatable, malleable enough to change with experience, and flexible enough to accommodate a wide range of operating realities. A sufficient breadth of Agile practices must be brought to bear on a situation or the practices will yield few benefits. The people performing them must master these new practices quickly or the process change will be perceived as providing little value.
When transitioning to Agile practices, managers must be attuned to several dichotomies. In making the change, are enough practices being undertaken, or is it a case of trying to do too much too fast? Do people approach the change with a healthy skepticism, or are they passive-aggressive toward making change? Does transparent execution expose problems or do teams game results to hide performance? Recognizing these "fine lines" separates a successful Agile adoption from a failed change initiative. The challenge to the aspirant Agile manager is to convert the forces that resist change into forces that enable change.
Changing Too Little or Not Nearly Enough?
There are distinct Agile practices for every software development activity, including programming, requirements, design, project management, testing, build, and deployment. This breadth of practices creates a conflict when transitioning to Agile. At one extreme, the wide variety is intimidating. It can be difficult to choose a place to start, so teams may choose to adopt only one or two practices, such as continuous integration or iterative delivery. Making too little change can leave a team no better off than it was before, as unchanged habits (e.g., large use case-based requirements) can negate the impact of Agile practices (e.g., short delivery iterations). At the other extreme, the interrelationships of the different Agile practices make it appear that they all need to be adopted. For example, unit testing increases the certainty that an Agile requirement (called a "Story") is fulfilled, which in turn makes iterative project management very accurate. A team may decide to begin doing all of these things, all at once. Whereas too little change may have no material impact, too much change can be destabilizing. Thus, any Agile adoption has the inherent risk of either trying to do too much, or not doing nearly enough.
Bear in mind three questions when transitioning to Agile practices.
Which specific practices will make the biggest impact in your current situation?
To what level of proficiency do each of these practices need to be executed?
By what point in a project do these different practices need to be mastered so that they make an impact?
When beginning a transition to Agile, the first question is: what practices will make the biggest impact in your current situation or project? Agile practices can demonstrably increase quality of deliverables, increase operating transparency, and accelerate time to market. There is a clear interplay among these three objectives, but when setting out to make a change, target one goal at a time. This makes it easier to focus change efforts. For example, if the primary driver is to increase quality, focus on unit testing, test automation and build pipelining. If the goal is to accelerate time to market, adopt Agile requirements, estimation and prioritization practices, and continuous integration. If the goal is to create greater operational transparency, introduce Agile project management, requirements, and unit testing. Once the initial goal is demonstrably met (e.g., quality metrics show improvement), pursue another goal (e.g., faster time to market) and examine further opportunities for change. Agile practices lend themselves to cycles of continuous improvement; exploit that in the pursuit of goals met through process change. Goal-oriented incremental change is of far lower risk than a big change event.
The latter two questions - proficiency and time - are reminders that work practices are always changing, and that committing to an Agile transition is a conscious decision to alter the patterns of change. Recognizing that there are different levels of proficiency acknowledges that Agile is not something that is performed or not performed. That is, a team will not work in a collaborative manner one day when it didn't the day before. A team will progress through several stages of collaborative maturity. This expectation must be well understood as it will have significant impact on decisions by management and behaviors of executors. An Agile Maturity Model helps to chart the path of maturity and shape expectations. Being aware that change takes place over time exposes assumptions inherent in a change program. Business, employee, and technology changes can upset - or enable - an Agile transition. A successful change program is not the pursuit of a fixed vision, but is re-framed to reflect new opportunities and operating realities.
Healthy Skeptics versus the Passively-Aggressive
Rolling-out change can produce any number of reactions from the people who are the object of that change. Specifically, people may interpret the call for change as a professional indictment that they're not effective at their jobs. As a result, change will be challenged. This can be healthy: someone who challenges a practice is more likely to gain a very good understanding of it. Challenge can also be unhealthy. Practices may be ignored outright, or performed to minimal levels of effort. People may write unit tests but nobody looks to see whether they pass or not. Requirements might be written as short statements, but may be purely technical in nature. Such disengaged execution means it will be "business as usual," with IT pretending to operate under a different process. This will confuse business partners and discredit change efforts.
Skeptics are convinced with results. Initiate change in high-profile projects that demonstrate benefit of Agile practices. For example, write a few well-placed unit tests over complex code that is undergoing significant modification. It won't take long before a unit test detects a defect that would previously have escaped development. Another suggestion is to create a cross-functional team of business representatives, programmers, and testers and have the team deconstruct a complex use case into a collection of Agile Stories and iterate through delivery in priority order. It will only take a few iterations before the time-to-delivery benefits of Agile practices become obvious. Once these benefits are clearly established, the loudest skeptics will become vociferous champions, and fence-sitters will lose their perch.
The Double Edge Sword of Transparency
When following Agile practices, there is much greater confidence that work reported as done is actually done. This is because of the completeness of Agile execution. Code and unit tests are delivered for each requirement. The software is subject to continuous integration. Each requirement undergoes business and QA review as it is delivered. When an Agile project management "burn-up" chart is used to track progress, there is very accurate, up-to-the-minute visibility into the performance of a development team. This transparency makes it easier for management to make decisions: Are dates at risk? Are there enough people on the team? Do features need to be removed from scope? It can also make people in the team uncomfortable: a poorly performing project reflects on the people in the team. People can thus be motivated to game the numbers. They can do so by elevating technical tasks to the equivalency of Agile Stories, making it easier to show progress. They may also substitute "developer complete" as opposed to "business sign-off" as their definition of "complete." Agile practices engender management confidence only when execution is consistent with canonical definitions. When execution strays from these definitions, performance is disguised.
Quantitative analysis provides a valuable means of assessing project performance. The IT industry is today awash in performance data, and Agile project management introduces many measures uniquely its own. Numbers, however, don't tell the whole story of a project. It will always be management's responsibility to understand the story behind the numbers. This comes from understanding the qualitative aspects of a project: Are requirements business-centric or technical in nature? Are the people of high or low capability? Is the business customer engaged or not? Reading the numbers can expose a host of delivery risks such as delivery date, budget, scope, but these numbers are less reliable for exposing operating risks, such as the level of understanding the team has for the domain, or the team dynamic itself. Good management transcends process; process does not substitute for it.
Transitioning to Agile: A Better Development Organization or Another Failed Change Initiative?
Agile change initiatives are inherently ambitious. It is no small undertaking to initiate fundamental behavior change while simultaneously delivering software in a turbulent business climate. What may appear to be simple process changes can create unintended reactions and encourage the wrong types of behaviors. The transition to Agile has less to do with the specific practices and more to do with mastery of the opposing stresses of change. This phenomenon of change, this balance of forces, is also present in any Agile development project. Projects don't succeed because of dogmatic adherence to a process; they succeed because disciplined and informed people collaborate and adjust to meet evolving goals in a dynamic business environment. For an Agile transition to succeed, the instigator of change must be prepared and capable of doing the same.
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 has most recently consulted to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement. He is a frequent speaker and active blogger on topics of Agile management, governance and innovation. He is currently a Client Principal with ThoughtWorks.
IT organizations face increasing pressure to reduce budgets, improve quality, and deliver more quickly. These business demands quickly come face-to-face with current IT practices: cumbersome requirements management, opaque project management, complex architectures, and lengthy testing cycles. Recognizing the need to be "more agile" in response to these pressures, IT teams are increasingly looking to Agile practices. Because they distill the essence of IT execution into a collection of efficient, waste-free activities, Agile practices offer an intuitively appealing way of working.
