I was very pleased to see that the current issue of PMI's PM Network publication (May 2010, Volume 24, No.5) contains a couple of good articles on agility. In particular, Sandra Guy gets it right in her article Philosophical Makeover when she talks about agility being a fear-inducing paradigm alteration. She also goes on to discuss the fear factor in agile adoptions, shaping them to the adopting organization, as well as the need for strong executive support. Coming full circle the article concludes with the thought that armed with good basic practices and fundamentals such as PMI's own PMBOK and the Agile Manifesto, companies and individuals can learn from both ways of thinking to adopt what produces the best results for them.
For those looking to understand what the agile movement is all about, this article is a great introduction, and makes a great case that agility is more about culture, values, and mindset than any particular set of practices.
That makes it all the more unfortunate that the piece also includes the well-worn "Tip" that agile is not for every team or for every project. This clearly takes us back to the "agile is a set of practices" school of thought doesn't it?
Rising above the practices view, agility is about improving business outcomes by more directly interacting with customers to understand business needs, objectives and priorities. Agility is about engaging teams in ways that allow them to accept a shared accountability for achieving those outcomes. Agility is about taking small steps and assessing them to ensure that the work being done actually moves us close to achieving our goals. Agility is about recognizing that we do not live in a static world and that we should stop doing work as if we did. Agility is about shortened feedback loops that allow us to incorporate learning as soon as we learn it in order to improve the work we do and the way we go about doing it.
So in that vein, I have to ask. What team or project would not benefit from those things? On what project is it acceptable not to seek the best business outcome possible? What team would not benefit from validating the work it is doing actually solves the business problem they are trying to solve? What set of practices is so honed to perfection that we would not seek regular reflection and refinement?
I am puzzled by the persistence of these type of "not suitable for agile" comments. In reality is it not saying that we have discovered a new domain in which we don't yet understand what set of practices to apply in order to achieve the cultural and values based concepts that agility represents? Wouldn't we be better served by finding those practices, rather than retreating into "this project is not suitable for agility"?
| Comments |
|