Archives for posts with tag: Product Owner

Too many conversations lately go something like this:

Me to startup leader: are you Agile?

Startup leader to me:  as Agile as our clients let us be.

Image: choreography by Ann Carlson, used with permission.  More at

When I speak to various groups on The Agile Mindset, I point out that enlightening clients about the benefits of Agile begins with conversations leading up to the initial agreement.  While it’s less important to negotiate a contract than it is to simply collaborate with the customer, language choices do tend to support certain ways of working.

I was pretty pleased with my last experience using a Scrum-friendly contract.  The client said, “Wow, this is short!”  I replied, “Yep, let’s get to work!”

As always, get legal advice from a qualified attorney when you need it.  This is not legal advice.  I offer these sample blurbs as building blocks for your consideration.


The following items shall be presented for acceptance:

  1. Project backlog – revised monthly or as needed

  2. Retrospective report with relevant recommendations for improvement – monthly or as needed


The relationship between Client  and the Consultant will be managed and sustained by [NAME OF PRODUCT OWNER], who will be responsible for articulating goals and requirements and formally “accepting” the delivery of the work agreed-upon.

Since projects benefit from regular, purposeful, bi-directional communication, meetings shall be scheduled as follows – [INSERT SCHEDULE OF CEREMONIES].  Consultant will remain available – face to face whenever possible – offering reasonable response times, and shall expect that the Client shall be similarly available and supply all information and data as needed to complete the work to mutual satisfaction.

Consultant is happy to use any tools or processes preferred by Client.  Consultant will follow an Agile framework, which is a proven way of getting things done based on principles of entrepreneurial science.  As an Agile practitioner, the Consultant will help identify strategic opportunities to increase business value for the Client, believing that:

  • People and interactions are more important than processes and tools.

  • Working product is more important than extensive documentation.

  • Close collaboration is more important than contract negotiation.

  • Responding to change is more important than following a plan.

Last four bullet points are from The Manifesto for Agile Software Development


Recently I received this note and cheerful query from a colleague who runs a B2B custom software development company.

“Good news!  I think I may have convinced a client to use Scrum methods for their next project.

However I’m not really sure how to draw up the project’s contract.  Most of my contracts have very specific tasks and use change orders every time the spec changes.  This doesn’t seem like it would work with a Scrum project.  Any recommendations?”

So I sent him the above, and added a closing line which applies across the board.  Should you ever need backup helping your clients ‘let’ you be more Agile, be in touch for a consultation!

In his book On Dialogue, physicist and theorist David Bohm famously describes thought as not an individual act but a collective stream of meaning that is shared within a culture.  He suggests we strive for “proprioception” in our thought processes, which he defines as the perception of self-aware movement.

Proprioception is the kind of sixth sense that enables a bike rider, for example, to perform the required  slew of nano-corrections that support the body’s forward motion.   Bohm proposes a corresponding set of mental processes that enable avoidance of dead-end patterns (chief among them, aggression and suppression), improving the flow of meaning and the success of a culture.

What might this have to do with the Scrum framework for project management?  One striking thing at the recent Scrum Gathering in Barcelona (see was an emphasis on the role of Product Owner in many of the sessions.   Getting that particular role “right” comes across as a critical lever for many Agile companies.

For those who aren’t familiar, a Product Owner is someone who works closely with a development team representing the needs and interests of the customer.  The Product Owner is chiefly responsible for articulating the project’s goals and acceptance criteria,  providing feedback and approving finished work at the end of each sprint.

According to the internal logic of Scrum, then, a Product Owner is engaged in a Bohm-like dialogue  with the team.  The degree of consciousness and subtlety of this dialogue can enable a kind of group proprioception, improving the quality of the team’s creative output.

With the right feedback, corrections can be achieved throughout the development process, making a product more powerful in its construction of a coherent set of meanings.  Because these meanings have been agreed-upon by the makers and those for whom a thing is being made, their realization in form is a kind of cultural success, a “win” for the culture.

This was evidently the case for Ericsson, a world leader in providing technology and services to telecommunications companies, as described by Peter Madden in his session Significance of Feedback Loops on the Journey to Agile, part of the “Engineering Wars” program track at Barcelona.  It wasn’t until they had made the Product Owner role full-time that his teams had enough customer feedback to be particularly effective in transitioning away from a waterfall approach.   For Madden, the urgent need to do so is primarily about velocity.

Because it can achieve creative proprioception by virtue of structured feedback loops, Scrum is capable of bringing thought into form – and into the marketplace – faster than traditional methods of project management.  These days, throwing work “over the wall” from one team to the next, as proscribed by the waterfall style, just can’t carry a dialogue forward fast enough.

%d bloggers like this: