Lean and Kanban Europe 2010 – Part 1

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.Lean and Kanban Europe 2010 Logo

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.


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.

lkbe2010 Keynote Alan Shalloway

Alan Shalloway giving the keynote (Photo courtesy of @karelboekhout)

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.

Reading Up: Books Every Programmer Should Read

When discussing books on software engineering with colleagues, I got the idea of listing the best books I’ve read in the past 15 years. Because it seems useful, but also because that will allow others to tell me which ones I should have read… Let’s start with some technical books. I’ve never had much taste for books on too specific technology subjects, so there’s no ‘J2EE Internals’, or ‘Jini Programming for Dummies’ books here. Not that I never read anything like that, but those were never books that really influenced how I do my job. Looking at this list it seems that I’m not very imaginative, since most of these are very well known classics. Still:

Applying UML and Patterns Cover Image Larman’s book (though in the first edition, I haven’t read the third edition I’m linking to here) was the book that first really explained Object Orientation to me. I had had courses in OO before that, but I’m pretty sure I didn’t actually understand it before reading this book.

It was also a nice introduction to UML, which I went all meta-meta-model-overboard on for a while before calming down and focusing on code.

There are other books on UML (UML Distilled is a good one), others on Design Patterns (see below), but if you want to learn Object Oriented Design, and get a good introduction to iterative development, UML and Patterns, then this is the book to get.

Design Patterns Cover Image I think everyone (who is remotely interested in OO) has at least heard about this book by the ‘Gang of Four’. The first approximately 65 pages of the book are a discussion on what patterns are, why they are useful, and how they are sturctured. The rest of the book is a catalogue of patterns.

Reading the patters will give (gave me, at least) a constant ‘Aha-erlebniss’, ranging from ‘So that’s why they did that!’, to ‘So that’s the thing I was doing in that project called!’ to (most often:-) ‘Damn! That’s what I should have used there-and-there!’.

Very much recommended for its obvious and continuing relevancy to anyone writing code. I’ve noticed recently that I’ve been forgetting which pattern was which (not enough coding…), so I suppose it’s time to do a little refresher here.

This one has in my mind always been the companion book the the Design Patterns book. It is structured in a similar way, with a part explaining what refactoring is (‘Improving the design of existing code’, as the subtitle proclaims), and then contains a long list of ‘Refactorings’, which are structured in the same way as in the Patterns book: How to apply in Which situations. This book also introduced the concept of ‘code smells’: those places in the code where you know something is wrong, even in the cases where you don’t know what it is that’s wrong. Again very much recommended. The various descriptions of what is wrong why, and how to fix it, are a great learning experience.

Kent Beck, of eXtreme Programming and JUnit fame, goes into deep detail of the TDD XP practice, by showing step-by-step implementations using TDD. He also explains why TDD works so well, that it is not just a way to increase your test-coverage, how it drastically improves design, and how to use it to write your own unit-test framework.

For some nice links to TDD articles and to Becks (and others) screencasts, see my earlier post. If you haven’t tried TDD yourself, give it a try. The results are surprising…

Clean code cover image

I haven’t actually read this one yet, but based on reviews, and on the fragments that I did read, it’s another must-read. Which is why it is on my nightstand in the ‘to read’ queue… The ‘Refactoring’ book teaches you a lot of things about improving code, but this one gives often more basic advice on keeping your code clean, readable, understandable en easy to change.

More when I’ve finished reading this one…

One other book that I’m aiming to add to my queue is Michael Feather’s Working Effectively With Legacy Code, which builds on the Refactoring concept, but grounds it in the ugly reality of dealing with legacy systems (defined as code that is not under test). After reading the original article, and recognising the situations he’s talking about, I’m convinced this is a good one to add.

Same is true for the Pragmatic Programmer book. I did read Andy Hunt’s Pragmatic Thinking and Learning book, and thoroughly enjoyed that, so I expect I’ll be reading this one in the coming months as well.

