You’ve heard the buzz: Agile development is all about solving the problems associated with traditional software development. The Agile Manifesto states, “We are uncovering better ways of developing software by doing it and helping others do it.” But just what is better about Agile development?
As a software development manager, I’ve had to consider this very question as we’ve progressed from testing the Agile waters to a full-blown implementation of Agile across our organization in the past few years. My thinking and this list are the result of my personal experience with Agile, numerous conversations, training, and plenty of reading on the subject of Agile development written by other experienced, very capable practitioners.
1) Superior ROI.
With many software projects, the
business is forced to wait for the completion of the entire project before it
can begin deriving a benefit from that investment. Given the challenges in
meeting software schedules, those on the business side of the house not only
have to wait for delivery of the software, they have the potential to be disappointed
in a couple of ways:
a)
Features are trimmed from the final delivery.
b)
Quality trade-offs are made.
(There are other ways to be
disappointed, and many are addressed in this list.)
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.
2) Business agility is embraced.
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, into the future.
Agile development welcomes and
adapts to change. Because software is delivered in short iterations (measured
in a few weeks) from a prioritized backlog of features, Agile development
projects are able to easily adapt in accordance with changing business conditions.
3) Agile development reduces risk.
There are a number of risks
(a.k.a., challenges) with every software project. Schedules, budgets, scope
creep, and one of the most demoralizing for everyone involved – particularly if
you’ve exceeded your planned schedule and budget – delivery of software where
the users “got what they asked for, but it isn’t what they wanted” because the
requirements were not understood in the first place. (This sometimes
masquerades as “changes in requirements.”)
Agile development seeks to avoid
these issues with frequent delivery of working software that allows the
business users the opportunity to provide feedback based on frequent
inspection. This permits the team to make immediate corrections if there was a
misunderstanding.
The frequent delivery of working
software also keeps schedules and budgets in check. There is complete
transparency and certainty about the progress of the team because the features delivered
slice vertically through the architectural layers. This eliminates the late-stage
integration and quality issues suffered with software projects that use different
delivery mechanisms.
Finally, the business has the
option of discontinuing further investment and retaining what has been
delivered at any time, instead of being forced to make a full (or greater) investment
in order to build out the software to a state where it is suitable for use.
4) Agile development increases productivity.
Producing software that meets the
needs of the business requires the involvement of knowledge workers from a
variety of disciplines – business and technical – to work together. Agile
development focuses the team’s attention like a laser on delivering the
highest-priority, highest-valued features in short increments of time using the
most productive mechanisms to accomplish the work.
As part of this delivery, Agile
development goes beyond using directed teams that are in reality nothing more
than a collection of individuals working on assigned tasks. Agile teams embrace
collaboration in the truest sense of the word; there are shared goals, shared
knowledge, shared learning, shared progress, and a shared responsibility by the
team to meet its commitments.
Another productivity increase
comes from teams operating autonomously, where the teams make informed
decisions about their day-to-day work without the need for constant managerial
direction. Not only does this expedite certain decisions by keeping them
localized, employees who have more control over their day-to-day work are more
energized and engaged about their work.
When an autonomous, highly
collaborative, multi-disciplinary team is firing on all cylinders, the
productivity gains can be extraordinary.
5) Agile development creates a sustainable development
environment.
Software projects rarely meet
their initial schedule. Overtime with the mandate to “work harder” is
frequently used as it becomes apparent that a project will be running longer
than anticipated. Often times, frustrated managers feel justified in holding
those who provided the estimates at fault for not meeting their commitments –
in spite of the fact that an estimate is supposed to be an approximation and
not a precise figure.
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 constant
overtime model is not sustainable in the long run.
Agile development sizes User
Stories in points and tracks team velocity – the User Story points that are
completed in each 2-4 week iteration. Over a period of time, it becomes crystal
clear how much work can be realistically accomplished by a team on a
sustainable basis. The goal then becomes one of working smarter to improve, not
harder.
6) Agile development enables emergent innovation.
Big innovations are easy to recognize,
but hard to come by; they typically materialize from work outside of day-to-day
projects. Because Agile creates a sustainable development environment, a
greater opportunity exists for innovation to emerge from the employees. Teams
that are working constant overtime to meet schedules simply lack the time or
inclination to think about anything else other than the difficult schedule in
front of them. In sustainable development environments, people have the time to
think more about the business and explore – creating the potential for
innovation that did not exist previously.
Even on “routine” tasks, the collaborative
nature of Agile development creates the opportunity for smaller innovations to
occur. Requirements are discussed as User Stories, involving what the business needs
along with the benefit that it hopes to realize. The important aspect of this
is that the requirements aren’t considered to be cast in concrete; there is a
discussion about what the business is hoping to achieve.
The discussion yields important
insight and understanding for the entire team. The worst-case scenario is that
everyone will be on the same page. At other times, the dialog between business
experts and the technical experts can yield unexpected results, like turning
complex, difficult features into elegant, differentiating features.
7) Agile development builds trust and relationships.
Through early and often delivery
of working software to the business – even if this is nothing more than
demonstrating the features – the business will grow to trust the development
team. In addition, the continual dialog and the ability for the business to
adjust and adapt the software gradually changes the “us versus them” dynamic
into a “we.”
The same will happen for the
members of the Agile development team. Instead of everyone divided by
functional roles, Agile teams make the most effective use of the team members
as dictated by the needs of the team to meet its commitments. The shared goal
becomes more important than each individual working strictly within his or her
area of expertise, with defined policies and procedures for handing off work
between functional roles. This breaks down barriers between functional
disciplines, enabling the team to reach higher levels of productivity.
8) Agile development expects continuous improvement.
Agile development expects its
practitioners to be continually learning and adapting, and is something that is
enabled in part through sustainable development. Sustainable development
provides the time and energy for the development team to expand their working
knowledge of their profession through self-learning.
In addition, Agile teams conduct
regular retrospectives at the end of each iteration to review what is working
well and what can be improved. Team
members are expected to assess their teamwork and their use of (or lack
thereof) technical practices and to make adjustments in the upcoming iteration
to improve.
9) Agile development is motivating and engaging.
Agile recognizes
that knowledge workers have the greatest understanding about their own work,
and that they are the ones best qualified to plan and organize how they will
accomplish that work. Agile development utilizes an autonomous, self-directed
work environment that is a powerful motivator. This
control over their workday, plus operating in a sustainable mode and the
feeling of accomplishment that is a by-product of continuous delivery of
working software, all combine to provide a solid motivational boost to each and
every person on an Agile team.
10) Agile addresses
the realities of software development and the needs of the business.
The
challenges that every software project faces stem from the fact that we’re not
producing pre-defined widgets; there is uniqueness involved with every software
project. Agile development’s entire approach addresses the major problems
encountered with software projects and managing talented knowledge workers while
being aligned with, and responsive to, the business.
I’ll close where I opened. There
is a reason that the Agile Manifesto states, “We are uncovering better
ways of developing software by doing it and helping others do it.” Agile is a
better way.

