#48-Implications of the Agile Manifesto, Part 3

This week I will cover part three of four in the Agile Manifesto, as preparation for my final entry in this series that will suggest how to address these implications in your organization.

Transcript

Implications of the Agile Manifesto, Part 3

Just in case you've joined us recently, I've been focusing on the four parts of the Agile Manifesto, which states:

"We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."

This week I want to take a look at point three, which is basically to acknowledge that effective collaboration with your customer is more important/valuable than trying to pin them down, or to pin yourself down to a fixed contract.

We need to start with the notion of a "customer".  Who is this?  Is it the person paying for the work?  Is it those who will use the product?  Is it the person who knows best what the system, if operating properly, should do under a given circumstance?  I submit that there are a lot of answers to this question.  In Agile Tip #25, I addressed this question by replacing the word "customer" with "stakeholder", and suggested ways you can determine who your stakeholders are for a given product or feature.  If you missed that one, it's in the backlog.

That said, how can we engender the most effective degree of collaboration, given that the stakeholders for a given product may have very different skillsets, experiences, priorities, and may use language in a way that is different from others?  If the stakeholders for a given feature include nuclear physicists, how can a development team collaborate with them clearly and effectively?

Also, if we have no firm contract (and the manifesto does not stipulate this, only that we value such a thing less) then how will we be able to show progress and track completion estimates with little or nothing to measure against?

Getting these issues addressed is not only absolutely critical, assuming our goal is to deliver real business value predictably, but is also a missing piece in many organizations.  Without proper collaboration that includes everyone with a stake in the product, and without a way to ensure and forecast progress, inevitably things will get muddled, miscommunicated, misunderstood, or just plain missed.

Also, the work that goes into this collaboration, even if effective, must be documented and preserved for inevitable maintenance when certain stakeholders may no longer be available for consultation.  Without this, you are potentially buying into a tremendous amount of waste in the future.

Next week I have one more point to address, and then afterward will write my conclusions about all of this.  For now, I simply want to point out and elevate the implications here.  Agile has been said to create chaos when you attempt to scale it past small products with limited teams, but this is only because organizations do not address some of these critical issues properly.

Stay Tuned

Agile Tip #25:
https://www.buzzsprout.com/admin/2329657/episodes/15571371-25-enumerate-your-stakeholders