AAggiillee DDeevveellooppmmeenntt

Sponsored By:

EE--GGuuiiddee

TechTarget Application Development MediaTheServerSide.comTheServerSide.NETAjaxian.com

SearchSoftwareQuality.comSearchSOA.comSearchWinDevelopment.com

TheServerSide Java SymposiumThe Ajax Experience

The SearchSofwareQuality.com E-Guide: Agile Developmentoffers an expert overview on best practices and pragmatic adviceon how to implement agile development methodologies. The E-Guide provides insight on requirements gathering during theagile process, how to manage upcoming agile projects and how toassimilate current development practices with the new agilemethodology.

Sponsored by: Page 2 of 13

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

AAggiillee DDeevveellooppmmeenntt

EE--GGuuiiddee

Agile Development

Table of Contents

Can traditional project management and agile developmentcoexist?

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.

Agile Development

Can traditional project management and

agile development coexist

Sponsored by: Page 3 of 13

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

Can traditional project management and

agile development coexist

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."

Agile Development

Agile development reshaping requirements

Sponsored by: Page 6 of 13

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."

Agile Development

Agile development reshaping requirements

Sponsored by: Page 7 of 13

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

Agile Development

Software development groups take many routes to Agile

Sponsored by: Page 8 of 13

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.

Agile Development

Software development groups take many routes to Agile

Sponsored by: Page 9 of 13

"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.

Agile Development

Software development groups take many routes to Agile

Sponsored by: Page 10 of 13

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."

Agile Development

Agile development: It isn’t just for small projects

Sponsored by: Page 11 of 13

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."

Agile Development

Agile development: It isn’t just for small projects

Sponsored by: Page 12 of 13

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 IBMIBM® Rational® provides an agile solution that includes agile practices, process improvementservices, training and mentoring services, and products to help companies succeed in an Agiledevelopment environment - regardless of their agile maturity level.

Agile Development

Resources from IBM

Sponsored by: Page 13 of 13