Karl Scotland – Using Agile to Deliver Value
Archive for December, 2011
Visualising Kanban Dimensions with TIPs
Dec 22nd
Following on from my post describing a Kanban Visualisation TIP (Token, Inscription, Placement), this post gives some examples of how to visualise the various dimensions of a Kanban Multiverse. The goal is not to define any ‘correct’ ways of visualising information, but to show that there are a variety of useful approaches and hopefully inspire further new creative approaches. As such, I have listed at least 3 techniques for each approach and tried to include some variety.
The dimensions I have used are the usual project management details, but can include the concerns of any member of a team or community. Let me know what other dimensions or data variants could be added, and what interesting techniques have you used to visualise them.
Scope
Scope represents the content of the work associated with an element.
- The size of the token can indicate the amount of work, with larger cards involving more functionality.
- An inscription can describe the scope, most commonly with a written annotation.
- A linkage can reference further details about the scope stored elsewhere.
Time
Time represents the when work starts and ends and how long it has been in progress for.
- Colour can indicate the aging of tokens, where lighter cards are newer, and older cards are darker.
- Graphics can also be used to represent aging, with a dot or other symbol, being added for each day. Different colour dots can further distinguish between what state the work is in for each day.
- A simple annotation of aging, or key dates can be written, using formatting to distinguish different information.
- Where a particular date or service-level is being targeted, an annotation can be added at key points in time, such as 50%, 90% and 100%+.
- The horizontal placement within a column can indicate time in progress, with the card moving further right each day.
People
People represent who the work is being done by (as opposed to resources!).
- Colour can identify the ownership of a token for small teams, or a primary functional or disciple group for larger teams.
- An avatar can be used as a graphic inscription to identify ownership.
- Horizontal alignment in swim-lanes can also group tokens and associate them with people or sub groups.
Cost
Cost represents the estimated effort required to complete the work.
- The size of the token can indicate the cost of work, with larger cards involving more effort.
- Colour can indicate the cost of the work, especially when using relative sizes or buckets, with larger cards representing bigger pieces of work.
- An annotation could be written on the token to indicate the estimated cost, such as a relative points, or t-shirt size.
Quality
Quality represents how well the work is being done.
- Colour can indicate whether the token represents value demand or failure demand. More failure demand indicates lower quality.
- An adornment can indicate the grading of a piece of work, where a lower grade (e.g. F) represents lower fidelity work, and a higher grade (e.g. A+) represents higher fidelity work.
- An annotation of the number of tests and/or defects can indicate the level of testing that has happened for a piece of work.
- The vertical placement of a token can indicate quality, with higher placement representing higher quality.
Priority
Priority represents how important the work is.
- Colour can indicate priority if using an enumerated scheme such as MoSCoW, where a mix of priorities is used to manage risk.
- The vertical placement of a token can indicate its priority, with high placement representing higher priority.
- Horizontal alignment in swim-lanes can also group tokens by Class of Service to indicate prioritization policies.
Status
Status represents what the progress of the work is.
- Vertical alignment in columns can indicate the current phase of a piece of work.
- The rotation of a token, such as making it portrait rather than landscape, can indicate that the status of the work has changed significantly, or that it is “done” for its current phase.
- An adornment can be used to represent key status types such as “blocked” or “done”.
Capability
Capability represents the amount of work that can be worked on at any time, managed through work in process limits.
- Where tokens are grouped through alignment in rows and columns, an adornment of the grouping can indicate the amount of work than can be taken in within the group.
- Alignment groups can also have a fixed number of “slots” which indicate the amount of work that can be taken on within the group.
- Graphical adornments such as avatars for team members can be limited and attached to tokens to indicate who is working on what.
Demand
Demand represents the amount and type work being requested. Demand could show failure and value demand types such as defects and features, classes of service, such as regular, fixed date or expedite, or investment allocations such as portfolio items.
- Colour can indicate the different types of demand for a relatively small number of possibilities.
- Shape or material can also indicate demand, and can be combined with colour to show combinations of work type, class of service and investment allocation.
- Horizontal alignment in swim-lanes can also group tokens by demand type.
Value
Value represents the benefit of completing the work
- Colour can indicate the value where a granular enumeration is being used such as High, Medium and Low.
- Size can also indicate an enumerated value, with larger tokens representing more value.
- A formatted annotation can be written to indicate the value where a more precise number is being used.
- The vertical placement of a token can indicate its value, with high placement representing higher value.
Externals: Issues, Risks, Constraints, Dependencies, Assumptions
These are all factors which are external to the represented work, but which impact it in some way. Issues represent things that might impact the progress of the work. Risks represent things that are impacting the progress of the work. Constraints represent things that limit the way in which the work can be completed. Dependencies represent things that must also be done as part of the work. Assumptions represent things that are expected to happen in order to complete the work.
- Adornments can be used to represent these external factors, with colour being used to distinguish between the different types.
- A separate token can represent each external factor, with colour being used to distinguish between the different types.
- The placement of separate tokens relative to the main work item can show the relationship of external factors, either horizontally or vertically as sub-states, or in a more free-form manner such as mind-map.
- A linkage can reference further details about the external factor stored elsewhere.
- A annotation can be written to provide more details about external factors. Formatting can help identify the different types.
Thoughts on Kanban Thinking
Dec 3rd
Some thoughts on what I have been referring to as Kanban Thinking
Why create an other brand?
I’m in the camp that believes we need to create more brands, rather than reduce everything down to “common sense” or “good practice”. To paraphrase Alistair Cockburn, every successful team should create its own branded processes to describe the context and the solution.
Why another “Kanban” brand?
By using the name Kanban, I am acknowledging the roots of my current approach in hearing David Anderson talk about Kanban at Agile2007 in Washington DC. I consider that to be as important a turning point in my career as when I first read about Extreme Programming in 1999. Further, my response to calls to provide a single, clearer definition of Kanban for software development, is to encourage more definitions of Kanban. The more definitions there are, the less dogma there will be, and the more people will have to think for themselves about what Kanban means to them.
Why the “Thinking”?
As I mentioned when I blogged about Agile Thinking at the start of the year, thinking should be a core part of what we do. Alongside Lean Thinking, A3 Thinking, Systems Thinking, Complexity Complexity Thinking and Design Thinking, I want to make this explicit. Emphasising the thinking is also intended to make it clear that action is also required to succeed. Kanban Thinking is not a silver bullet as the right action is needed for each context.
What is Kanban Thinking?
Kanban Thinking is systemic. It takes a mindset of optimising the whole system, whatever the boundaries of that system are defined to be. Part of the thinking is deciding what those boundaries are. They do not naturally exist but are created by us to help frame a context.
Kanban Thinking strives to achieve flow, deliver value and build capability.
- To achieve flow is to have smooth, regular and frequent progress of work. Kanban Thinking looks to eliminate delays rather than eliminate waste.
- To deliver value is to focus on doing the right thing in order to delight the customer (and other stakeholders). Kanban Thinking looks to maximise value rather than minimise cost.
- To build capability is to develop people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems.
Kanban Thinking involves studying, sharing, limiting, sensing and learning.
- Studying the current system helps understanding of the existing context.
- Sharing the understanding gives everyone knowledge about what is happening.
- Putting limits in place bounds the system to help stabilise it.
- Sensing how the system is performing gives an understanding of current capability.
- Learning from the systems performance allows for capability to be continually improved.