Next time, books related to Lean and Agile development, which have been my main reading material for the past year…

Why Scrum Developers Should Get Paid More!

Peter Stevens has a nice write-up on the differences in responsibilities between Scum projects, and traditional project. As can be expected, responsibilities are distributed broader in an Agile team, with much (or all) of the responsibilities of a project manager being spread over the Product Owner, Scrum Master and the development team.

Especially interesting is that they found some responsibilities not being clearly defined in a traditional team (ROI, process improvement), while it was there in Scrum. I’m not sure whether that’s quite fair, since tracking ROI is only rarely actually done in Scrum projects, but the responsibility is explicitly there.

Scrum Breakfast: Responsibilities in Scrum, or Why Scrum Developers Should Get Paid More!.

Wave goodbye!

The retirement of Google Wave is pretty big news. There’s a lot of discussion on how Google failed. Failed because they misjudged the acceptance, failed because they overhyped, and failed because they waited too long before finding out whether users would actually like it. And all those things did happen, and some of them were probably mistakes.

But the main thing that I get out of this, to be honest, is quite a bit of respect for Google in how they handled this. They had an idea, followed up on it, saw a possibility of creating a product out of it, experimented, poured resources into it, tried it out in the wild, publicly supported it… And when the time came, they admitted it wasn’t working out as hoped for, and in a timely manner pulled the plug. Writing the whole thing off as something that generated some useful technology, and hopefully some valuable insight in end-user wishes.

This is how you innovate. You take risks. You try new ideas. You get feedback from your (potential) users. You fail.

And if you don’t fail enough, you’re not trying hard enough.

For a company of Google’s size, failure is necessary on a larger scale.

Now if you’ll excuse me, I have some failing to do…

Update: I just love it when people back me up: Eric Schmidt said: ”We celebrate our failures. This is a company where it is absolutely OK to try something that is very hard, have it not be successful, take the learning and apply it to something new.”

The Role of the Manager in Scrum

Pete Deemer has written an article on InfoQ, Manager 2.0: The Role of the Manager in Scrum which disucusses the role of the manager in an Agile organisation.

The situation sketches that he gives are all too familiar, and anyone working on a transition to Scrum (or any other Agile practice) would be well advised to read this article.

The quote that rang the most bells for me was:

“If there exists a fundamental belief in the effectiveness of the “command and control” approach within the management and executive ranks, and a heavy dependence on intimidation, threats, or punishment (such as shaming or humiliation) as a management tool, it is going to be particularly difficult to make the transition to a new way of thinking. As a result, an adoption of Scrum risks being incomplete and dysfunctional, producing little if any improvement for the organization.”

The warning not to have (ex-) managers as Scrum Master is another important lesson, though. The habit of following orders is just so very hard to break.

EA Survey: talk the talk!

Scott Ambler is in the habit of doing some very interesting surveys. One that caught my attention this morning was on Enterprise Architecture.

The interesting part is the tables on success and failure factors. The highest rated success factors are about involvement and communication with both business, management and the development teams.

The highest rated ‘reasons for cancelling enterprise architecture programs’ are getting insufficient time, not being able to prove any benefit, and rejection of the EA work (and sometimes the EA) by the development team. Again, all factors of involvement and communication.

So there you have it: If you want to get some architectural improvements off the ground, the important thing is that you need to talk about it. Sell it to the business, by providing them with convincing arguments on how this change will benefit them. Talk to the development teams, and get them involved. Not just in execution of the idea, but in improving the concept and generating alternatives. You can’t know everything, and even if you did, you’ll get more done if the teams are involved in defining the needed changes.

Product Owners and business value

In Agility, Or A Pig On Roller Skates? Ken Schwaber comments on the role of product management / ‘the customer’ in Agile projects: The backlog is the result of actual work managing a product, and should be used to increase agility (ie. flexibility in getting higher value items out first), not just to adapt to a different development process.

