TheServerSide.com SearchSoftwareQuality.

com TheServerSide Java Symposium

TechTarget Application Development Media TheServerSide.NET SearchSOA.com The Ajax Experience
Ajaxian.com SearchWinDevelopment.com

E-Guide

Agile Development
The SearchSofwareQuality.com E-Guide: Agile Development
offers an expert overview on best practices and pragmatic advice
on how to implement agile development methodologies. The
E-Guide provides insight on requirements gathering during the
agile process, how to manage upcoming agile projects and how to
assimilate current development practices with the new agile
methodology.

Sponsored By:
 Agile Development
Table of Contents

E-Guide

Agile Development
Table of Contents:

Can traditional project management and agile development coexist?

Agile development reshaping requirements

Software development groups take many routes to Agile

Agile development: It isn't just for small projects

Resources from IBM

Sponsored by: Page 2 of 13

 Agile Development
Can traditional project management and
agile development coexist

Can traditional project management and agile development

coexist?
By Colleen Frye, Contributor

Are traditional project managers and agile practitioners the Felixes and Oscars of the IT world? Are practices
outlined in the Project Management Institute's PMBOK Guide in conflict with the Agile Manifesto and agile best
practices?

While it may seem like an odd coupling, industry observers say the two methodologies don't have to be mutually
exclusive, but rather can live together and in fact complement each other.

In his research on project teams, analyst Dave West with Cambridge, Mass.-based Forrester Research has found
this commonality: "A smart agile project manager does a lot of things the PMBOK talks about without calling it
PMBOK, and a smart PMBOK project manager does a lot of agile things without calling it agile."

In Forrester's recent report, The PMBOK and Agile: Friends or Foes, which West co-authored, the recommendation
is to use the strengths of both approaches to boost project success. More importantly, the report recommends that
organizations tap into the specific practices and methodologies that work best for them and for particular projects,
rather than taking a one-methodology-fits-all approach.

Jim Johnson, chairman of The Standish Group, a project management consultancy based in Boston, concurs. "You
need to look within your own organization and environment, and understand what parts you want to keep and will
work within your process as you move forward. The whole project management thing is just doing the right things
right," Johnson said.

There are some misconceptions around both Agile and PMBOK that have led people to believe they are incompati-
ble, West said. One is that traditional project management is highly structured and inflexible and agile is highly
unstructured.

"Agile projects are a lot more structured and disciplined than people would expect," West said. "With continuous
planning and sharing transparently, there's a lot more control in agile than most people appreciate. And PMBOK is
not robotic. It's a series of good, sensible milestones and techniques."

Of course, there are some key differences. For example, according to the Forrester report, traditional project
management has a more "command and control" style, with the project manager ultimately responsible for the
project, while agile teams are self-managing and empowered. Work is also organized and assigned differently, with
agile teams deciding among themselves who will do the tasks, as opposed to a PM schedule of assignments and
tasks.

Also, in traditional PM, project managers disseminate status reports to team members and project
stakeholders/customers, while in agile the status is transparent to all team members and stakeholders/customers
are part of the team. Documentation -- how much or how little -- is also a difference.

Sponsored by: Page 3 of 13

 Agile Development
Can traditional project management and
agile development coexist

Perhaps the biggest sticking point is the perception that PMBOK prescribes a waterfall method, which West said is
another misconception. "PMBOK has fantastic content, but you read it in a sequential way, and then you apply it in
that way, so you assume it's waterfall, but it really doesn't advocate a particular process flow." However, he
acknowledged, "at the moment the [PMBOK] literature and material doesn't dissuade you from that."

Michele Sliger, consultant and co-author of The Software Project Manager's Bridge to Agility, said the Project
Management Institute (PMI) "recognizes agile is not a fad; it's a valid approach to software project management."
As such, PMI is creating a forum to help its members learn more about agile, and Sliger is part of the steering
committee. She said she expects PMI's agile program to launch in the second quarter of this year.

According to Forrester, PMBOK does bring some strengths to the table where agile is lacking. It provides:

* Clear guidance on project initiation and closure.

* Communications management and project integration management.

* Project cost management.

* Risk management.

On the other hand, agile also has some strengths PMBOK does not have. It promotes:

* Cross-functional, empowered teams.

* Flexibility and adjustment throughout a project.

* Encouragement of strong working relationships with customers.

* Just enough rigor and documentation.

While the role of the project manager does change in an agile environment, agile does not obviate the need for
project leadership, according to both Johnson and West. "I think the role of the project manager is an important
role. The project management profession and techniques have been worked on for years and have validity,"
Johnson said. The role is somewhat different, however, he added. "The project manager needs to be more of a
pipeline manager, to keep the flow going. The role is to make sure the pipe doesn't fill up and get blocked. Basically
it's just a faster way of doing things."

According to West, "The majority of agile projects have someone in a PM role even if they're not calling themselves
that; it may be the scrum master or a product owner, but you definitely have some people involved in leadership.
The difference is how you do leadership. Agile doesn't support command and control. Projects tend to be self-direct-
ing, so the project management role is more a coaching model or a mentoring model."

At Vignette, an Austin, Texas, Web content management company that has moved to agile, there are program
managers, "but their role has changed slightly," said Subu Subramanian, senior director of engineering. "They're
not as involved in the planning and coordination of the product development activities, except in cases of large,
multi-scrum projects, where they coordinate across the teams."

Sponsored by: Page 4 of 13

 Agile Development
Can traditional project management and
agile development coexist

He said their primary responsibilities are "managing the software release process, including early release/beta
programs; managing the technical enablement of our sales, service and support organizations; and coordinating
with external vendors such as for localization."

Basab Dattaray, engineering manager for new business initiatives within the TurboTax group at Mountain View,
Calif.-based Intuit, said the need for project managers is less with his group's move to agile. "We do have a project
manager whose primary work has been designing the user experience. We also have rotating scrum masters. We
usually spend only a small percentage of our time on project management. With agile I feel that the individual
team members feel empowered and take ownership, and hence the need for project management is somewhat
mitigated."

But in the end, West said, "Every project has somebody who worries about the things project management
classically worries about. The difference is how you execute on those concerns."

Sponsored by: Page 5 of 13

 Agile Development
Agile development reshaping requirements

Agile development reshaping requirements

By Colleen Frye

It's like a light bulb turning on. That's how Bob Schatz, agile trainer and consultant, describes the realization that
the traditional thinking around requirements needs to change in an agile environment. "The fact is, in these
iterative environments, things are being produced quicker; it almost forces people. You have to start thinking what
you really want, and do the most valuable things first."

In addition to prioritization, organizations need to think of requirements as more organic and negotiable versus
something that gets captured, specified and locked in with reams of documentation before a line of code is ever
developed, explained Schatz, who formerly led the successful agile transition at Primavera Systems Inc., where he
was vice president of development.

"Traditionally there's a big effort up front to collect all the requirements, and describe in text what you conceptual-
ize visually, so a 'contract' can almost come to life," Schatz said. "There is never an effort to think about prioritiza-
tion. No one is thinking things will change, and that there will be constant negotiation."

Schatz advises companies to focus on what the goals they trying to achieve with the project are and how the goals
are prioritized. Once that lesson is learned, the next task is determining what features and functions are needed to
achieve those goals? "Then, you prioritize, and in an iterative way start focusing on the highest value first," he said.

Forrester Research analyst Dave West sees three major differences in the requirements process for agile versus
traditional development projects. First, he said, the relationship between development and business is "more
collaborative and less confrontational." Second, both the size and complexity of requirements documents are
reduced, and other mediums are employed to express requirements.

"A lot of agile organizations use the user story—it's an invitation for a conversation rather than detailed specifica-
tion," said West. "It's a placeholder for collaborations and discussions vs. [a specification that says] 'the system
shall do this.' Does that always work? No, sometimes you need more specification, but traditional requirements take
this to the extreme."

Agilists use the right medium for their needs, West said. For some teams this may be a whiteboard, a video
recording or a PowerPoint, or a simulation tool like iRise, West said.

