Agile Modeling Home Page

The Criteria for Determining Whether a Team is Agile

Scott W. Ambler Home Page
 
   Home  |  AMDD  |  Best Practices  |  Architecture  |  Requirements  |  Analysis  |  Design  |  Documentation  |  Models  |  Modeling Style  |  Contact Us  |  Mailing List  |  FAQ
Enterprise Unified Process A common challenge within the IT management right now is to understand the implications of disciplined agile software development.  A critical step to understanding agile development is to observe an actual Agile team in action and see the results for yourself.  Unfortunately there is no official criteria for determining whether or not a team is Agile, and worse yet there are many "code & fix" teams claiming to be agile.  I often run into traditional IT professionals that are confused about Agile either because they mistake code & fix approaches for Agile ones.  Worse yet they then propagate their misunderstandings to others, compounding the problem.   

 

At the time of this writing there is no official definition of what Agile is, and many people want to use the values and principles of the Agile Manifesto as the definition.  Although I respect this opinion, and wish it were that simple, my observation is that the values and principles are too vague for determining whether or not a project team is taking an agile approach.  When I "evaluate" a project team, here's what I look for:

  1. Is the team is doing developer regression testing, or better yet taking a test-driven approach to development?  Minimally developers should be testing their code, to the best of their ability, at least daily in a regression manner.  With test-driven development (TDD) you write a single test before writing just enough code to fulfill that test.  This can be done at the requirements specification level as well at the design level.  I will ask a team to show me their test suite.  I want to see it run, but anyone on the team, and I want to see the actual source code.  I typically look for a roughly 50-50 split between testing code and production code, although 60-40, or 40-60 is also reasonable depending on the situation.  If I see an 20-80 split then I know there's a problem.  There are no hard and fast rules, of course.
  2. Are stakeholders active participants in development?  Your project stakeholders can and should actively participate in the development process.  Minimally stakeholders should be involved on a daily basis, they should provide information in a timely manner and make decisions in a timely manner.  I should be able to ask the team to introduce me to their stakeholder(s) and they should do so right there on the spot, or at least respond with something along the lines of "that would be Beverley, and she's in a meeting right now and can't meet with you until 11am."
  3. Is the team producing high-quality, working software on a regular basis?  The team should be able to show me the working software that they've built to date as well as the source code.  The code should be consistent because it will have been written to conform to a common set of guidelines and the team will refactor whenever appropriate to ensure that it remains of high quality.  If it is early in the project, say the first week or so, then I wouldn't expect to see much.  If they're at least a few weeks into the project then I would definitely expect to see some software.  If the team is several months into the project then I would also expect to see evidence of a track record of producing working software.
  4. Is the team is working in a highly collaborative, self-organizing manner within an effective governance framework? Agile teams employ the most effective communication strategies available to them, this often means that they don't write detailed specifications and throw them over the wall to each other, and they plan their own efforts instead of having a project manager do it for them.  But just because they're self-organizing doesn't mean that they're out of control doing their own thing.  They must perform their work within the context of an effective governance framework which guides and monitors their efforts.
  5. Is the team improving their process on a regular basis?  A common practice on agile project teams is to hold a retrospective at the end of each iteration to identify potential ways to improve their software process.  More importantly they act on one or more of their issues the next iteration, improving their approach throughout the project.  Really disciplined teams make the effort to track their progress over time and share their ideas with other teams.

You might find my articles Examining the Agile Manifesto and Agile System Development Lifecycle (SDLC) to be interesting introductions to agile software development.  Also, my various agile surveys provide some insight into the how Agile is being adopted within organizations.

 

My Agile Books

Agile Modeling The Object Primer 3/e Agile Database TechniquesOrder now! Refactoring Databases

 

Other Recommended Resources:

 

 

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here

 


Copyright © 2005-2009 Scott W. Ambler

This site owned by Ambysoft Inc.
Agile Data (AD)  |  Agile Unified Process (AUP)  |  Enterprise Unified Process (EUP)  |  My Writings   |  IT Surveys  

Follow Scott W. Ambler on Twitter