Success abounds
The intertubes is home to a multitude of blog posts, videos, prezzos,case studies evangelizing the agile method for software project management. Many cite phenomenal results with agile and so-called hyper-productive teams. It all sounds too good to be true because it kind of is. What’s the catch?
Agile is simple but hard
Agile processes are deceptively simple but the underlying principles require much understanding. Take a look at scrum for a moment, a very popular gateway to agile adoption. The official scrum guide emphasizes processes but not so much agile principles. Don’t get me wrong. Scrum has not abolished agile principles but instead appears to be tailored for for shu-level agile practitioners.
Starting out is easy
As you build your product it becomes increasingly more complex (hopefully not complicated) resulting in the need for increasingly complex decision-making. Initially its very easy to follow the Scrum recipe for agility but as we progress from iteration to iteration we need to be able to respond to the changing environment.
If you’re still blindly following the scrum recipe by the book (i.e. the process) 20 iterations on you’re in big trouble. You need an understanding of the underlying principles. You need to progress from shu-level. Fast.
Be agile about your agile adoption
If you’ve adopted agile for a particular project realize that you now have two projects. The software you’re developing and your team or organization’s state of agile adoption.
Retrospectives are crucial
Always have a retrospective meeting at the end of an iteration. In fact make it a rule that an iteration is incomplete without such a meeting. Not only is the retrospective a reflection on the latest iteration but its also function as an inspection point for the state of your team’s agile adoption. Ask yourself is agile working for you or are you working for it? Every retrospective should identify at least one problem. I doubt any team has ever had a perfect iteration. This is an opportunity for self-reflection, correction, inspection, adaptation blah blah.
How to tell if you’re failing
Things might be going well for your agile/xp/scrum team. Don’t be deceived. Just like a code smell is an indicator of a larger problem in a codebase so can seemingly small issues be a manifestation of greater ones. See Mike Cohn’s excellent pdf on how to fail with agile.
Prevention better than cure
Before you get all excited about the wonder cure to waterfall madness ask yourself:
- Is an agile methodology a good fit for your software development team? Or the bigger question: Is agile the right thing to do for your business?
- Are you sufficiently fed up with waterfall to try something radically different?
- How susceptible is your team/organization to change (managers, developers, testers, everyone!) ?
Stick it through
If your agile implementation is hurting more than delivering the expected result i advise:
- Call in an agile expert to coach your agile implementation
- Seek to get the most out of retrospective meetings. this means looking deeply at the root causes not just the manifestation of the problem(s)
- Talk to other agile practitioners (preferably “ri” level). You’re not alone
- Seek to understand the principles behind the rules and don’t give up until you do!
Disclaimer: I’m no agile expert. At best I may rate myself at “Ha” level. So if u find an odd statement or two in this post please send me some feedback. I would hate to mislead a “shu” 