The third major difference, West said, is around scope. "One of the biggest challenges in a traditional project is you
go through requirements capturing by going to the business and asking them for everything they could ever want
around a system, and you get a complicated, long list of things." But the business only interfaces with that system
once, he said, and only when the system is delivered do they see that some of those requirements really aren't
right, or even necessary.

"With agile projects, [requirements] can incrementally develop, and scope changes as all parties get more of an
understanding," West said. "It reduces feature bloat."

Sponsored by: Page 6 of 13

 Agile Development
Agile development reshaping requirements

In addition to process changes, agile projects get more roles involved with requirements. "Probably the biggest
change is getting the end user involved," Schatz said. "It's something people are struggling with, especially with
getting feedback on what we've done." The fear of feedback, he said, is that the users will request a change, and
they typically will as the system evolves. "The dynamic there changes quite a bit. It gets away from 'give us the
requirements and we'll go away and deliver something.'"

But it's not just user involvement, West said. "Everyone is a lot more involved in requirements," he said, from the
customer to the business analyst to developers and testers.

That's true at Vertafore Inc., a Bothell, Wash.-based provider of software and services to the insurance industry,
said Chris Kinsman, vice president of development. "More of the development team is involved and interacts
directly with customers instead of just the business analysts," he said.

An agile development practitioner, Vertafore, is also changing the way it gathers requirements. "We have been
trying to move away from large functional requirements and more to a user story approach. We are still working on
this," Kinsman said.

Changing the approach to requirements with agile projects, however, doesn't mean abandoning everything
traditional. Agile projects still have some documentation, Schatz said, but "the documentation becomes more of an
artifact of what happened."

And some projects, and industries, require traceability and must prove compliance, such as software for medical
devices, said David Locke, Rational Director, Offerings Marketing, IBM Software Group. "It's an age-old problem," he
said. "In communicating and capturing requirements, you have to find the right weight." For a medical device that
needs FDA approval, he said, the process is rigorous. "It's heavyweight stuff, but you still need to be agile enough
to be competitive."

Mary Gerush, an analyst at Forrester, said agilists need to be realistic. "There are pure agilists that may shirk from
using a requirements management tool, but others recognize there are times you have to have rigor, so if there are
compliance issues you have to have traceability of requirements. Agilists in the real world understand that."

Gerush's colleague West said even traditional projects can benefit from some of the requirements techniques agile
organizations use, such a closer relationship with business and delivering more appropriate requirements artifacts
vs. huge documents. However, he said, the frequent delivery of working code and constant reevaluation of require-
ments would be difficult to apply to a traditional project.

That said, the question remains, does an agile approach help organizations produce better requirements? "We
haven't gotten better at producing requirements, but I would argue we have gotten better at delivering what the
customer truly wants," Kinsman said. "This can in many cases be very different from what the former requirement
documents set out."

Sponsored by: Page 7 of 13

 Agile Development
Software development groups take many routes to Agile

Software development groups take many routes to Agile

By Colleen Frye, News Writer

No doubt Agile development methodologies are making inroads in today's enterprises, but the road to Agile is far
from straight and narrow. It's more like a multi-lane highway, with all types of drivers taking a variety of routes to
their destinations. And according to respondents to SearchSoftwareQuality.com's 2008 Agile Trends survey, the
waterfall methodology is not always the road less traveled.

For those survey respondents developing with Agile techniques, Scrum is the most popular (41%), followed by
Extreme Programming (XP) at 15%. Others use a hybrid of Scrum/XP (14%), and 13% use a custom or other type
of hybrid Agile methodology. And the Crystal and Dynamic Systems Development Method (DSMD) both have a
following of 3%.

Many organizations use the parts of Agile that work best for them rather than taking a purist approach.

"Agile has lost some of its more technical meaning. So, on one hand I think Agile is growing, but not the strict XP
or Scrum, but some modification of them," said Justin Gehtland, president and co-founder of Relevance Inc., an
Agile consulting and development company in Chapel Hill, N.C.

