Tag Archives: agile

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.

Going with the flow

A few weeks ago I joined an up-and-running software development (and service operations) project together with a few other people. The team had already launched the first version of the product successfully. We had heard that huge effort had been put in to achieve this success and we had a hunch that the team would likely benefit from a renewed emphasis on certain lean & agile practices. We also had a hunch that the team wouldn’t benefit from us showing up and starting to lecture from the latest Scrum book or so.

I consider us extremely lucky to work in an environment in which we are free to choose our working practices (obviously within reason). I also consider us extremely lucky to work in a great team willing to own their work — and to put themselves on the line every day trying to improve our performance while at same time having to deliver against high expectations.

Listening to the team and the people around us, and establishing a shared understanding of our goals (including trade-off priorities; hat-tip to Alistair Cockburn) and the forces acting on us seems to be the essential foundation for our learning. After that, getting out of the way seems to be the best thing us management types can do. Every so often, we can provide some support and advice, or offer some re-assurance and confirmation. But mostly, it seems to be about getting out of the way and keeping the way clear of other obstacles as best as we can (we have way to go on that one).

Our work practices seem to become more lean & agile by the day, and I think our performance is improving. This post makes reality probably sound easier than it is, but I feel things are going so much better than whenever I’ve seen project teams being instructed to “be agile”.