I attended the Lean and Kanban Europe conference last week, and I thought I’d do a little write-up to share my impressions.
As an Agile Coach and Scrum Master, I was going to this conference to find what parts of Lean and Kanban (in that order) could be of use for me when helping clients improve their way of working. I was in particularly interested in ways of extending the values and principles of Agile into the non-IT parts of an organisation.
I was not disappointed! The central theme of the conference was very much about enabling organisations to provide better value and service to their customers. As is appropriate for a Lean conference, the ‘how’ of doing that was all about Systems Thinking, Flow, and Eliminating Waste. And about pushing responsibility and decision making down to the people doing the work.
The general atmosphere at the conference was very open, speakers were mingling with everyone else during the breaks, and always welcomed questions and discussions. The focus of most presentations was on explaining why certain Lean principles work, and what common problems they solve. There was also enough focus on practical implemtation examples, and during the Open Space part of the conference, there was also room for some games that illustrated things very clearly.
Agile vs. Lean?
Before I left for the conference, I ran into a thread on the yahoo scrumdevelopment list that discussed whether Lean and Kanban were Agile, or not. The discussion was quite intense, but as far as I can see there is so much more overlap between the Lean and Agile approaches that to most outsiders the two would be pretty much the same. The general ideas at the conference also seem to support this idea. Lean is seen as a way to achieve ‘organisational agility’, and can be used in combination with many existing Agile approaches. There does seem to be some strife between some members of the two communities, though, some of which did come out during David Anderson’s presentation. Apparently he wasn’t made very welcome with a talk about Kanban at an Agile conference a few years ago, and some of that discussion still gives some friction. Mostly though, the general feeling was that Agile methods don’t always succeed in triggering required change in the broader organisation.
Agile also doesn’t always give much of a handle on deciding *what* to build. It promotes customer interaction, but especially in an enterprise scenario, that doesn’t mean you’re actually building the right thing. This theme returned in a number of talks, ans very notably in the keynote by John Seddon, who impressively presented a usecase from the Portsmouth housing authorities the demonstrated systems thinking very convincingly.
Talks
I’ll give my main impressions on the talks I attended below and in follow-up posts, starting with the opening keynote by Alan Shalloway.
Maarten from AGILEMinds told me that the slides, and probably videos, of most of the talks would be put up on the conference website. That’s very nice, and also means that I won’t need to give a blow-by-blow description of the contents of each talk. I’ll just be giving the highlights and my impressions for each one.
Opening Keynote by Alan Shalloway on September 23, 09:15-10:45: What is Next in the Agile World: Why Lean/Kanban Matters
Alan Shalloway (http://www.netobjectives.com/bio-alan-shalloway, @alshalloway) opened the conference with a keynote talk that discussed the way that Lean thinking can be used to expand the tenants of Agile towards the broader organisation. He started out with a quote from Ken Schwaber where he states that only about a quarter of the teams that *say* they use Scrum are actually really doing something that can be called that (thanks to an update from Alan, I now have a reference for this: http://www.agilecollab.com/interview-with-ken-schwaber).
Below are my notes on the talk, which I thought very well performed. He certainly managed to capture my interest with lots of examples that were very recognisable. It was a good introduction to Lean and Kanban, and as such was very accessible for those of us that have not had much experience with implementing Kanban.
[
He then went on to explore some of the reasons that these initiatives don’t reach their full potential. In general he says it is because Scrum, though seen as having a fairly simple process/framework, is still too complex or difficult to do. And perhaps too disruptive if done right. He sees a number of corporate Agile anti-patterns:
- Business
- Poor Prioritisation
- Too many projects!
- Teams
- Poorly formed teams
- Teams that don’t know how to do Agile
- Ineffective release processes
- Technical Debt
- Management
- Management not helping teams
- Resistence to change
A wonderful quote on that last item:
People know what to do, but they don’t do what they know.
Which is something that I have seen many times. We know exactly how to make sure we do everything right, but seem to put that knowledge aside the moment the pressure is on. And often even when there’s no pressure at all.
He then went on to look into more detail at some of the issues that organisations have organising their technical work. I certainly hope that the slides for the first of those will become available, because I very much liked the clarity they gave on all the problems you can/will get when you arrange your teams by component/specialisations instead of by functional areas. I won’t try to reproduce them, but the message is clear, and familiar: splitting work by component will create hand-overs and delays, and should be avoided.
He also gave a nice overview of how most project organisations created a very high load on their most critical people. People with specific knowledge, experience and/or skills need to be involved in so many different projects that they get overloaded and become constraints on those projects. And thus on the organisation. Mostly this is done out of a misguided attempt to ‘optimise utilisation’, but having everyone allocated to a project 100% of their time doesn’t mean that they’ll be creating the most value for an organisation.
Busy doesn’t mean productive!
In the next bit Shalloway explained what he called ‘induced work’. He explained how, when you ask a group of programmers what they spend most of their time on, they will often say: ‘fixing bugs’. And that he then tells them they’re wrong! They’re not spending their time *fixing* bugs, they’re spending most of their time *finding* bugs. And that’s usually true, in my experience. Once you know what’s wrong, you mostly know how to fix it. And the fresher in your memory the original work is, the easier it is to find problems in it. All this is of course another way to reiterate the familiar truism that the earlier you find a problem, the cheaper it is. Fresh bugs are easier to squash! This means that any delay in the process increases work, and thus makes the process more expensive.
The message is that it’s not just about ’eliminating waste’, it’s about *preventing* waste.
In informal queries, people estimate the amount of ‘induced work’ in their companies somewhere between 30 and 70 percent. That’s a lot.
Then Shalloway went on to some of the management issues trying to do (especially large scale) scrum. The problem that even with a well designed multi-team approach, the tribal nature of people still brings unwanted competition and separation between the goald of the teams. He also commented on the common problem of management declaring ‘Thou Shalt Be Agile’, and expecting that to be sufficient…
After this description of the limitations and challenges of Agile implementations, he went on to discuss how Lean, and Kanban, provide tools to deal with these kind of issues.
The first is the fact that Kanban allows teams to start from where they are now. It doesn’t require the kind of (sometimes disruptive) changes that a Scrum of XP implementation does. Of course, many people would call that disruption a positive thing, but there are plenty of organisation which are simply not able to deal with that level of abrupt change. A Kanban implementation start by simple modelling the current process, and value stream, giving insight in where any problems lie.
Sometimes chaos is creative, but most of the time it’s just madness.
He sketched a progression of production styles, going from the original ‘Craft’, to ‘Interchangeable Parts (1800s)’, to ‘Interchangeable People - Assembly Line (1900s)’, to the new ‘Engaged, Thinking People - Lean (2000s)’.
Lean management depends on the ability to ask the right questions. It’s not a matter of changing the culture of a company. Culture can’t be changed directly. You have to change the management system.
Culture is the result of the management system
In that same way, you can’t decide to ‘change productivity’, influence ’trust’, etc. You can influence the system, and build people and those other properties can/will emerge.
The basis of Lean is the continuous process improvement. You take small steps, often, in the right direction.
Focus on a process improvement to achieve a specified improvement, not to achieve a specified $ return.
All this results in the following definition of Lean Management:
Lean Management means setting up an environment in which people can learn to do their work better.
There followed some advice on things to keep in mind when you start with implementing Kanban in your organisation, for which my notes are less extensive (wait for the video! :-), but do include the following quotes:
A Kanban board is a representation of your model, not a process to be followed.
So if you can’t draw up your Kanban board, you don’t know what you are doing!
At the end there was a nice statement on how you still have to make sure that what you are building is solid (“Load bearing walls”;). He referred to an article on his company’s website (http://netobjectives.com/), on “What a programmer should know before I’ll let him touch my code.”;. I haven’t been able to locate the correct link yet, but I’ll update this post when I do.
That’s it for now. Next time I’ll post my notes on Mary Poppendieck’s ‘What is this thing called pull’ presentation.