"Scrum is fairly straightforward and simple and is easy to adopt," said Scott Ambler, practice leader for Agile
development at IBM. "The main focus is on team leadership and requirements management. It doesn't get into the
technical practices XP gets into, nor does it [cover] the lifecycle details of the Unified Process."

No methodology covers everything, Ambler said. "My advice is [a methodology like Scrum] should be part of an
overall palette of processes. The process you follow has to fit the situation you're in. Everyone is finding Scrum is
not sufficient, XP is not sufficient, Agile modeling is not sufficient. They all address subsets of the overall process.
So you have two choices. You can put together your own process, which seems to be the flavor of the day, taking
the best of Scrum, XP, etc., and reinvent it; or you can take RUP [Rational Unified Process] and tailor it down to
something that meets your needs."

Toronto-based LYNXDev Inc., which provides business solutions to the financial services industry, is a good example
of this a la carte approach.

"Although we do not use a formalized methodology or process, I would consider the development process that we
do use to be aligned very much with the concepts of an Agile methodology," said Steve Whatmore, a Java architect
there. "We used certain aspects of a RUP methodology injected with a much shorter development cycle and much
less formalized requirements."

He continued, "Since we are a small ISV that works directly with a large number of financial institutions, we are
finding that typically our clients are requesting a RUP-based development methodology. However, we have found
that the overhead and process inherent in a RUP-based methodology doesn't fit well in our application space, and

Sponsored by: Page 8 of 13

 Agile Development
Software development groups take many routes to Agile

thus the effectiveness of a RUP-based methodology is somewhat limited. Typically, we end up with a modified
RUP/Agile methodology."

Nari Kannan, CEO of Ajira Technologies Inc., a Pleasanton, Calif., developer of service process management
solutions, also mixes and matches Agile methodologies to fit his organization's needs.

"We really don't believe in a lot of named methodologies," he said. "We pick and choose whatever works for us.
We're also not dogmatic about doing all those rituals, at the same time every week. Sometimes we do weekly
builds; sometimes we do them every few weeks. If you have a lot features sometimes it makes sense to wait a few
weeks. We keep it flexible."

Holding on to waterfall

Other organizations have not gone the Agile route yet.

"To my knowledge Health Net has not formally rolled out any agile methodologies, though I believe some of our
Web teams use a more iterative approach informally in some of their smaller projects," said Cooper Zale, business
systems analyst at Health Net Inc., a managed health care company in Woodland Hills, Calif. "Health Net is still
very process immature and is just grappling with agreement to consistently follow any methodology at all."

Zale continued, "As our first step forward in consistently following a methodology, we have adopted a traditional
waterfall system development lifecycle that we are working to implement across the enterprise."

Zale's organization is not alone. Among the SearchSoftwareQuality.com Agile survey respondents, waterfall is
neck-and-neck with Agile. Among the respondents, 45% follow Agile methodologies, while 44% use waterfall. Other
development methodologies cited were test-driven development (19%) and RUP (15%).

"Waterfall is not going away," Ambler said. "It's definitely shrinking in popularity because it's not as effective, but a
lot of organizations still cling to the old ways. A lot of organizations are comfortable with that. It's what they know,
and they're happy with their success rates. There's an opportunity there to do better, but it takes time. Iterative is
a step in the right direction."

According to Ambler, organizations can't flip a switch to Agile.

"For IBM it's a multiyear transition," he said. "We're the largest organization in the world transitioning to Agile. We
definitely have some waterfall teams, and we probably still will five years from now."

For those organizations that haven't started down the Agile path, there is an appeal, however. Among the survey
respondents who don't currently use Agile methodologies, over 60% said they had some interest.

Industry observers suggest, though, that not all organizations will be all Agile all the time, and that it will depend
on the project and the developers themselves.

Sponsored by: Page 9 of 13

 Agile Development
Software development groups take many routes to Agile

"Large organizations that used to have heavy top-down development are branching into trees with some projects
that are Agile and some that are not," said Relevance's Gehtland. "So a person working on projects that aren't Agile
might not know that there are Agile projects going on at their company, and in a survey will say the company is not
using agile."

In addition, "Not all projects will be Agile," Ambler said. "Going Agile across the board is going to take some
flexibility. You have to understand what the problems are and what the challenges are."

