How To Tell If You're Doing Agile Right

Agile software development is about asking a question, taking a best guess at the answer, acting on that assumption, and then back to asking a question about what happened as a result. It's about gathering feedback and acting on it in a continuous cycle. That's it. Iterations and retrospectives are the core of any shift towards agility. They are axiomatic; everything else can be derived.

All the popular agile practices like test driven development, continuous integration, refactoring, short iterations, and daily stand-up meetings are nothing more than some of the answers a lot of people arrived at after asking some interesting questions. (Edit: That might sound like I'm discounting these practices. I'm not. I've found them all to be very useful tools.)

If the only question you're asking is "are we doing Agile right?", then you're probably not. There's no magic formula. Some practices are helpful across a wide variety of contexts, but there's no guarantee a given practice will be right for your situation.

If you're asking questions like these:

• What is our biggest problem? What is the most important question we can ask ourselves right now?
  
• What are the expectations of each stakeholder group? What are our stakeholder groups?
• What are this project's risks? Can we reduce any of them? How can we force ourselves to tackle them early? What mitigation strategies can we put in place? What can we do to help ourselves notice new risks as the project proceeds?
  
• Is this project worth undertaking? What is the expected value? Do we know the TCO of the project? Do we know the opportunity cost?
  
• Why did we miss that deadline? Did anyone realize that would happen and not say anything? Did everyone realize that would and not say anything? What was the cost of missing the deadline, and what was the cost of finding out we would miss it so late? Would we be in a better position if we faced reality sooner? How can we help ourselves do that next time?
  
• How much is employee turnover really costing us? Can we do anything to reduce this cost? Can we do anything to reduce employee turnover? Is it cost-efficient to do so?
  
• How did that bug get into production? What changes can we make to prevent similar bugs from reaching production in the future? What will the side effects of those changes be?
  
• How can we improve the way we work? What do we mean by "improve"?
  
• Are users actually using this feature? How are they using it? What do they think about it?
  
• Why are we adding this feature? What is the feature's TCO? What value will it deliver? What risks are involved with adding this feature?
  
• What have other teams with this problem done? Do any of their solutions make sense in our context? What makes us similar/different?
  
• How do you unit test a user interface? Is it worth it (for us)?
• Why are we producing document x? What is it's TCO? What is it's value? Who's the audience? Do they have any ideas about increasing the value of the document?
  
• Is this particular "best practice" or "agile" practice helping us work more effectively? Are we missing something important, or is it just not useful in our context?
• If we don't know the answer now, how can we find out quickly?

... and if you're asking them collectively, as a team, in a blame-free manner, then it's likely you're on the right track.

Of course I'm not prescribing that you ask exactly and only these questions... they're just the kind of questions that I find lead to positive changes and other interesting questions.

I'm sure you are all thinking of other questions that should be on this list. Please share them in the comments!