Article Review: Managing an Agile Project by Jeff Pallermo

Jeff Pallermo has an excellent article about "Managing an Agile Project" at CoDe magazine:

http://www.code-magazine.com/Article.aspx?quickid=0805041

First, About Jeff

Jeff is the founder of the MVC Contrib project at http://MVCContrib.org and he blogs here: http://codebetter.com/blogs/jeffrey.palermo/. He is also working on a book about ASP.NET MVC with a co-author who is a Ruby on Rails consultant.

He's interviewed on Polymorphic Podcast here about MVC and MVC Contrib: http://polymorphicpodcast.com/shows/mvccontrib/. (Scott Guthrie (The Gu) is interviewed in the beginning of this episode)

My favorite quote from this interview is "If you are writing new code without automated tests, you are writing instant legacy code".

My second favorite part is where he says that they use CruiseControl, NAnt and NCover for MVC Contrib and they do not accept any contributions that have less than 95% code coverage in their automated tests. NO EXCEPTIONS

Jeff leads a .NET Boot Camp for .NET Teams every six weeks: http://www.headspringsystems.com/training/. The training is in Texas and covers the following topics:

This advanced agile curriculum will cover everything involved in developing software in .NET, from setting up a new project and defining the architecture to implementing functionality in a loosely-coupled and testable manner. We will immerse ourselves in domain-driven design, test-driven development, design patterns, object-relational mapping, inversion of control (IoC), pair programming, automated builds, and continuous integration (CI). Students will discover which practices cause projects to fail and which practices help projects succeed. The course will include a strong focus on solid principles and values that can be applied to any .NET project. With a solid understanding of Agile values and object-oriented programming, students will emerge from the training with a refocused view on software development and the tools to immediately bring value back to their companies. All developers will take back working code developed during the course using the techniques and practices taught.

Comments on Article
Pallermo makes some very good points about Communication and Expectations. In my experience with iterative development, these were absolutely critical.

One project I worked on for four years in which Scrum techniques were applied was CDCs Epi-X system (http://www.cdc.gov/epix), a peer-review and emergency notification system for alerting about emergency health threats. We held weekly planning and strategy meetings in which the business side, the scientists and epidemiologists, related plans and goals for upcoming activities. On the development side, we had "stand up" meetings that were crucial for the team to understand the goals and problems for each day. After each milestone and release, we held reviews in which we cleaned up our environments, tightened our procedures, and made other improvements.

During a four year period we made about 15 releases, each bounded, each small and highly testable. That is roughly one release every three months.By breaking down the dilverables into smaller milestones, we were able to deliver new value continuously while also maintaining the mission-critical operations of the system on a day to day basis. Communication and documentation between the users, the business staff, and the technical staff was what enabled our success as a team.

On With the Highlights from the Article

Aiming for Agile

• Combine XP, Lean, and Scrum practices

The Fallacy of Fixed Scope

• Agile project management understands that scope is a moving target.
  
• The larger the scope, the more it will change.
• The software manager should foster an environment where questioning assumptions is welcome.
  
• The software team will apply a critical eye to every story on the table and evaluate whether that story will contribute to the end goal.
  
• Every story must stand up to criticism in order to prove worthy of the team's time.
  
• Working on the right thing is as important as making the thing worked on right.
  

Teams

• In an agile project, you tend to employ more generalists than specialists. With a team of generalists, you want folks who are skilled in a variety of areas.

Key Performance Indicators

• Defect-free stories delivered. Each story represents a unique behavior in the software from which the customer benefits. Stories delivered with defects aren't as valuable, so don't count those.
• Customer satisfaction. Ultimately, you are creating software for a customer. Without the customer, you wouldn't be creating the software. Keeping them happy is a great metric. It's simple. Just ask their satisfaction level on a scale from one to ten.
• Consistent velocity. Iteration over iteration, velocity should remain constant. If it continues to change, something is wrong. After about the sixth iteration, treat any significant change in velocity as a cause for alarm. If the team make-up is consistent, the velocity should remain constant. A slowing of velocity could be a sign of a codebase that is less than maintainable.

Managing the Customer

Manage the customer's expectations. Use daily "stand up" meetings to communicate the following quickly:

1. What I accomplished yesterday.
2. What I hope to accomplish today.
3. What barriers are impeding progress.

• Armed with this daily knowledge, the customer will start to feel like part of the team instead of an outsider.
• If the customer isn't engaged properly, there will be an us vs. them environment, and that is dysfunctional.
• When your team is in competition with the customer, neither will win.

Bugs versus Defects

• Defects are gaps between what your team committed to and what they delivered.
• A bug is anything that bugs the user. I'm not sure we'll ever get away from bugs, but constant communication sure helps.
• A defect is a gap in the story contract and acceptance criteria.
  
• A bug is not a defect since it's an annoyance that has yet to be discussed.
• When someone finds a defect, the team should drop everything and fix the defect right away.
  
• A defect signifies that a story which the team has already labeled "done" is, in fact, not finished. Finish the story and move on.
  
• Institute a zero-defect policy.

Retrospectives
After an iteration, have the team take about 30 minutes to document the following:

1. Good (what you would like to continue).
2. Bad (what you would like to stop).
3. Ugly (a fun category if an issue was particularly messy).

All-in-all, you are in charge, so if your team starts a long discussion on how to move forward, you may have to make the call.