Usually, the introduction of Scrum is initiated by the development organisation. Whether it is completely bottom-up, initiated by the developers to get more grip on their process, or more top-down by development managers interested in increasing productivity and work satisfaction, the initiative is mostly from development. This is both odd, and something of a problem: The main focus for Agile is to get the most value for the customer as soon as possible. This should be of huge interest to the customer, usually product management. But it often isn’t. Perhaps because the principles are not very well understood, or perhaps because any project manager has now been trained in distrusting development teams and their management because what is asked for is usually not delivered.

Years of waterfall, with very high penalties for changing or adding requirements after a project has started development, have conditioned product managers everywhere to create requirements documents in which every possible little thing that might ever be wanted is listed. And of course everything in those documents is Must-have, or at the very least Should-have (MoSs grows, CoWs get eaten), otherwise you might as well not put in there at all!

Going from that requirements document towards a backlog is easy, simply make a separate user-story for each of the requirements in there. Strict priorities are a lot harder, and you notice a lot of attempts to wiggle out of having to make those choices. However, to go from that big document towards a backlog, and then doing some reality-based release planning is very hard, especially when trying to determine minimal sets of features that are actually useful for your users. Simply going through the full list (even when leaving the CoWs out in the pasture) to get to the full release ‘1.0’ is not going to give you all the advantages that you could be having from adopting Agile. Thinking in smaller feature sets, and smaller releases is needed to get to the type of flexibility that well get you the competitive edge that you are (should be) after.

TDD and Emergent Design

I’ve been reading up on Test Driven Development, starting out with Kent Beck‘s book, then finding his screencasts, first the teasers at vimeo, and later the official release through the pragmatic programmers. There’s also a nice free example available on vimeo from Bret Schuchert of ObjectMentor, of which I watched the ‘Getting started with TDD in Java using Eclipse‘ one.

The nicest introduction on TDD, and on why you should use TDD, and how it helps you create better designs, emerging from the test driven approach, has been Neal Ford‘s articles on IBM’s DeveloperWorks: Evolutionary architecture and emergent design: Test-driven design, parts 1 and 2. I can thoroughly recommend those articles to any developer interested in improving their code (and design). I’ll certainly be reading his other articles in this series.

Is Agile always effective?

Ron Jeffries has a nice new article on whether agile implies effectiveness, and vice versa. The way he describes this is that an agile approach gives more opportinity for effectiveness, but if you can’t follow the agile approach you can use non-agile measures to still reach a certain point of effectiveness.

I think this resonates with some other things I’ve been reading and thinking about. The road to creating a full working agile implementation can take quite a few turns before ending up with the type of completely self-organising team that we’re aiming for. A lot depends on the people in the team, the support in the wider organisation, and the experience with agile processes. Scott Ambler has been talking about his Agile Maturity Model which promotes that ‘you should strive to be as agile as you need to be, and that will be driven by the situation that you face’. Jeff Sutherland has been emphasizing that new teams should start with a complete and structured Scrum implementation before they start adapting it to their specific situation, to avoid team (and whole companies!) to ‘adapting’ Scrum towards their previous way of working.

All things said and done, I prefer starting with quite a strict way of applying Scrum, so that when you are changing an organisation, it has something substantial to change to. Of course, this can be interpreted as being against the first value of the Agile Manifesto: People and interaction over processes and tools. But if the process is all about enabling people and interactions, then not sticking to it will be worse than the alternative, especially if that means a return to a non-agile process. 

Adrenalin rush, it’s not just for parachutists anymore

In A Successful Manager But Never A Successful Project? Bruce Benson writes about a rather thought provoking idea: People might actually like being in firefighting mode!

The next time I’m in a situation where I’m having trouble understanding why management is not encouraging improvement, but completely focused on dealing with the craze of the day, I’m going to remember this post. And perhaps arrange some panic theater to keep everybody happy…