It is great
to end 2007 by looking back at what the Agile community has achieved. Organizations
have made tremendous strides, particularly in the areas of large, distributed Agile
projects and increased customer satisfaction. Competing Agile conferences, new
commercial and open source Agile tools, and a growing number of global Agile
consultancies all attest to the validity and benefits of Agile approaches. But enterprise-wide
Agile initiatives are still few and far between. Some of the issues on the
table for Agile teams are the same issues that have existed for software
developers for the past decade! Agility in software development emphasizes
small, frequent steps and continuous improvement; we can approach Agile
adoption in the same way. Agile approaches stress individuals and interactions,
so my suggestion for the coming year is to hone in on four core goals -- skill
development, incremental practice adoption, leverage of existing assets, and
the ever-present demand for better project visibility -- and see how far
they'll take us towards enterprise Agile adoption.
Back to the Future
I began
working with Agile teams in early 2000, as an analyst with Giga Information
Group (acquired by Forrester Research in 2003). At that time, the use of Agile
processes was limited to small projects in fairly sophisticated, "type A"
corporate development shops and to leading-edge product development companies.
However, even the broader software
development community at that time recognized the pragmatism inherent in Agile
approaches. Our research stressed that to be successful, software delivery
processes needed to:
Implement
iterative and flexible cycles.
Support
the increasing diversity inherent in the development community.
Retain
outside expertise for process transition and best practices.
Leverage
predefined deliverables and experiences.
What has
changed in that past seven years? Not much. For some companies, this list could
have been created today. But the means by which these requirements are achieved
using Agile processes differs from the waterfall and iterative processes used
in the past.
Advertisement
By
definition, Agile teams adopt incremental development and short, frequent
release cycles. Short release cycles don't make a team Agile in and of
themselves, but they do provide the framework by which value can be measured
and changes can be evaluated. Regarding team roles, there's no question that
the composition of an Agile team has grown to include business customers,
partners, and other external organizations. Without participation from those
outside of the core development team, Agile projects would not achieve the necessary
customer collaboration and responsiveness to change. In addition, the market
for Agile software development consulting and mentoring services has taken off,
acknowledging the demand for Agile skills. In fact, new entrants from Eastern
Europe and South America are threatening the success of U.S. and Asian offshore
firms with their Agile expertise and increased flexibility due to lack of language
and time zone barriers.
However,
the fourth requirement noted above is still a problem: it is rare to see an Agile
team leveraging the organization's past experiences and deliverables. I have
long argued that firms need to build incentives for teams and team members to
collect best practices and discrete deliverables from past projects and make
them available to future initiatives. Consulting firms are adept at this, as
leveraged work directly impacts profitability. But few IT shops really have
made this investment - "reuse" is still a bad word, connoting costs and
bureaucracy rather than productivity and quality benefits. So as we consider goals
for 2008, this legacy requirement really must remain on the list.
Call to Action for 2008
Can
making changes in a few areas make an Agile project successful? Of course not,
but I would argue that these incremental steps on the path to Agile adoption
are truly the most important.
Invest in your staff. Organizations are still
clamoring to build internal expertise rather than relying on third-party
resources. We continue to receive positive feedback from Agile developers
who cite the benefits of working on Agile teams and the importance they
place on their own skills development. Companies don't need to do this on
their own. For example, the Agile
University is offering a wide range of classes and events, addressing
both development and management topics.
Perhaps this is also a role that the Agile Alliance can play in 2008 -
spearheading training and mentoring initiatives that are process- and vendor-neutral.
Take small steps, but keep
moving. Most
teams have gotten past the religious issues of whether they should follow
an Agile approach such as XP, Scrum, or DSDM, or stick with a legacy
process. Yet there is still debate as to whether the selective use of
Agile practices within a more traditional methodology is really agile. Who
cares? I would challenge developers and project managers to share their
transitional approaches with the broader Agile community, particularly at
the Agile 2008 conference, and
demonstrate the benefits of incremental Agile adoption.
Don't start from scratch. We learned the benefits of
reuse years ago. Agile teams must also build environments to collect,
collaborate upon, and share "assets" for development teams. These assets
can include specific project deliverables (e.g., code, tests) or more
qualitative best practices for specific tasks in the Agile lifecycle. Call
it a knowledge base, repository, or whatever term will work in your
organization!
Publicize all that you can. Sorry if this sounds like a
broken record, but few teams have made progress in the area of metrics and
visibility. We demand visibility into our contractors' projects, yet we
don't seem to have the same level of scrutiny into internal projects. A
Business Scorecard model can be one of the most effective ways to
communicate a variety of metrics including operational status (e.g.,
quality, budget, schedule), contribution to business goals, customer
satisfaction, and even staff development - all of which contribute to the
success of an Agile (or any) initiative.
Note that
each of these four areas addresses individual and team collaboration issue far
above any technology issues. It's not a simple list, but it's certainly a
reasonable set of goals for savvy Agile organizations. Good luck in 2008!
About the Author Liz Barnett is the Editor in Chief of the Agile Journal and
Principal Analyst at EZ Insight Inc. Previously Liz spent 10
years as a Vice President and Research Analyst at Forrester Research, joining
Forrester as a result of its acquisition of Giga Information Group. Liz held
management positions at Accenture, PepsiCo, and Atelier Research. She also was
the Research Director for the advanced software development and advanced
network computing research services at New Science Associates, prior to its
acquisition by Gartner Group. Liz holds a patent for developing a distributed
application development/CASE tool. Liz earned her B.S. in operations research
and industrial engineering at Cornell
University.
Articles 
It is great
to end 2007 by looking back at what the Agile community has achieved. Organizations
have made tremendous strides, particularly in the areas of large, distributed Agile
projects and increased customer satisfaction. Competing Agile conferences, new
commercial and open source Agile tools, and a growing number of global Agile
consultancies all attest to the validity and benefits of Agile approaches. But enterprise-wide
Agile initiatives are still few and far between. Some of the issues on the
table for Agile teams are the same issues that have existed for software
developers for the past decade! Agility in software development emphasizes
small, frequent steps and continuous improvement; we can approach Agile
adoption in the same way. Agile approaches stress individuals and interactions,
so my suggestion for the coming year is to hone in on four core goals -- skill
development, incremental practice adoption, leverage of existing assets, and
the ever-present demand for better project visibility -- and see how far
they'll take us towards enterprise Agile adoption.
