Feedback on a Kanban Board for Solution Architectects

Question

Before I get started I need to issue a pre-emptive apology:

It is very likely that some of the terminology / vocabulary I use in this post is plain wrong there is also a good chance I have entirely misinterpreted some of the keys aspects. I am new to this so don't be too critical, more than welcome constructive feedback ;)

Background

We are currently transitioning a development department of 200 people from multi-methodology into "Agile". The whys, wherefores, pros and cons of this are well beyond the scope of this question.

This development department contains an Architecture Service team that is made up of 10 people that are officially known as "Solution Architects". In reality they cover more than just the solution, these are technical people that cover every technical architectural aspect of a project (i.e. hardware, software, security, governance etc). They also provide ad-hoc functions to the development team (code reviews, standards guidance etc) and wider business (technical input into tenders, pre contract technical preview of customer requirements)

As part of this transition I have been tasked with creating a Kanban board for the purposes of getting a view of the work activities that the Architecture Service team are accountable for. There are a myriad example boards for development / coding teams, but none that I can find for Architecture. So I have taken from various sources and created "something", I would really appreciate genuine feedback on it.

It is also worth noting that this will be presented to the team as a starting point / work in progress. It is their board and I want them to own it, all I am doing is setting a foundation for the guys to build on (and change if necessary)

So far I have something like this

The Main Board

The main board is where we hold all active / backlog projects - all active work will be on this board. This will be short reviewed in the daily architectural scrum with a more in-depth review at the end of every week.

           ------------------------------------------------------------------------
           | Evaluation            | Implementation       | Ad- Hoc               |
           | Todo  | Doing  | Done | Todo  | Doing | Done | Todo  | Doing  | Done |
    -------------------------------------------------------------------------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    -------------------------------------------------------------------------------

The column descriptions / purposes are:

Evaluation: Projects where the person is doing an initial technical analysis, i.e. running through technical options with a product owner, determining the size of the project. As an example an Evaluation project may be the Architect evaluating a new technology or working with a customer to produce a mutually agreed technical solution.

Implementation: Projects that are actively in development (coding, testing etc) and the person is acting in an SA function for the wider project team. As an example this could be the development of coding aspects of the "mutually agreed technical solution" mentioned above, equally it could also be architecturally overseeing the implementation of some new hardware.

Ad-Hoc: All the weird and wonderful stuff that comes up that can't be put into the other two columns. As an example in a strange recursive world there is a card for me in the ad-hoc column to create a KanBan board :).

Person: Fairly self explanatory, the person who "owns" the cards in that row. To make things a little more fun this actually contains an avatar of that persons choice.

Todo: Is effectively our backlog, the cards in here are ordered top to bottom in priority. As space in a persons doing cell becomes available we take from the top of todo.

Doing: Fairly self explanatory

Done: Items that have been completed since the last full board review (Friday afternoon every week)

WIP Limits

Rather than do what we do now (i.e. give out work until somebody squeals), I would like the main board to work with objective / evidence based WIP limits. The intention is to size each of the board cards with:

• XS (Extra Small) : 3 points
• S (Small) : 5 points
• M (Medium) : 8 points
• L (Large) : 13 points
• XL (Extra Large) : 21 points

The size is very much from an Architects workload perspective, for example a project that requires 1 year of coding for 10 people but minimal Architectural input would be XS or S. However a project that has massive Architectural input but minimal coding could be an XL.

Over time we should be able to work out the WIP limit for each person. So we know that Jonny Smith can work with a velocity of 42 points and therefore allocate projects up to that level.

As we have not done this before my intention is to set the initial limit high, the idea being that when a person squeals we can (as a team) look at this objectively and determine if it is genuinely too much or is it because our processes etc are too onerous and should be streamlined.

• NOTE: Of everything here these WIP calculations are the bit that "feel" the least right*

The Funnel Board

In order to keep track of all the random things that fly through the team we also have a funnel board. This is a relatively simple board that looks like this:

    ------------------------------------------------------------------------
    | Evaluation            | Implementation       | Ad- Hoc               |
    ------------------------------------------------------------------------
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    ------------------------------------------------------------------------

As the team is made aware of a "project" but this is not yet officially sanctioned (i.e. can be put into the Todo columns on the Main Board) then it goes onto the funnel board. Items here are not allocated to a person. The idea being that we can track those random things that come through and ensure they are not forgotten. Also, as the person completes an evaluation project this then moves from Main Board Evaluation Done to the Implementation funnel board (unless it immediately becomes an implementation project)

A member of the team will occasionally be tasked with following up everything on the funnel board, i.e. quick phone call to the product owner asking if this is still relevant (this would be an ad-hoc project on the main board)

The Successes Board

This is just a simple board to track what we have done over the last X months. It holds the cards that have been through the Funnel and / or Main boards

    ------------------------------------------------------------------------
    | Successes                                                            |
    ------------------------------------------------------------------------
    |                                                                      |
    |                                                                      |
    |                                                                      |
    |                                                                      |
    |                                                                      |
    ------------------------------------------------------------------------

The idea being that we can occasionally get around this board and give each other mutual pats on the back :)

Board Cards

