Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Jump in the Water's Fine: Implementing Agile

Why it's time to join the Agile movement and bring some business discipline to software development.


advertisement
o you have decided to implement Agile at your company. You like the ability to track the teams progress using velocity charts, and the close customer communication. The ability for a software team to release software frequently (at the most every month) is attractive as well.

What is the best way to introduce this? There are many ways to implement Agile in IT, the following are experience based recommendations.

Introducing Agile to a Software Development Team



The bulk of the literature about Agile methodologies is related to software development. In fact, Agile was developed in software development teams. See "Agile, a Different Methodology" for more information on the background. For that reason, introducing Agile first to an application development team makes sense. If your team is one or 200, there is something in Agile for all sizes of teams.

If your group has no experience with Agile, use a good consulting group to do at a minimum an immersion class for the developers. This is the best way for all devs to get jump started into doing Agile.

The different methodologies include Scrum, XP, Crystal, FDD, Lean and others. The methodology with the most adoption is Scrum. We will touch on standard Scrum practices initially, and mention some newer Lean ideas used in software development as well.

Keep in mind that Agile/lean practices promote continuous improvement. Even though when the team first uses Agile practices, there will be mistakes. The beauty of using practices like breaking requests into smaller features/stories, and frequent iterations is that those mistakes will be caught early.

Continuous improvement helps to make sure that mistakes happen less frequently and waste is eliminated. For instance, three months after using Agile, the team may change their estimation method based on experience.

Starting a New Project with Agile

Once the Agile training or immersion class is done, the team is ready to begin. Start the project as soon as possible after training, to keep the training fresh in the teams minds. One core Agile concept is the self directed team. Have the team decide what practices to implement in this project. This means, the kickoff meeting is the place where the Scrum master, or team leader, leads the team to determine the following:

    * Breakdown of work (use Features or stories for instance)
    * Length of iterations (in the case of lean length of releases)
    * Team Room (recommended)
    * Testing discipline (use TDD? Recommended)
    * Preparation for Customer demo/planning meetings
    * Estimation practices (use planning poker or other)
    * Release planning
    * Definition of Done
Daily standup meetings of 15 minutes are not considered optional. In these standups, team members who are doing work (usually developers, analysts and testers), communicate to the team leader and stakeholders. This communication takes place by each team member providing the answers to the following three questions.
    * What did you do yesterday?
    * What are you working on today?
    * Are there any roadblocks?
If you have a large team (more than 10 developers, analysts etc.), then consider having only blocked team members communicate. If this restriction is not put into the standup, then this daily meeting can take a lot of time that may not be necessary.

Breakdown of Work

The breakdown of work is critical to many of the other issues mentioned. Estimation planning is dependent on what size of work the team is using. Customer planning expectations depend on what size of work items are selected as well.

Features may make more sense to customers. If your marketing person wants to let external customers know what will be included in the next release, features can be useful.

The definition of features from Feature Driven Development is as follows: "Features are granular functions expressed in client-valued terms using this naming template: <action> <result> <object>. For example, calculate the total of a sale, calculate the total quantity sold by a retail outlet for an item description. Features are granular in accordance with the rule that a feature will take no more than two weeks to complete, but not so granular as to be at the level of getters and setters. Two weeks is an upper limit; most features take less than this time. When a business activity step looks larger than two weeks, the step is broken into smaller steps that then become features."



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap