In the latest VersionOne State of Agile Survey, ninety percent of the respondents reported improvement in managing changing priorities by implementing agile. This is not a big surprise since agile is often billed as being able to respond to changing requirements.
In that same survey, eighty five percent of the respondents reported an increase in productivity. Since agile development is a lightweight approach to software development, we should expect an improvement. Less overhead – while retaining the necessary framework for coordinating and managing work – certainly contributes to improving productivity.
Couple this with a few other ingredients like greater collaboration, combining of conventional tasks to reduce formal handoffs and practices designed to increase feedback and produce working software in short cycles with quality, and we have the critical elements in place that lead to greater productivity.
Here’s a reported benefit from the VersionOne survey that might make you think: Eighty-four percent of the respondents reported an improvement in project visibility.
Despite all of our planning, reporting and tracking with non-agile approaches, agile still manages to improve project visibility. What is the difference?
With agile, we gain visibility through transparency, and this is achieved by changing our orientation. How does your reporting and control structure look and feel? Is it designed for centralized control where the information being reported is designed to meet the needs and desires of those being reported to?
Agile makes use of artifacts that are simple, fast and of direct relevance to those performing the work. A small amount of overhead is required to maintain this information compared to non-agile approaches, and coupled with regular reviews of working software everyone is fully informed about just where the team is at – for real.
What agile doesn’t do is pile on more reporting and metrics to what you already are doing. This is one thing that many organizations can consider doing less of; how much time and effort is required of people who are performing the work to also generate reports and attend status meetings, taking valuable time away from their work? Too much tracking, reporting and status meetings about progress actually obfuscates our view as opposed to enhancing it, not to mention placing a burden on the people performing the work.
Other key benefits cited in the VersionOne survey include:
- Improved team morale
- Enhanced quality
- Reduced risk
- Faster time-to-market
- Better alignment between IT & Business Objectives
Superior ROI. Agile emphasizes delivering early and often, enabling the business to begin generating a return on its investment much earlier. Agile does ask for discipline and participation from the business as part of the deal, such as rigorously prioritizing the features and being available to answer questions during the development cycle. In return, the business gets its highest-valued features delivered early, and delivered with quality.
Software Agility Supports Business Agility. In order to capitalize on opportunities, the capability for a business to adapt and respond to change is critical. Software development practices shouldn’t run counter to business needs by forcing the business to choose and adhere to a set of pre-determined features that will be delivered months, if not years (in extreme cases), into the future.
Sustainable Pace. There are a number of problems with the regular use of overtime, including more mistakes being made by tired employees, risk of costly turnover, and the simple fact that a delivery model that requires constant overtime is not sustainable in the long run.
Emergent Innovation. Some innovations materialize from efforts pursued outside of day-to-day projects. However, the collaborative nature of agile development creates the opportunity for innovations to occur because solutions are shaped collaboratively between the business and the development team. The business articulates what it wants to achieve and why and the development team contributes ideas on how to accomplish the goal. This dialog between business experts and the technical experts can yield unexpected results, like turning complex, difficult features into simple elegant, differentiating features.
Stronger Relationships and Trust. Agile development fosters true collaboration as opposed to individuals working on a cooperative team that is orchestrated by a project manager. As team members collaborate and learn from one another, they build stronger relationships and trust that helps them achieve even greater productivity. Relationships and trust are also built between the development team and the business through continual dialog, collaboration and the frequent delivery of working software. The collaboration and ability for the business to regularly inspect and adapt the software gradually changes the “us versus them” dynamic into a “we.”
Continuous Improvement. Agile development expects its practitioners to be continually learning and adapting. Agile teams not only routinely inspect and adapt what they are building, they inspect and adapt how they are building it. Agile team members are expected to assess their teamwork, their use of (or lack thereof) technical practices, and their overall approach to work and to make adjustments (experiment) to improve.
As I’ve considered my own experience and thoughts on agile development – supplemented by reading, training, and interacting with others – I’ve captured what I consider to be possible with agile, framing it as a challenge. This is what we all want; it’s a question of how we go about achieving it.
Produce greatest possible, high-quality quality customer outcomes…
…in the shortest amount of time possible
…using the least amount of effort
…at the lowest possible cost
…keeping risk reduced
…while creating a sustainable, rewarding, and satisfying work environment that supports learning and continuous improvement.
My assertion is that agile development can help us meet this challenge, if we allow it to. The remainder of this book will explore how agile development makes this possible.
A Brief Definition of Agile
You’ll frequently hear agile development described as “iterative development.” You might feel that with agile we are incrementally building software, so which term is correct? Should we use both terms? Let’s level set on these terms:
Incremental development is about building features one at a time and delivering them in small units of time. It is about delivery and progress; a project team increments its way towards an end goal.
Iterative development, is about refinement and re-work. Let’s say that after a software team delivers a feature, the customer requests a modification to that feature. The team then circles back – iterating – to re-work the feature to better meet the needs of the customer.
While we do both with agile, these days I keep the more popular term “iterative” as well as “incremental” out of my actual definition of agile. Iterating is a strategy for maximizing value, but it doesn’t describe agile well enough for my tastes. Instead, I prefer to characterize agile as being adaptive and responsive, or more fully:
Agility is a quality (and willingness) of the people and the organization to quickly adapt using the least amount of effort and cost when adapting to:
Changing business conditions and requirements
I’ll refer back to this definition and build on it in future chapters to make it more complete.
This post is a draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran
VersioneOne. (2012). 7th Annual State of Agile Survey.