Stepping It Up From Contract Negotiation To Customer Collaboration
The third value of the Agile Manifesto is Customer collaboration over contract negotiation.
This is a tough one - why on Earth would anyone want to mess with the contractual agreements, some explicit, some implicit, sometimes between multiple and diverse parties.
Let me propose an approach that is very much based on (personal, but not only...) experience.
Every time - towards the end of initiatives/projects/large releases -, that we had to go back to the contractual artifacts to review, discuss and potentially argue over provisions, scope items, other related details, there was a lot of fallout, bad blood, mistrust, etc. In general, nothing much good comes out of these situations.
Reflecting on these, I noticed two emerging patterns:
a. If the customers and end-users were happy with the deliverables - functionality, capabilities, quality, timeliness, etc. - nobody would bother to retrace our steps to the contractual details.
b. Most of the times when things worked out, it was because somehow the development folks were clear not only about what we were supposed to build and how, but also why? How would the product benefit the customers, the context in which it was used (and useful!) and equally important what they didn't care for.
Now let's lay on top of these above the fact that quite often (arguably most of the times!) at the inception of the initiative, the customer is not very clear and detailed about what they want. And even when they are clear, there is still significant work to be done to assemble options for a solution combining most of the times business processes (new or modified), policies and procedures and applications and systems to support them.
Which brings us to the one reasonable model to be successful in this context - customer collaboration!!!
The proven method we're contemplating here is close collaboration between the customer and the delivery team.
The Agile mindset aligns into this vision through this third value of the agile manifesto, through the 4th principle ("Business people and developers must work together daily throughout the project."), through core concepts like transparency and feedback loops, and through a plethora of practices supporting all of these concepts.
So my core assumption when starting on any new initiative is that as a group, we will take an early, very high level vision and (a) build up the context and common understanding around it and (b) align customers, business experts, delivery folks around that shared vision. Which means a good part of the early stages are much more about learning about the product and about the process, and less about the delivery of "large amounts" of business value. The caveat here is that these are two parallel work streams, as per the opening statement in the Agile Manifesto - "...uncovering better ways of developing software by doing it...". The best way to learn in this context is by starting to deliver product increments, working software. It is a win-win situation, where everything delivered that delights our customers is business value, and everything delivered that results in negative feedback, is a learning opportunity - "this isn't gonna work, can you please do that...!".
And before some readers will think - "but I'm not a developer working in a team at a customer site, interacting directly with the customers, so this cannot apply to me!" - let me clarify. From the start of this piece, I had in mind different "embodiments" of contracts. Here's a few examples:
a. The obvious one is the explicit and most of the time legally binding contract or SOW for consulting software delivery teams executing new or modified solutions for a customer organization.
b. The business case or project charter artifacts submitted by IT groups to Finance, PMO, other governance bodies inside large organizations to receive approval and funding to kickstart new projects/programs/initiatives.
c. Regulatory and Compliance initiatives, where the "contractual" relationships go at least 3 ways between the Regulatory Bodies, the organization required to comply to the specific rules/regulations/policies, and the delivery team.
d. Architectural artifacts used to drive Enterprise Architecture Roadmaps for systems and applications. These operate as the "contract" between delivery teams and Enterprise Architecture governing the landscape of business processes, data domains, application eco-system and infrastructure. Without constant collaboration, the enterprise architects are a category of "customers" that are quickly prone to discontent with the emerging solutions.
And of course, the concept extends in kind to all (or at least most!) product development situations.
One last aspect that needs to be covered here is the fact that this value demands and drives several critical aspects of the agilist striving for continuous improvement.
One is transparency - as a fundamental pre-requisite to real collaboration for obvious reasons. And that brings along the trust required between all the stakeholders involved.
Another is the dramatically changed (arguably evolved) perspective into commitment. In this context our commitment shifts towards the customer needs and their delight, from output towards outcome.
We will take these other core concepts at hand in subsequent posts since they require much more attention!
And as usual, I will wrap up with the invitation to comment, and hence create a more complete picture of the meaning of the third value of the manifesto that guide us on a daily basis.
This is a tough one - why on Earth would anyone want to mess with the contractual agreements, some explicit, some implicit, sometimes between multiple and diverse parties.
Let me propose an approach that is very much based on (personal, but not only...) experience.
Every time - towards the end of initiatives/projects/large releases -, that we had to go back to the contractual artifacts to review, discuss and potentially argue over provisions, scope items, other related details, there was a lot of fallout, bad blood, mistrust, etc. In general, nothing much good comes out of these situations.
Reflecting on these, I noticed two emerging patterns:
a. If the customers and end-users were happy with the deliverables - functionality, capabilities, quality, timeliness, etc. - nobody would bother to retrace our steps to the contractual details.
b. Most of the times when things worked out, it was because somehow the development folks were clear not only about what we were supposed to build and how, but also why? How would the product benefit the customers, the context in which it was used (and useful!) and equally important what they didn't care for.
Now let's lay on top of these above the fact that quite often (arguably most of the times!) at the inception of the initiative, the customer is not very clear and detailed about what they want. And even when they are clear, there is still significant work to be done to assemble options for a solution combining most of the times business processes (new or modified), policies and procedures and applications and systems to support them.
Which brings us to the one reasonable model to be successful in this context - customer collaboration!!!
The proven method we're contemplating here is close collaboration between the customer and the delivery team.
The Agile mindset aligns into this vision through this third value of the agile manifesto, through the 4th principle ("Business people and developers must work together daily throughout the project."), through core concepts like transparency and feedback loops, and through a plethora of practices supporting all of these concepts.
So my core assumption when starting on any new initiative is that as a group, we will take an early, very high level vision and (a) build up the context and common understanding around it and (b) align customers, business experts, delivery folks around that shared vision. Which means a good part of the early stages are much more about learning about the product and about the process, and less about the delivery of "large amounts" of business value. The caveat here is that these are two parallel work streams, as per the opening statement in the Agile Manifesto - "...uncovering better ways of developing software by doing it...". The best way to learn in this context is by starting to deliver product increments, working software. It is a win-win situation, where everything delivered that delights our customers is business value, and everything delivered that results in negative feedback, is a learning opportunity - "this isn't gonna work, can you please do that...!".
And before some readers will think - "but I'm not a developer working in a team at a customer site, interacting directly with the customers, so this cannot apply to me!" - let me clarify. From the start of this piece, I had in mind different "embodiments" of contracts. Here's a few examples:
a. The obvious one is the explicit and most of the time legally binding contract or SOW for consulting software delivery teams executing new or modified solutions for a customer organization.
b. The business case or project charter artifacts submitted by IT groups to Finance, PMO, other governance bodies inside large organizations to receive approval and funding to kickstart new projects/programs/initiatives.
c. Regulatory and Compliance initiatives, where the "contractual" relationships go at least 3 ways between the Regulatory Bodies, the organization required to comply to the specific rules/regulations/policies, and the delivery team.
d. Architectural artifacts used to drive Enterprise Architecture Roadmaps for systems and applications. These operate as the "contract" between delivery teams and Enterprise Architecture governing the landscape of business processes, data domains, application eco-system and infrastructure. Without constant collaboration, the enterprise architects are a category of "customers" that are quickly prone to discontent with the emerging solutions.
And of course, the concept extends in kind to all (or at least most!) product development situations.
One last aspect that needs to be covered here is the fact that this value demands and drives several critical aspects of the agilist striving for continuous improvement.
One is transparency - as a fundamental pre-requisite to real collaboration for obvious reasons. And that brings along the trust required between all the stakeholders involved.
Another is the dramatically changed (arguably evolved) perspective into commitment. In this context our commitment shifts towards the customer needs and their delight, from output towards outcome.
We will take these other core concepts at hand in subsequent posts since they require much more attention!
And as usual, I will wrap up with the invitation to comment, and hence create a more complete picture of the meaning of the third value of the manifesto that guide us on a daily basis.
Comments
Post a Comment