The cards that are on the boards contain the following information:

    ------------------------------------------------------------------------
    | SIZE (XS,S,M,L,XL)          | OWNING TEAM MEMBER             |  RAG  | 
    ------------------------------------------------------------------------
    |                                                                      |
    |                         PROJECT TITLE                                |
    |                                                                      |
    ------------------------------------------------------------------------
    |                                  |                                   |
    |        DEPENDENTS                |          DEPENDENCIES             |
    |                                  |                                   |
    ------------------------------------------------------------------------
    |                                                                      |
    |                         MISC INFORMATION                             |
    |                                                                      |
    ------------------------------------------------------------------------
    |                WIDER PROJECT TEAM (AS APPLICABLE)                    |
    | Other Architects, Project Manager, Principal Developer, Business     |
    | Analyst, Scrum Master                                                |
    ------------------------------------------------------------------------

As you will notice the granularity of the card is at a fairly high "Project" level, I am not planning on doing a developer style board that is split into tasks (thoughts on this welcome). Also worth mentioning that depending on where the card is not all sections will be applicable. I am also planning on colour coding the cards, as a first stab I have:

Yellow : Anything that is customer contractual Pink : Anything that is internal (i.e. not end user facing) Green : Anything that is a company group project

The cards will be magnetic rather than post-it, I am hoping to find some that are like mini white boards as this will make life easier as things change

Other Stuff

• If its not on a card on a board then as far as the team is concerned it doesn't exist
• The boards themselves are Whiteboards with Wheels, we can take them wherever we want
• We may consider going to a virtual whiteboard in the future (physical whiteboards are easier to change when we decide that the X column is best on the left of Y not the right)

Questions

1. After reading my newbie Kanban War and Peace what are your thoughts? (please go easy on me :))

Answer 1

Wow! That took some time to fully digest and understand. Congratulations on deciding to adopt Kanban for your Agile initiative. Really nice analysis and modeling so far. Thanks for sharing it here and allowing us to help and contribute to that initiative!

I have some thoughts and suggestions – hope these help!

A. First, just to get an overall “system view”, I gather the three boards you have shown are ONLY for tracking the Architects’ work, not the rest of the Development Department’s work, is that correct?

B. Given the way you have described it, it would appear that each of the Funnel Board columns is essentially the “Ready” column for the corresponding sections of the Main Board.

1. Is it necessary to have the separate Funnel board? Would it not be simpler to have a single board – where you have “Funnel” or “Ready” columns for each section of the Main Board?

2. Similarly, the Successes Board can be seen as a large column to the right of the Main Board where all successfully completed work accumulates for a period of time?

3. So, depending on the number of projects in the funnel and in progress (in any of the stages) at any time, would it be simpler to manage these all in a single Board which has the following design -

Of course, it is very likely you have already evaluated this and decided it might be too big to manage in a single Board! (You could consider dropping the To-Do lanes in each section since the Funnel lane might serve that same purpose?)

C. In terms of the Main Board design, it really depends on what your overall goals are for implementing Kanban. Some questions on the board design:

1. Do you want to improve Lead/ Cycle Times for individuals (which would be easy to do in the current design) or for different types of Projects (which might be more tricky (but not too much given your color-coding)? If it were the latter, you might prefer to have the lanes defined not by people but by Project type (similar to class of service)?

2. Is it ever possible that you might have two architects working on a single project? If so, having lanes by people would make it difficult to model that, unless you had two cards for the same project against each person?

3. Is it possible that different types of Projects may have a different workflow? For example, might a customer project require greater scrutiny (validation or testing or reviews) than the others? If so, Kanban allows you to have different workflows for different types of work, which would not be possible in this design.

   If any of the above points 1-3 make sense in your situation, I would suggest that you might want to consider lanes not based on people but on some other aspect. From what you have talked about, doing it by Project Type seems to be one option – but I am sure there are other criteria possible as well.

4. Another suggestion, just for more intuitive visualization – since people associate the left-to-right flow (or right-to-left in some parts of the world) to be the direction of the flow, do you think having the Ad Hoc section to the right of the Implementation columns might be confusing? My own preference would be to have Ad Hoc projects having their own separate Swim Lane.

   So, the Main Board might look as follows –

   

5. In all of the above, you could have some “avatar stickers” to show which architect(s) was work on each project that you could stick on the Project cards. If needed, a legend on one side of the board might explain which avatar was which Architect.

6. Finally, a bigger question – you stated initially that these boards were meant to track projects that the Architects were accountable for. These projects, I presume, are part of (larger) projects that are being done by the overall Development department. How are you planning to show dependencies between those (bigger) projects and the architects’ work?

D. On the WIP Limits, based on what I have seen a number of our customers do – is not to sweat it too much initially! But as you go, it is critical to establish WIP Limits – and change them as and when needed, rather than not have WIP Limits. If you already have some data on how many projects did each Architect or the entire Architect team handled in the last several months, you could use that to define some initial WIP limits already.

If you do consider going to a virtual Kanban board in the future, some of these might be easier to manage, change and play around with – such as –

• Showing people working on cards
• Setting up and showing intra- and inter-board card dependencies
• Filtering the Board by people, project-type or other attributes
• Making changes to board and card designs, etc.

I hope this helps - at least in throwing up some ideas for you to consider.

Best,

Mahesh

Answer 2

Interesting read, and mostly makes sense.

The one immediate thing I would comment on is that a Kanban board is meant to represent a flow of work, from left to right. As I imagine that your work doesn't flow from Implementation to Ad-hoc, then this doesn't really work on your board.

A better (imo) option would be to have the horizontal lanes as Evaluation, Implementation and Ad-hoc, and then have the cards themselves contain the name(s) of the people on them. This has the advantage of allowing more than one person to work on an activity (tho maybe you don't need this).

In addition, as the other poster says, you've not considered external dependencies. It might worth having a 'Blocked' column to show work that is waiting for someone or something outside the team.

Hope this is useful