Skip to content

Architecture Work In Progress

January 21, 2010

The problem

I lead a group of senior solution architects who are supporting application development and maintenance activities across the GMAC Global Marketing Organization. We are spread thinly across the eastern half of the US, and responsible for assisting with and overseeing the work of roughly 20 development and maintenance teams.

The challenge we face is this: How do we track the work that is in flight, and provide a very clear high level picture of who is doing what? Especially in the rapidly changing, sometimes amorphous world of application architecture?
How do you make it easy to visualize and communicate the items your team is working on, and give everyone a common model for the work moving through

In an attempt to address these problems, we have adopted a lightweight kanban-like work tracking board, with index cards that represent discrete assignments and a simple lifecycle that tracks their flow. Kanban originated as a means of optimizing the amount of work flowing through an manufacturing assembly line, and is closely associated with Lean Manufacturing and “The Toyota Way.” Many software development teams have adapted it as a means of managing their work. (A deeper exploration of kanban, why it works, how it relates to lean and other agile practices, is WAY outside the scope of this post but something I’m really interested in. Subject for another post perhaps?)

Intentionally simpler than a project plan or “dashboard,” the kanban board gives us a single easily digestible view of what’s in flight and what’s coming up, where are resources are allocated and what the key bottlenecks and issues are.

The Cards
In a kanban development approach, each card in the system represents one or more user stories, or a feature that the team is working on. In a development lifecycle, you might have stages like Requirements Definition, Analysis, Code, UAT.

In our simpler Architecture kanban we’re using cards that represent discrete assignments or deliverables that an architect is working on. Typical cards might be “Billpay ADD,” or “Universal Customer Profile Discovery,” or “Anti-Money Laundering RFP.” Note that architects get asked to participate in many different kinds of efforts, attend lots of calls, and provide opinions on many topics. Not every Architecture request goes onto a card. A card has to represent a significant chunk of discrete work, with a concrete deliverable at the end.

Because there are many different kinds of work represented by the cards in our system, we’ve adopted an extremely simple lifecycle. There are four states that any card can be in: In Queue, In Progress, Done, and suspended.

As we mature the practice I want to add other metadata to the cards: when the work was defined, when it was begun, when it was expected to be due, and when it was actually completed. This will allow us to calculate important metrics about the process, including Cycle Time and On Time Percentages.

Finally, to really “grow up” and be a mature kanban system we would evolve WIP limits, which would be a chokepoint beyond which we couldn’t accept more work into the system. Until we are truly limiting the amount of work in the system at any given time we aren’t really leveraging the power of a kanban approach. One of the key elements of a true kanban system is that work is “pulled” into the system as architects finish other items. In our case work is still pushed into the system, and we’re still spreading ourselves thinner and thinner in an attempt to cover it.

But we need more experience understanding how much load we can manage, the ideal “card size” (eg: amount of effort per card), and the capacity of each architect on the team.

The Board

We’re using a wall in the office as the “system of record” for our work tracking. Index cards are labeled with each of the steps of the lifecycle and arranged in large columns. Other (sometimes smaller) index cards are labeled with each work item, and placed in the appropriate column. If an architect has been assigned, his/her name is also added to the card.

We cluster the cards in horizontal rows based on the assigned solution architect, although you might choose to cluster based on class of service, or type of engagement, or some other factor.

Because many of our architects (and stakeholders) are not in the same office, we also maintain a virtual kanban board in visio.

Anyone on the floor can walk by at any point and see the current state of our workload. I send out a weekly version of the virtual visio kanban board.

The lifecycle stages
In Queue
Items are In Queue when they have been identified as upcoming pieces of work but they are not yet defined or funded, or have not had an architect assigned to them. Sometimes items sit In Queue for several weeks and then move directly to Suspended because they never get off the ground.

In Progress
Items are In Progress when they are being actively worked. They can move from this state if they are completed, or if they are suspended.

Suspended, Done
The terminal states for work items are Suspended or Done. Items accumulate in these states throughout the month, and then get cleaned out (and, when we get more mature, archived) on a monthly basis.

Status reports
Each week I get status report updates from the solution architects. These should reflect the major accomplishments or issues for each item in the In Progress column assigned to that architect. I consolidate these into a group status report that goes out with the weekly WIP chart email. If we go a few weeks without any updates on an In Process item, I know to start getting skeptical about whether it is still really active.


Customers (especially BIO and senior staff) have a clear view of all that we are working on.

Each Solution Arch can easily look and see what his/her teammates are working on (so collaboration opportunities are easily identified)

We have a consistent story about what we’re working on, and keep our commitments to our customers clearly and concretely tracked in a shared model across the team.

Eventually we will start to get valuable metrics like Cycle Time, Defect Rates, and On Time Delivery Rates


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: