Our standard answer and presentation materials usually involves citing the text of the Agile Manifestoand either this definition by Scott Ambler and/or this comment by James Highsmith that "Ultimately, Agility is about embracing change rather than attempting to resist it, [and a] focus on talent and skills of individuals and teams."
I've noticed our responses attempt to describe what Agile Development is by describing what it looks like (Ambler's definition), or the Agile values (from the manifesto), or the emphasis on change and collaboration (Highsmith). What they don't do is describe what Agility is! The Highsmith comment comes closest, but none of them really describe what it means for something to have the ability called agility.
I think it is key to understand what Agility is, and why/how it works, in order to understand Agile software development. I think without that understanding, it can be much harder to understand and apply the principles of lean/agile development, and to "inspect and adapt" to improve the right things in the right direction.
Toward that end, I did a bit of research on a lot of different definitions of agility (beyond some of my previous blog entries like Nutshell definitions of Agile development, Agile development distilled, and Business Agility defined) and of various attributes of agility. And I plan to share them in some blog-entries for each of the following:
- Business Agility
- The Agility Cycle
- Software Agility
- Collective Intelligence
- Social Creativity
- Swarm Behavior
- Collective Ownership
- Change & Uncertainty
- Simplicity, Sufficiency and Sustainability
So "stay tuned" to this blog over the next several days because I intend to post on this more than weekly.
Agility is not the point, http://jchyip.blogspot.com/2007/05/agility-is-not-point.html
Hi Jason! Thanks for sharing your post. I think I disagree with it tho. I think agility is/was the point, because needing to accommodate frequent change was the problem. I do agree that agility is a means to an end, and not the end-goal itself.
My recollection is that back in 1997 when myself and Mike Beedle and Jim Coplien (Cope) and Robert Martin (Uncle Bob) started up the "Chicago Patterns group", it was still very much about being adaptive and responsive and self-organizing and emergent.
And it was still very much about embracing and responding to change, and flattening the cost-of-change curve, and what Mike Beedle and Jim Coplien were describing as "hyperproductive" teams.
And many of those elements of hyperproductive teams were being documented as pattern languages, and the concepts from pattern-theory of emergent behavior from dense-local interaction and self-organization (using sociometric analysis and affinity diagrams in some of Cope's patterns) definitely applied and were definitely being mentioned.
Those things were deemed the desirable means to a desirable end to allow dealing with constant change in ongoing knowledge-work and learning through feedback and adaptation.
that's really a fantastic post ! added to my favourite blogs list.. I have been reading your blog last couple of weeks and enjoy every bit. Thanks.
Post a Comment