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.
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: http://agilemanifesto.org/ ). 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.