Monthly Archives: November 2008

Re-reading the Agile Manifesto, Part Two

In my last post, I discussed a section of the Agile Manifesto that jumped out at me when I read it recently. I thought IÂ’d add another post on the Manifesto: ItÂ’s not a long document, but every word is carefully chosen to reinforce what agile stands for, so I think it merits some scrutiny.

Another line in the “Twelve Principles of Agile Software” section that spells out how agile leads to the delivery of the “right” product is:

     Â“Business people and developers must work together daily throughout the project.”

In the past, stakeholders and developers might never actually meet. Instead, a manager would relay vision to the development team, leaving plenty of room for misunderstanding. Clearly, conveying requirements becomes a game of telephone in this situation. But in the agile paradigm, business people and developers are asked to communicate not only at the outset of a project, but at every step along the way. The manifesto suggests they actually “work together daily.” With direct and continuous feedback from business people, there’s virtually no room for the team to misinterpret customer expectations or stray from that vision. In conclusion, agile helps build products customers truly want by getting stakeholders and developers to communicate directly and frequently.

Re-reading the Agile Manifesto, Part One

Today, I took a look at the Agile Manifesto, the document signed by agile gurus such as Ken Schwaber, Jeff Sutherland, Mike Beedle, Alistair Cockburn, Kent Beck, and others at Utah’s Snowbird Ski Resort in 2001. Most folks who have worked in an agile environment know the manifesto well (if not, you should check it out: ). I’ve noticed that, the longer I use agile, the more deeply I understand the principles that inform the manifesto. For instance, a different part of the document (from the “Twelve Principles of Agile Software” section) made an impression on me today:

       Â“Welcome changing requirements, even late in development.”

That sentiment, to me, really gets at how agile is committed to building products that customers want. There’s always a premium on completing work, but this line reminds that, in agile, a project’s not really complete if it fails to meet the expectations of the customer. Even the wording in the manifesto hits me as radical. How often, when you’ve nearly wrapped a demanding project, would you “welcome” a sweeping scope change that meant your work was far from done? I’d wager the answer is “never.” But in the iterative, incremental paradigm of agile, the focus isn’t just on churning out product — it’s on producing the “right” product.