3 comments
While in general I agree agile makes sense, my experience shows agile only works when the rest of the company gets it.
June 25, 2010 at 12:55 PMIf you have stakeholders ("chickens") who don't participate, who continually add or change features in the middle of sprints, and who push all the project management off onto the team, agile fails, just like any other methodology will fail.
Likewise, if the team members don't get agile or the team is too small or too heterogeneous for team members to self-select their issues, agile will sputter.
If some of the team is offshore, well, you have bigger problems: your management confuses quantity with quality.
However, not everyone has a work environment as dysfunctional as mine.
Burndown charts are a great tool for showing actual progress, and mine also show the accumulation of new requirements as the sprint progresses.
Sprint retrospectives are a good way to talk about what work, what didn't, and what we can do about it: this promotes team buy-in.
Getting to your article, I take issue with some of your claims.
4) Agile development *can* increase productivity, but it depends on the rest of the organization being involved.
6) Wow, sorry, my BS detector goes off when I see "innovation." If you read Scott Berkun's work, it's pretty clear innovation can happen in some very unusual places, like the Soviet Union during the Cold War, which is about as far from agile as you can get. I'd say agile can lead to a healthier work environment - less stress, more time to think about things instead of jumping in and coding.
7) Again, I'd use *can*. If the rest of the organization is working with you, agile can help earn trust by letting you make and meet commitments.
8) I have to call BS here. All methodologies assume the people involved are bright, motivated, and want to do better. I'd say agile *encourages* continuous improvement, not expects.
Finally, this "knowledge worker" phrase is a bit tired. I am an *engineer*: while I have taken some computer science courses, I started off as a "real" engineer (nuclear) and think much of the problem we're dealing with is students being taught computer science instead of software engineering.
Anyway, that's my 2¢, and thanks for the article.
All you say about Agile is right & great. But then I look at your profile on the right side and it says "manager". You can be a great manager if you understand Agile. But the one point is that it has to start with the programmers. You can not order it. Let the guys who do the work do whatever they want. Then nudge them into an easy way to interact with managment and schedules. Every time I see Agile fail it is because it is top down. Now I think of it more as a tool that enables managment to work with bottom up.
June 26, 2010 at 8:43 AMPost a Comment