And finally, "agile" can mean different things to different teams. "Agile means different things on different projects,"
said Per Kroll, chief architect, Rational Services, IBM. "What works for one project may not work for another."

Former Editor in Chief Michelle Davidson contributed to this report.

Sponsored by: Page 10 of 13

 Agile Development
Agile development: It isn’t just for small projects

Agile development: It isn't just for small projects

By Colleen Frye, News Writer

For organizations wondering if they can utilize the agile methodology for large-scale development products, IBM's
Scott Ambler offers this thought: Bureaucracy and discipline are two different animals.

Meaning, "A lot of traditional development is based on shaky theoretical foundations that don't reflect human
behavior. It's not viable in many organizations," said Ambler, practice leader, agile development, with IBM Rational.
"The agile community has a higher focus on quality and value; we're a little smarter about the way we work."

He added, "Many traditional organizations suffer from the misconception that bureaucracy equals discipline, but
bureaucracy is bureaucracy and discipline is discipline."

In fact, asking if agile can scale is the wrong question, said Damon Poole, founder and CTO of AccuRev Inc. in
Lexington, Mass.

"The question to ask is, 'How does software development scale in general?' Traditional development doesn't scale
very well anyway; you hear all the time of large projects that were cancelled or delayed. Scaling is independent of
methodology," he said.

Does Poole believe agile scales better than traditional methodology? "Absolutely." However, he added, "There's a
question of proven scalability. There are fewer proof points of agile scalability; that's just the way it is because
there are fewer large projects. But look at the algorithm of agile development. There's more in it that allows you to
scale."

In a SearchSoftwareQuality reader survey conducted earlier this year, more than half of the respondents (53.52%)
cited agile team sizes of four to nine, while 22.54% cited agile teams smaller than three, and 19.72% of respon-
dents cited agile teams of 10 to 20. Just 1.41% of respondents cited agile teams of 20 to 50, and 2.82% had
teams over 50.

Perhaps reflecting the small amount of large-scale agile projects, just 16.9% of respondents cited scaling as a chal-
lenge to using agile, while more than half (52.11%) cited communication as a challenge, followed by documentation
(47.89%) and resistance to change and tool integration (both at 23.94%).

Scaling agile using sub-teams

At IBM, Ambler said there are other agile projects on the order of 500 to 600 people. To manage large teams, both
Ambler and Poole agree the project needs to be broken down into smaller components and sub-teams.

"There's no magic to this," Ambler said. "The architecture should be a system of subsystems."

Sponsored by: Page 11 of 13

 Agile Development
Agile development: It isn’t just for small projects

He said the structure of the teams should be aligned with the architecture, and ideally the sub-team members
should be co-located.

"The worst way to do this is to have the business analyst in Toronto, the test analyst in London, etc.," Ambler said.
"You'd get a phenomenal amount of coordination required among these sites, across time and geographic
boundaries, which increases cost and risk."

Poole is on the same page: "Making teams bigger is problematic; you don't want teams to get bigger than 10 or so
people for any kind of development. Say you've got a product and you've got 250 people working on various
aspects of it. You could say you have a team size of 250, or you've got 25 10-person teams and set it up so the
teams are all working on something of appropriate size. To scale, you have to have a componentized software code
base so people can work on different components and communicate API changes, and put team members in the
same locations so you have good communication."

Sponsored by: Page 12 of 13

 Agile Development
Resources from IBM

Resources from IBM

The IBM Rational Jazz Cultural Revolution by Ovum analyst Laurent Lacha

Rational Agile Development Solutions eKit

Agile Eval Guide

Agility at Scale: Become as Agile as You Can Be

EZ Insight: The IBM Rational Jazz Strategy for Collaborative Application Lifecycle Management

Delivering Continuous and Measurable Improvement in Your Business

About IBM
IBM® Rational® provides an agile solution that includes agile practices, process improvement
services, training and mentoring services, and products to help companies succeed in an Agile
development environment - regardless of their agile maturity level.

Sponsored by: Page 13 of 13