Representation of structure

Structure in the design of systems is usually represented by some form of schematic or block diagram.  Block diagrams describe logical relationships between design elements, without getting hung up on physical detail.  UML class diagrams and electronic schematics are examples of such abstract structural models of “things that are made out of things.”

Graph diagrams have one big trick for managing scale by collapsing compositional hierarchy into subdiagrams.  Most of the time, I don’t care how an integrated circuit works, I’m only interested in the inputs and outputs.  I’d rather treat it as a unified thing, even if the components on the inside of the thing are of the same type as the components I connect to the outside.

If our biggest scaling trick is reserved for object composition, then other hierarchical relationships may be described by color, symbolism, or layout.  Color can be tricky because of problems with reproduction and perception (colorblindness is common).  Symbolism works well for simple type relationships, but it’s difficult to represent taxonomy with nothing but icons.  Edge layout is the first and most expressive tool of block diagramming, but layout quickly runs into problems with scale.  Block diagrams are not the panacea of design modeling.

Large diagrams can become incomprehensible as they scale beyond a few 10′s of nodes. Most block-diagram notations allow an ad-hoc layout. Imposing rules upon the layout of the diagram can preserve comprehension and communicate additional information about structure. Resistance to orderly layout is itself useful information about structure.

There are some wonderful algorithmic graph layout tools that we can apply to help us make sense of things, but there are also a few simple manual layout tricks we can apply to finding latent structural patterns. It’s useful to know a few tricks for discovering structure when you are given a set of entities, but you don’t yet understand the relationships between them. It’s even more useful if these tricks can be applied at a whiteboard or in a spreadsheet without the need for expensive and/or complicated software tools.

Radial layouts equalize the significance of nodes and emphasize patterns between edges. They also scale up nicely.  These can be very useful for discovering relationship patterns in a system that is new to you.  You can make a pretty big circular diagram on a whiteboard with sticky notes for nodes and ink for edges.
Linear layouts are easy to draw.

They scale up decently, equalize nodes, and emphasize patterns between edges. They can optionally encode sequence along the node axis, but they don’t have to, and we’ll see why not encoding sequence is also useful.

Linear layouts are especially useful when we make a rule about the direction of the edges.

Any leftward edge that we can’t remove by reordering the nodes is a dependency cycle. Generally, you want to avoid such cycles in your design structure.  A useful consequence of such a linear layout is that it can easily be translated into a matrix of relationships between diagram nodes. The reason becomes more apparent when you orient the graph along a diagonal axis:

The graph can be represented as the matrix

Such an adjacency matrix can be referred to as a design structure matrix, or dependency structure matrix.  The tabular form of a design structure matrix makes it a useful tool for understanding the relationships of large interconnected systems.  A block diagram with 26 nodes may be simple, or it may be visually unwieldy. The equivalent DSM always has the same layout:

dsm

With our matrix form, we can apply simple row and column reordering to maximize the number of edges on one side of the diagonal.  The dependency matrix of a decoupled design can be made to have all of its edges under the diagonal.   Any edges above the diagonal that can’t be removed by row/col reordering are dependency cycles.

In a coming article, we will expand on this matrix technique to further understand and manage the structure of large systems. We may also discover something in the patterns of relationships that will help us to manage the work of building and maintaining such systems.

Comments (4)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Leanroom!

Cleanroom is a high-capability iterative development process that can be made to flow:

cleanroom

Is Cleanroom Agile?

“The technical basis for incremental development in Cleanroom is the
mathematical property of referential transparency.”

Who knows?  But we can definitely make it Lean.

Thanks to MP for the riff.


Comments (2)

Print This Post Print This Post

Email This Post Email This Post

Permalink

The Modus Cooperandi card wall, circa December 2008

cardwall

Jim, An, and Jeanine discussing a work ticket at the daily standup.

This is the card wall we’re currently using in the Modus Cooperandi office.  It’s not terribly complicated, because there are only five of us, but there are still a couple of interesting things about it.

We’re working on a number of different programs in the office.  Some of these programs have distinct workflows.  Most of them don’t, or more accurately, don’t yet.  So, we’ve split the board into two sections.

