Agile Lab - Training, Coaching and Consultancy Blog

Thursday, 16 July 2009 at

Trying to Understand Kanban in Software

I was very interested to hear Karl Scotland's talk yesterday at Minispa2009 about Kanban. I think he's a addressing some very important issues, but as I've said on Twitter, I wasn't quite convinced by his talk. I think he's nearly there and can't quite make out whether the problems are in my understanding; his communication; or in the actual ideas themselves. Anyway, here are some notes on things that I think at the moment are an issue.

Software components aren't car parts

One of the way I try to explain stories when I'm doing agile training or consultancy is that stories are stories. A story is an out-of the ordinary situation which needs resolution. It's news. Software development spends most of it's time dealing with "Man Bites Dog" cases because "Dog Bites Man" cases are already catered for in the language libraries and the API. Software people, project managers and the people who support them with training and consultancy are all what Peter Drucker called "Knowledge workers". Ironically, that means we spend most of the time NOT knowing what we're doing. I'm not sure how well this fits with manufacturing car parts, or assembling cars.

Toyota Production System is a "That would never work for us" method

Anybody who has ever tried to advocate any kind of project management method to someone in an organisation will be familiar with the "That would never work here, that would never work for us," response. What isn't perhaps discussed so much is that exactly that attitude is the root of the Toyota Production System from which Lean and Kanban ideas are extracted.

As I understand it from my reading of Taiichi Ohno's book and from reading "The Machine that changed the world." One of the original spurs for the Toyota Production Method was an understanding that the way that Ford made cars wouldn't work in Japan. They simply couldn't make enough cars to get the economies of scale that Ford (claimed) he was getting. Another realisation was that Japan's demand for manufactured goods was extremely cyclical and so Toyota needed a method that could "smooth" out these oscillations in demand. But Ford's model of hiring and firing low-skilled workers as the need arose simply didn't fit with Japan's cultural understanding of what work was. People worked for the same firm and stayed loyal to it all their lives. Enormous value was placed in the deep knowledge and mastery of skills. Toyota decided to put together a system valued skilled workers and held onto them through all stages of the economic cycle.

This is what I don't see in Lean and Kanban approaches to software. It doesn't say "We need to design our own Toyota Production System that reflects our culture, values and economic cycles," rather it says "we need to use theirs!".

Flow vs frame. How do you know what you're capable of?

This maybe not so much an objection as a lack of understanding. I didn't quite understand what Karl meant by the term "cadence". It seemed to be something like an iteration, but of variable length. I sat up and paid very close attention at this because one of the things that you're always asked when consulting and training about Agile methods is "How long should iterations be?" And so some kind of rule - even a rule of thumb for working this out would be interesting to know about. But at the same time I'm worried that giving up on the idea of fixed-length iterations, results in the loss of information about velocity. And one of the things that I think is vitality important about Agile methods is the ability to get better and better understandings of what you're capable of as a team.

Another way of thinking of iterations is a frame that you put around the work that would be getting done anyway that allows everybody (developers, project manager, clients) to talk about it in an different way, to reflect on progress, to decided on changes of emphasis and direction.

The aim of these comments and objections isn't to dismiss Kaban/Lean approaches because I think they would be particularly well-suited to settings such as web development agencies, where the work tends to turn up in a continuous flow and doesn't necessarily fit itself into time-boxed. Iterations.

Thanks to Karl for an interesting talk.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , , , ,

Thursday, 27 March 2008 at

Agile - Keeping the Conversation Going

When I was a student of philosophy, way back in the last millennium, I was often told by my tutors that all modern academic philosophy is really just a set of footnotes to the works of Plato.

I was recently reading Plato's disapproving comments on the dangerous new information technology of his day - writing - and suddenly realised that maybe Agile is doing a bit of Plato footnoting of its own.

"The fact is that this invention [writing] will produce forgetfulness in the souls of those who have learned it. They will not need to exercise their memories, being able to rely on what is written, calling things to mind no longer from within themselves by their own unaided powers, but under the stimulus of external marks that are alien to themselves." (Plato, Phaedrus 67-71)

I often think - and say to people who come on our courses - that Agile methods are really about making sure that a bunch of people who have tried to get through life by making "marks that are alien to themselves" - i.e. computer programs, have to talk about what they're doing. Sprint planning, story prioritisation, story estimation, daily meetings, sprint retrospectives, pair programming, all of these are ways of making sure that we're talking about what we're doing and by doing so, hopefully, starting to make sense of it.

I'm also reminded of the words of another wise man, Taiichi Ohno: "Too much information induces us to produce ahead and can also cause a mix-up in sequence ... Eventually, it becomes impossible to make a simple change in the production schedule. In business excess information should be suppressed." (Taiichi Ohno, Toyota Production System, p.50)

There's a limit to what you can talk about. Agile methods (such as time-boxed meetings) use the limits of conversation to suppress excess information as Ohno recommends and keep teams focussed on what's most important right now, for this iteration.

Labels: , ,

Tuesday, 6 November 2007 at

Buildling Agile Relationships with Suppliers: A Lesson from Toyota

Toyota didn't start making cars until the 1930's. Now they're the biggest car company in the world.

I just recently read a Boston Consulting Group white paper about the way that Toyota treats its suppliers which I think is really interesting. It's not easy to become a Toyota supplier. They have very exacting standards and expect to be given very deep access to the inner workings of any company that wants to become a supplier. Toyota's goal is to avoid "information hiding" allowing information that is useful to Toyota to flow from the supplier and vice versa. Once a company is a Toyota supplier Toyota work very hard on two things. They work very hard to improve the design and production of whatever components a supplier makes for them. As a result of this, they also seek to share the benefits of these productivity increases between Toyota and the supplier and maintain the suppliers profitability.

The relationships between customers and suppliers, especially for IT services is often very fraught. It's quite usual for "information hiding" to be built into the way that work is bid for and commissioned. A client asks suppliers to pitch for a piece of work and very often, price is used as the sole piece of information on which to make a decision. It's easy for the seeds of future disaster to be sown at this point. The client has just commissioned a piece of software that they don't fully understand from a supplier who has either bid so low because they have no idea of the full costs of implementing what the client wants, or they are "low-balling" to get the work with the hope that they can ask the client for extra money for changes further down the line. This isn't a good basis for a successful project.

Agile methods can get round this problem. Agile methods encourage information sharing between client and supplier. By delivering software in small iterations, Agile methods allow the suppliers to get paid a reasonable rate for what they do at a low risk to the client who gets to see working software early in the process. Once they see some software working, they have a chance to change their mind before it's too late.

Labels: , , ,

© Agile Lab, 2007-2009. All rights reserved.

sitemap

Powered by Blogger

Subscribe to Posts [Atom]