Design Visualization: Smoke & Mirrors (by Ruth Malan)

My friend Marc pointed me to the slides of a presentation given by Ruth Malan last year. (I also found a version with her notes here, but haven’t read through them yet.)

As usual, Ruth’s material is incredibly dense, i.e. lots of information, thoughts and insights in a small space. Don’t be fooled by her friendly and casual tone: More often than not I find myself happily trotting along with the conversation — just to go back because I realised I probably missed half of what she said. YMMV, though.

I found the thoughts on system design intent vs. system design reflection intriguing.


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


“Courage is not the absence of fear; rather it is the strength to overcome fear.”

Warfighting, United States Marine Corps

I’m about halfway through this little book. There is a lot of wisdom in there even for people like me whose profession is not war. In other words, if social interactions are your business, this book may well be worth reading.

Too many errors?

Udi Dahan wrote a very helpful and enjoyable paper in which he Clarified CQRS (command-query responsibility segregation). While explaining the benefits of CQRS he planted a somewhat disturbing thought in my mind:

We may be resorting too readily to reporting errors to our users.

In other words, we may be telling our users “There’s something wrong here. You deal with it!” too quickly, too often and too readily. In many cases, appropriate alternatives are fairly obvious and probably quite implementable.

(As a side note, many of these alleged error conditions can be traced back to the failure to plan for the concurrency of events and actions in real life (i.e. we’re not talking thread management here) as Udi pointed out. That’s something to think about in another post…)

Is calling a situation an error and reporting it to the user the easy way out? As developers, are we yielding our responsibility to achieve meaningful outcomes when processing user requests to readily? What do we fear in this context?

I resolve to question decisions to treat a situation as an error and report it to a user more thoroughly in the future. That may well take some courage.



Whole-of-system architecture

Tom Graves writes about whole-of-enterprise architecture, where the enterprise is far greater than any single organisation or even individual markets. Similarly, whole-of-enterprise architecture concerns go far beyond the technology domain.

When working at the scope of individual systems, I have realised that we can benefit from taking a similarly whole perspective: I suggest thinking in terms of whole-of-system architecture can be useful and, in my work, necessary. Software systems certainly play an important role in my work, but people play vastly more important roles. As do relationships between people, groups of people and various forms of organisations. Furthermore, we need to talk about processes and data. The list goes on an on.

Even when thinking only about the technology aspects of such whole-of-system architectures, we usually have to consider runtime (or deployment) architecture concerns, development-time concerns (form, function and structure of code) as well as the tools and processes for helping us to build, deploy and manage the technology components of the system.

Thinking about this further, we might consider a system in this broad sense to be a fractal element of a larger enterprise, and therefore, perhaps, a small enterprise in itself. Consequently, whole-of-enterprise architecture insights may well apply. If so, whole-of-system architecture can then be understood as a specific type of whole-of-enterprise architecture (i.e. one tied to the system scope).

Having gotten the above out of my system, I can now start to sort it out. Would you care to help?