The top section is the workflow for software development.  The workflow is yet another variation on the two-tier workflow that I’ve discussed here before.  The green tickets are Minimum Marketable Features (MMFs) and they occupy the outer, slow-moving workflow with states { backlog, ready, busy, demo, verify, done }.  The yellow tickets are User Stories that are decomposed out of the green MMF tickets.  The inner User Story workflow is { ready, busy, demo, done }.  Stories should be done in a few days.  MMFs may take several weeks.  The workflow is not particularly detailed because the team is small and the work is exploratory.  The emphasis on the demo states is because most of the work is done off-site.  We’ve allowed capacity for two MMFs in process at any time, but for now we are only scheduling one.

The rhythm of pull, and the discipline of the MMF make planning a self-regulating activity.  Naturally occuring pull events occasionally trigger planning events, which trigger further pull events and so on.  Demos and process improvement are built into the workflow, so no planning contrivances are required to make these happen.  Keeping the “Minimum” in MMF isn’t always easy, so having a “Minimum Champion” around is pretty important to making this kind of self-regulation work.  Time spent thinking about real options strengthens one’s resolve in this matter.   Enforcing the MMF is still much easier than wasting a lot of time on estimating and forecasting.  And after you gather enough cycle time data, the work begins to forecast itself.

Software development is one thing we’re working on, but we also have a number of other programs which are…not software development.  For now, these are mixed work item types that don’t have well defined workflows.  Instead of assigning them to a workcell, we assign them to individuals, with a generic common-denominator workflow of { backlog, ready, busy, verify, done }.  Backlog tasks are unassigned.  Ready tasks are assigned by affinity or consensus.  At the time that a task is assigned, it is given a due date.  When busy tasks are judged complete by their owner, they are moved to the verify state, where somebody else has to agree that the task is complete.  When a task is verified, it moves to a pooled done state.  Blocked work, as always, gets a pink ticket for issue resolution and/or process improvement.

Some of these programs are content development and we expect that they will develop more regular workflows over time.  When we identify those workflows, we’ll redraw the board and move their tickets out of the personal rows and into new workcells.  Eventually, we may collapse all of the personal rows into a single “miscellaneous” row.  The miscellaneous row is worth keeping because there’s always random stuff to do that still merits tracking.  The card wall is a living system that is subject to evolution as we learn more about how to do our work.

We haven’t set hard WIP limits on the personal rows, because we’re able to manage it through peer feedback…mostly.  The emphasis on controlling WIP still allows us to plan new work and manage the backlog on demand.  We all know that if the WIP ever gets out of hand, we can restore order by setting kanban limits.  The card wall is the focus of the daily standup, where we gather around, point at the tickets, move them around, write new tickets, and make plans for how we’re going to advance the board for the day.

The lesson is that, with or without kanban, the investment in a thoughtfully designed and carefully managed visual control is already enough to obviate time boxing and the planning ceremony that goes along with it.  Go with the flow.

Comments (0)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Video: Lean Thinking for Agile Process Evolution

Merlyn Albery-Speyer invited me to speak at Extreme Programming Portland (XPDX) this month and was kind enough to put up a video of the event. Thank you to all who put on the event and made these recordings.

Part 1 (45 min): Lean Thinking in software development, Deming and quality, customer pull vs Kano model and gemba:

Part 2 (60 min): Cumulative flow diagrams, pull and kanban, kanban and Scrum, Scrumban:

Part 3 on evolutionary design, minimum marketable features, and feature crews did not make it to video (sorry, maybe next time!)

Comments (1)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Why should you care about Lean for software development?

  • You are building a large product and you want to give your customers high visibility into your progress before you deliver.
  • You operate an online service or application and you want to deliver frequent product enhancements to your users.
  • You are building to schedule and you want to deliver the maximum value in the time available with minimum risk.
  • Your product requires professional contributions from people with non-overlapping skill sets (artists, engineers, subject matter experts) who have to coordinate with each other in order to deliver anything.
  • You outsource some part of your development process.
  • You have technology suppliers.
  • You are a technology supplier.
  • Your old product requires maintenance while your new products are under development.
  • You care about time to market for new features.
  • You have a competitor.

If you don’t have any of these problems, then maybe you don’t need Lean.

Comments (1)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Close
E-mail It
Socialized through Gregarious 42