Monthly Archives: September 2014

Products and services, again

Physical products play a curious role in the context of service design, marketing and delivery. There seems to be surprisingly little thorough discussion about this topic.

Tom Graves has written a brilliant post titled From Product To Service, which significantly adds to the discussion.

I’ve been rambling about this topic here and here.

Coordinate – collaborate – conclude

In their book Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise, Scott W. Ambler and Mark Lines write about The Agile 3C Rhythm (chapter 1):
“Over the years we’ve noticed a distinct rhythm, or cadence, at different levels of the agile process. We call this the agile 3C rhythm for coordinate, collaborate, and conclude. This is similar conceptually to Deming’s Plan, Do, Check, Act (PDCA) cycle, were coordinate maps to plan, collaborate maps to do, and conclude maps to check and act.”
While I prefer the Plan – Do – Study – Adjust variant of Deming’s cycle, I definitely agree with the fundamental assessment. This rhythm also maps nicely to the Plan – Brief – Execute – Debrief cycle, i.e. the Flawless Execution Engine described by James D. Murphy in his book Courage to Execute: What Elite U.S. Military Units Can Teach Business About Leadership and Team Performance. Here, coordinate maps to plan and brief, collaborate to execute, and conclude (mostly) to debrief.
Ambler and Lines continue:
“The agile 3C rhythm occurs at three levels in the DAD framework:
1. Release. The three phases of the delivery lifecycle—Inception, Construction, Transition—map directly to coordinate, collaborate and conclude, respectively.”
From a client’s perspective, these three phases seem more relevant to me than the four-phases model proposed by the older Unified Process: the Elaboration phase proposed by UP seems much more relevant to the service provider (i.e. the software development organisation) than the solution’s customer.
2. Iteration. DAD construction iterations begin with an iteration planning workshop (coordinate), doing the implementation work (collaborate), and then wrapping up the iteration with a demo and retrospective (conclude).”
There’s not much to add to this description. When releasing a working solution into production every iteration, the release and iteration cadence described here overlay each other.
3. Day. A typical day begins with a short coordination meeting, is followed by the team collaborating to do their work, and concludes with a working build (hopefully) at the end of the day.”
We expect working builds many times a day, but a nightly build (or better, the last continuous build of the day) is a worthwhile thing to have.
Now this description of a fractal rhythm isn’t rocket science, but it resonates nicely with my own experiences: I have this pattern.
PS:  Reading Disciplined Agile Delivery was worthwhile to me. It describes a framework that many organisations try to build at home. It focuses on generic terms, which might allow us all to collaborate a little better. I like the fact that it is open to different development methods, providing explicit lifecycles for Scrum and Lean/Kanban environments.

Cross-functional product management teams

Over the years, we have achieved some success with the cross-functional software delivery teams established (well, popularised) by lean and agile methods. More recently, the perspective has broadened somewhat to delivering usable solutions rather than working software.

I think it’s time to broaden the perspective a little more and to think of software-supported solutions in terms of products more consistently and to manage them accordingly. Kristofer Layon’s book Digital Product Management is a good start.

My experience mostly comes from fairly sizeable digital business initiatives in fairly sizeable organisations. While your mileage may vary with the size of the initiatives and the (network of) organisations you are involved, I believe that the basic argument put forward in this most still holds true in a smaller context.

Years ago I’ve seen projects succeed whose leadership included a competent functional architect and a competent technical architect. This duality was de-emphasised by the Unified Process with its strong focus on the (fairly technical) software architect role and by Scrum with its focus on the (fairly functional) product owner role. To make things worse, providing the “content leadership” (a better term, anyone?) on any sizeable initiative is a tall order for any single person, at least in my experience. Disciplined Agile Delivery begins to address this issue be re-emphasising this duality with its product owner and architecture roles.

To me, this looks like a good start but I think we ought to go a step further: I suggest that introducing cross-functional product management teams is likely to yield similar benefits in the area of “content leadership” as introducing cross-functional solution delivery teams did in the area of producing software-supported solutions.

For example, in addition to business and technology design expertise, we certainly want to include experience design expertise in the product management team in most contexts. Other expertise can be added as and when necessary.

In addition to the immediate benefits of the cross-functional approach, this will also help to reduce the load on the two people that used to be “the architect” or “the product owner”.

In the type of contexts that I tend to work in, this leaves a digital business initiative with three major groups: project management, product management (in a staff position to project management) and the delivery team(s).

The concerns addressed by these groups can be delineated quite nicely, which offers the benefits of clear focus for each of them. In combination with a shared purpose, these clearly defined responsibilities provide a strong basis for collaboration across these groups’ boundaries