Agile Management
Driving out uncertainty
Agile practice irrespective of flavour (Scrum Kanban XP …)can often be reduced to:
- Work in small batches
- Deliver often
- Build the most valuable chunk first
And it’s the “value” bit that can get us in trouble.
How do we determine which is the most valuable bit? Particularly early on in a project we need to be careful about how we prioritise. Do we just get a bunch of business folk to fight for their favourite features or do we have some hard won lessons to apply from many years of technology project management?
more »
What I learnt from Tom Gilb
Last week I had the opportunity to spend a day with Tob Gilb, this was my first introduction to his methods for establishing project goals.
I have spent plenty of time this year working with clients who required help in initiating new projects and each time I have emphasised the importance of establishing the drivers for the project in order to provide direction and purpose. Even knowing how important this process is it surprised me the degree to which Tom wishes to emphasise the value being derived from a project and more specifically the metric for it’s measurement.
more »
Reviewing a project initiation
I was recently asked to help a client kick-off development of a new product. This was to be their first “agile” project so the kick-off had to set the scene for the collaborative development approach that was to follow.
I used a variety of tools and techniques to bring the project to life. As is usually the case, some worked better than others so I thought I’d review the approach and describe some of the issues and possible reasons.
The agenda for the day was:
- Review project vision and goals
- Establish key priorities and concerns
- Establish candidate releasable chunks
- Decide what to do first
Attendees included the development team, development management and business sponsors.
Theory of constraints for beginners
Take-away #3 from David Anderson’s Kanban Coaching workshop.
A discussion of Kanban can only go on for so long before the subject of the Theory of Constraints comes up. In this post I’ll try to explain just enough to show this connection.
Theory of Constraints (TOC) is a large subject that I was first introduced to some time ago by Pascal Van Cauwenberghe and his explanation of the 5 focusing steps for process improvement. Since then I’ve seen TOC pop up at a few Agile conferences. The most notable aspects that tend to be discussed are the 5 focusing steps mentioned earlier and the TOC thinking tools. The Thinking tools offer techniques for root cause analysis, problems solving, conflict resolution and planning. While there have been a number of books explaining these techniques the source material is a set of novels written by Eliyahu Goldratt the first being The Goal: A Process of Ongoing Improvement
David’s first book (Agile Management for Software Engineering
At this stage I should say that where David has applied TOC he has subsequently realised that a Kanban approach would have led to an equivalent result and is a conceptually more simple approach.
The areas of TOC that David chose to focus on were the classification of bottlenecks and the application of Goldratt’s 5 focusing steps. more »
Lean decision making
Take-away #2 from David Anderson’s Kanban Coaching workshop.
This post will be short and sweet. It’s not a revelation but it is a simple pattern that can support us in making the right decisions as we evolve and improve development processes.
Value trumps Flow
Flow trumps Waste reduction
Eliminate waste to improve efficiency
This mantra might be deceptively simple. We need to consider each aspect in turn.
Value
In a Lean sense value is in the eyes of the consumer. Activities can be classified as value adding and non-value adding. Classifying activities isn’t always as simple as it sounds; development = value adding, fixing defects = non-value adding but what about testing? If you’re not sure then answer this, would you do more of it if you could? Remember, not every non-value adding activity can be eradicated in the short term.
Flow
In this context flow refers to the uninterrupted adding of value from concept through to realisation. When presented with a need we should seek to fulfil it in a continuous chain of activities with minimal time in queues and minimal delay.
Waste
There have been a number of attempts to define waste in software development through comparison with manufacturing industries. In the Kanban class David chose to classify wastes as transaction & co-ordination costs, failure load and depreciation of assets. I believe that this could form a useful framework assuming that we accept a certain amount of waste as necessary.
For example daily stand-up meetings are certainly not value adding and fall under the category of coordination costs, however, they are a necessity in the contexts of many teams. Perhaps more on waste in another post.
So, to reiterate, value will trump flow where we choose to disrupt flow in order to meet an opportunity. An example of this would be a new requirement that must be expedited in order to minimise the cost of delay. An expedited request will cause delay in all of the other in-flight requests.
Next we choose to trump waste reduction with flow. This is most visible where we introduce buffers to ensure maximum utilisation of a bottleneck activity. Recall that the theory of constraints teaches us that the throughput of the bottleneck determines the throughput of the entire system. Where flow is somewhat ragged we will introduce a buffer to ensure that work is available. Buffers can be considered wasteful, however, the benefits of the increased throughput out-way the benefits of reducing inventory. Another example might be the introduction of non-value adding activities at non bottleneck stations that, while wasteful in them selves, might serve to improve flow through the bottleneck.
Finally we aggressively eliminate waste from the system in order to improve efficiency while remaining conscious of two temptations:
- to use economies of scale to hide transaction costs
- drift into ‘analysis paralysis’ for fear of failure load
Technorati Tags: Kanban, Kanban Coaching
Why Kanban
Take-away #1 from David Anderson’s Kanban Coaching workshop.
Kanban (as applied to software development) has created something of a buzz over the past few years growing out of a couple of case studies of David’s along with the experiences of the likes of Arlo Balshee now we have many more experiences from a variety of contexts.
Given this it was interesting to reflect on why a Kanban approach might be right for a team or organisation looking to adopt an agile way of working.
David highlighted a number of reasons why Kanban might be the right approach including:
- Optimising an existing process is easier and more effective than trying to introduce a new one
- Provide what execs want
- Achieving high maturity
The first of these points challenges the approach that many process improvement initiatives have taken in providing new job titles, new process, new document templates and more. By contrast where an organisation has an existing process, possibly with specialisations and tooling in place, a Kanban initiative would seek to model existing workflows and expose issues leaving job titles and working methods intact. This approach is likely to meet less opposition since it cut’s less to what individual contributors care about and identify with. In addition a Kanban system should generate metrics that inform further improvements, for example to working practices. With luck, by this point sufficient buy in will have been achieved to minimise objections.
The second point cuts to one of David’s mantra’s. Exec’s, he asserts, all want the following:
- Predictability
- Business Agility
- Good governance
In addition David likes to emphasise
- Empowerment without loss of control
- Self organisation without fear
Two aspects of David’s approach to applying Kanban appear to contribute a great deal to keeping these promises. The first is an emphasis on metrics. Particularly where an electronic tool is employed a Kanban system can inform a wide variety of management decisions. This is often missing where agile teams rely on a more emotional output from retrospectives. The second aspect is the exposing of policies. Many classes of issues that constrain the performance of development teams can be described as policies. Once de-personalised these can be considered with respect to the risk that they serve to mitigate and the benefit they bring as contrasted to the over-head.
And finally we come to the maturity argument. A high maturity organisation will be able to; make statistically defensible decisions, implement causal analysis and resolution and effectively deploy process improvements.
While a Kanban system will provide a rich set of metrics and enables the application of a great deal of knowledge accrued in the management of pull systems, it’s great strength (from my perspective) is process improvement. A Kanban system will make any mismatch in capacity between specialists visibile. The board can be annotated with information regarding blocking issues. But, best of all, where a blockage occurs the Kanban system will release resources to deal with the constraint.
Given this focus it seems likely that a Kanban approach may appeal to a class of organisation who see little appeal in more developer centric approaches. Kanban offers a tool set for the management of knowledge work. However, while Scrum and XP expose trust and respect as key principles these remain a choice for the manager applying Kanban.
Kanban Coaching Workshop
OK, I’m a little slow on the uptake here since “real work” is proving to be something of a distraction.
Last month I was fortunate enough to attend David Anderson’s Kanban Coaching Workshop. Here is how David described it:
This 3 day workshop is for experienced Agile coaches, existing Kanban practitioners, and those who have previously taken David J. Anderson’s Kanban class. This workshop is intended to be an interactive collaborative session designed to facilitate knowledge sharing and learning. The class will be divided into approximately 10 sections with a slide presentation or tutorial from David to introduce each section. The goal is to enable participants to go back into the field and successfully coach Agile/Lean transitions using the Kanban approach. Each participant will received a personal recommendation from David J. Anderson as a result of participating in the class.
The three days were run in a very interactive style with 8 delegates including myself. Since all of the delegates were either Kanban practitioners or practicing agile coaches the discussion was both lively and in depth.
Subject matter covered a wide range including:
- Motivations for introducing Kanban
- Getting started with Kanban
- Comparing Agile and Lean decision making
- David’s “recipe for success”
- Reviewing David’s Microsoft XIT case study
Rachel Davies has already blogged some of her isights from the workshop here and I plan to add a few of my own key take-aways over the next few posts, these will be grouped under the Kanban Coaching tag.
Three questions about leaders
Clipped from an article entitled – Are Leaders Born or Made?
I had three questions.
1. What do good leaders achieve?
2. What do good leaders do?
3. How do they do it?Read more at www.vanguardscotland.co.uk
