How Is Agile Software Development Adopted?

[martinig]

Hello,

I have read an interesting article on agile approach adoption in http://www.methodsandtools.com/archi...hive.php?id=43. I would be interested in knowing how other organisations are adopting the same practices.

[Lori]

I'd be interested in hearing that, too. Which methodologies are people implementing?

Lori

[martinig]

From what I see/hear, companies are more looking to pick interesting items than adopt complete approaches. Shorting the delivery cycle is an important goal and it seems that Scrum is attractive with its project management tools.

[shercorp]

Based on my research, it will depend on what suits the company. Most of the methodologies in agile can be combined thus making it more appropriate to the company. In our case, we're planning to discuss each methodology and maybe come out with at two or three methodology and pick up the principles that we can apply in our existing approach.

[martinig]

VersionOne recently conducted a survey sponsored by The Agile Alliance on agile adoption. This study saw the participation of 722 respondents. Among those, 84% of the organisations had adopted agile practices. Scrum was the most widely followed agile methodology.

Sources:
http://www.versionone.net/surveyresults.asp

Other sources of Agile adoption surveys:

http://www.methodsandtools.com/dynpo...poll.php?Agile
http://www.ambysoft.com/surveys/agileMarch2006.html
http://agilealliancebeta.org/system/.../1121/file.pdf

[waterjock2000]

I'm currently leading a team who recently adopted the Scrum framework. In our experience, we've learned that you have to adopt the whole system in order for it to work. We originally tried to take the pieces we liked, but realized that you have to modify your entire process.

It's not as difficult or scary as it might sound - the advantages of agile/scrum are many fold. Having well defined / prioritized features is just one side effect of the approach. While having this one item is useful, to get the product out the door, you have to do the daily scrums in order to ensure that people don't go too far off the beaten path (easily done without daily meetings).

[Lori]

Waterjock,

How strictly do you follow? For example, do all team members stand during the daily scrum?

Have you been doing it long enough to say whether it is really making a difference in product quality?

Lori

[waterjock2000]

Too early to say... So far, it feels right. However, it does feel like we're still working out the kinks. We don't stand during the scrum (we're a distributed team, although I guess we could stand with our headsets on...). I was actually referring more to the main components such as maintaining the product backlog item list, meeting every day (briefly - asking the 3 questions) to avoid divergence, etc.

[martinig]

Thanks for your feedback on this point. I had a discussion in December with the manager of a team that was trying to adopt Scrum. He says that the team was very enthusiastic with the approach. His main issue was how to get the customer involved to define each iteration. How is this on your side?

[waterjock2000]

Our customers are internal at this point. We're re-writing our product, so we have an internal product board which is involved with the process. However, the process should be similar with an external customer. Some buy-in points for the customer include:
- Getting incremental functionality instead of the waterfall "all-or-nothing" approach
- They decide which features are the highest priority (therefore, which features get implemented first)
- Visibility into the process (what is done, what hasn't, etc)

It's not a silver bullet - using scrum/agile doesn't prevent feature creep, but it does help manage workload so you know when your projected hours far exceed available work hours in an iteration.

[sehlhorst]

We recently published a series of articles, listing and discussing 10 mistakes that people make when adopting agile processes . I think you'll find it spot on for this discussion.

Here's the list of the mistakes we discussed, check out the article for more details (there's a detailed article on each mistake, available after the jump).

Go All In
Go Fast to Go Fast
Ignore the Corporate Culture
Fail to Identify the Sponsor
Fail to Define Roles Within the Agile Team
Do Not Create a Project Plan Before the First Two Iterations
Overdo the Team-Room Concept
Trash All Computer-Based Project Management and UML Tools
Choose Your Key People Poorly
Make Agile the New Religion

Would love any feedback from other folks who've recently adopted agile processes!

[waterjock2000]

I have to agree with the "Do Not Create a Project Plan Before the First Two Iterations" item. We did this and it failed miserably. Lesson learned. It takes a few turns to get a feel for how long things take.

[alachisoft]

The business and data objects are usually very good candidates for object to relational mapping and code generation. Once you've mapped your objects, have specified your database operations, queries, and stored procedure calls, you can pretty quickly generate fully working objects and use them in your application.

My company (Alachisoft) provides TierDeveloper, a leading O/R Mapping and code generation tool for .NET. You can learn more about it at http://www.alachisoft.com/rp.php?dest=/tdev/index.html

Cheers,

Iqbal Khan

[sondlerd]

We have implemented Agile Scrum and we do the following:

- Two to five week sprints
- Daily Scrum each morning (30 - 60 minutes)
- Close work with Product owners and BA/QA staff
- We try to deliver functionality after about 3 sprints... it turned out that delivering after a 30 day sprint was very difficult... management wanted to see more functionality in each rollout
- We usually have three sprints for rollouts, two development sprints and one QA sprint in which the developers work directly from a defect backlog comprised of all the defects from the first two sprints.
- Constant information exchange between the product owner and developer, directly and through BA/QA staff
- product backlog (not the 1.1.2 stuff) that consists of a list of requirements. They are reviewed by the development staff and given a Level Of Effort LOE and then from the LOE the Product Owner chooses which items should be fit into a sprint based upon available hours versus LOEs.
- We try to educate the product owners on Agile with Scrum so they know the playing field. One thing that is difficult is sticking to the Iron Triangle, three equal sides made up of features, resources and time.
- Pre sprint planning has been identified as very important in our organization, thankfully
- We create Burn Down charts and report burn down time during our Scrum (from the developer's point of view)
- One big must is having the right people involved.


- We don't do paired programming (extreme XP)
- we chose not to use the language and of Stories and Story Points. I am disappointed here because there is a very cool practice of writing stories on 5x8 inch note cards and putting them on a white board. On the back of the cards the BA/QA staff writes a few simple test cases and then at the end of a sprint, these are what they test to make sure that all requirements are complete and done as the BA/QA expected.