Archive for the ‘Lean’ Category

Understanding before documentation

July 25, 2008

One of the most important principles I use in all the agile and lean software development or cross functional teams I run is ‘understanding first’. This means that teams must first seek to understand and only then write that up. My default form of this is to take two very different groups — perhaps IT and the business or product management and producers or finance and a budget owner — and get them to each explain their viewpoint to the other. They talk until the other group can explain their viewpoint to their own satisfaction. Then they sit together and write it up.

The longer that the groups work together the more rapport that they build. Talking is many times quicker than writing and this is many times quicker again than waiting for an email response. Once understanding is reached the last crinkles can be ironed out by writing together.

Often the business will ask IT to do the write up so that they can review at their leisure. This is a mistake. It confuses the time spent as support with the total time needed. A little feedback in the first write up can be the difference that makes the difference so that only one iteration is needed.

Advertisements

How not service customers — by the Rabobank

June 11, 2008

My Rabobank credit card was rejected (and apparently had been rejected before, but I only just noticed it). Here is the value stream mapping of my customer experience with the Rabobank customer service group. Total value time: 2 minutes. Total wasted time: 29 minutes. Efficiency ratio: 6.9%.

First I searched for the number of my account manager. This was given as +31 71 565 9393 — the same number as the main service desk, so:

1. Call the Rabobank service desk +31 71 565 9393. Takes a few minutes to get someone on the line. Explain the issue (card rejected). Nice man asks me to hold which I do for a minute before he disconnects me. Wasted time: 7 minutes.

2. Call the Rabobank service desk again. Takes a few minutes to get someone on the line. Explain the issue and that I already called. Take a note of her name. Nice lady asks me to hold. I hold. She connects through to someone else. Wasted time: 7 minutes.

3. My account manager. Explain the issue to him. He asks me to hold, then after a couple of minutes of doing this, he explains that it will take a little to find out what’s going on and he will call me back. I reiterate that I don’t want to know what’s wrong, I want to be able to use the card that I pay them for. Wasted time: 4 minutes.

4. 5 minutes later he calls me back. He explains that I need to call another department (i.e. they’ve outsourced their services). When I ask why he can’t fix the issue, he says he’s not authorised. When I ask the name of the department, he can’t tell me but says they can fix Gold card problems. I didn’t even know that I had a Gold card. I call the mystery number +31 88 722 6777 (interestingly 088 722 6777 seems to also be the number of a property in Bulgaria — http://www.estroitelstvo.com/imoti/kashti-kashta-enno270306.html. If only the Netherlands allowed reverse look-up). Wasted time: 5 minutes.

5. I call the number and talk to the nice lady. She says that to solve the problem I’ll need to talk to someone else. So she puts me through. Wasted time: 3 minutes.

6. The lady asks me some security questions, explains the card is blocked, because of strange activity. She can’t tell me what the activity is, but having seen that I’ve looked at and approved all my statements, she unblocks the card. Result!

I asked why no-one from the Rabobank contacted me. She says that a letter was sent and our house number was called. When I say we never got a letter, she laughs like “sure, sure, that’s what they all say, eh?”. She does say that the strange transaction occurred in Japan. When I point out that I’ve been through this before and that the Rabobank knows I travel, she says it’s not that the amount was high or that the transaction occurred in Japan, it’s that “the computer” spotted something strange, but she can’t tell me what that is.

Then I ask why the Rabobank chose to contact me with my home phone when they knew I was in Japan. She said because the transaction was fraudulent (it wasn’t), they might expect to find me at home or someone who could confirm that I was in Japan (apart from the other five or six transactions in Japan in the days before that is). The conversation was getting more bizarre by the minute. I asked why they couldn’t contact me in some other way. After all my Rabobank account manager has my full contact details: mobile phone, house number and email addresses. The nice lady (who was steadily getting more irate) explained that if I could give her these contact details and give her permission to use them, she would next time, but due to security concerns my Rabobank account manager could not contact her about this issue, or pass on my contact details!

When I ask how come the Rabobank has assigned me a special account manager who is supposed to my one stop shop and has to pass me through to the Gold card department to get these kinds of things fixed, she asks me what I’m talking about. “Gold card? Gold card? I have no idea what you are talking about!” It turns out that her department has nothing to do with Gold card. Go figure. Value time: 2 minutes. Wasted time: 6 minutes.

Total value time: 2 minutes. Total wasted time: 29 minutes. Efficiency ratio: 6.9%.

Dealing with unexpectancies

March 27, 2007

Nuno writes that “Why shouldn’t we try finding out find a model to deal with unexpectancies instead?
The thing is that if you by some cosmic accident find too much unexpectancies along the way your iteration plan will become a baby monster.”

Well, we do assume change will happen and most times it does. We also try to build some slack into each iteration, so that things can go wrong (because they always do) — that’s what velocity is for. But in the end: you’re right. There is that worst case scenario where everything falls apart and all the high-level estimates are wrong and we have to update all the planning just like it was a classicly managed project — i.e. update the project plan and re-do all the resource planning. From my experience this worse-case rarely actually happens.

There are some underlying assumptions:

  • Features are independent, negotiable, valuable to users, estimable, small and testable
  • We can easily move features from one iteration to another
  • We can use the same resources for each iteration

We know that in reality these assumptions are either wrong and at best partially true. However, we can turn that around and make that a roadmap for our business and IT, e.g.

  • Spread the knowledge between BA and developer resources so that it becomes easier to use the same resources for a number of different iterations (hitting different systems)
  • Make the technical architecture more modular (there are some pretty standard ways of approaching this for legacy systems)
  • Teach the business how to take thin enough client-valued strips of features across systems so that they are small enough for a few to fit into an iteration

Technorati Tags: , , ,

What software development problems do agile best practices answer?

February 4, 2007

In Which best practice to implement first? I said that agile best practices are really answers to problems. The best way to identify the correct agile practice to implement first is to work out the root causes of your biggest software development problems. Let’s take an example that is common complaint from many business customers: how come our IT department delivers so little? Rather than just complain about this, let’s keep on asking ‘why’. We can list some of the products that our IT department produces:

  • Project plans
  • Project charters
  • Test plans
  • Software working in production
  • Estimates
  • Change requests
  • Status reports

Of these, what is most important to us? In fact, there is only one product which we really care about: software working in production. The others are simply products that we have been led to believe are required to deliver software on time and budget. From a lean point of view, these other products are ‘waste‘: they do not directly add value to the customer.
In my research I found that most of the time, it was not just a project manager delivering these management deliverables, it was the whole team: programmers, application development managers, testers, etc. So, why is IT spending so much time doing everything but what is essential to producing software?

The following is a snippet of a ‘Current Reality Tree’, a Theory of Constraints approach to describing how things work right now.
Plans and estimates are waste
A Current Reality Tree (CRT) can be read ‘A causes B’ or ‘A means B’, e.g. “Lots of time updating plans & estimates means less time for delivering software”. We can create a CRT by asking ‘why’ repeatedly. For instance, why do we spend less time delivering software? Because we spend lots of time updating plans & estimates. Why do we spend so much time updating plans & estimates? Because changes happen more frequently than we had planned. The power of a CRT comes from being able to identify some of the root causes to business issues. Some of the answers are more implicit assumptions than direct answers. e.g. Why do changes happen more frequently than planned? Not only because we keep on changing our list of priorities, but also because the business demands that IT produce a new set of plans, status reports and estimates of new delivery dates every time the priorities are changed.

So, how can we turn these problems into solutions? We need to tackle one or both of the two root causes identified in the CRT:

  • The business demands a plan-based approach
  • Multiple changing priorities

In my experience, changing either one of these brings a lot of great results very quickly.

At first glance, either of these seem to permeate most business environments. Can there be an alternative to a plan-based approach to building software? It’s to this type of question that agile best practices provide such great answers. For instance, a time-boxed deployment schedule where the schedule is fixed, but scope is allowed to vary is a non-plan based approach. If a feature takes an unexpected amount of time to deliver, it can slip to the next iteration. The impact of the change is small and the product that requires updating is the software itself. In contrast, in a plan-based approach, the team delivering the software needs to update plans, estimates and delivery schedules. The next steps are to identify how this time-boxed approach will work in practice. This is to ensure that it does not create additional business issues and to ensure that we have everything required for a successful implementation. In a way, this is just another way of continuing to ask ‘why’. Luckily, as we get deeper into the implementation, there will be other agile practices to help us, such as continuous integration and test driven development.

Technorati Tags: , , , ,

Lean software development from concept to cash

January 17, 2007

Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck & Tom Poppendieck is one of my favourite books right now. The book is not a big selection of agile recipes you can apply to different situations, instead the Poppendiecks take us back to first principles. They show how these principles drive the different agile practice. Ultimately they demonstrate how to think about your software development and what it means to become more effective. If you have decided to embark on making software development better, then this book can help you choose what it most important and what to do about it. The authors cover a history of lean and the seven principles of lean software development, ripped from their first book (Lean Software Development). The meat of the book covers off value, waste, speed, people, knowledge, quality, partners, and the journey ahead.

A couple of things made the book different for me: firstly, it is a great mix of sage advice, first principles from the grandfathers of lean, real-life stories and practical exercises. Secondly, it really covers the full value stream from your first ideas about software to ringing up the sale.

Technorati Tags: , , ,

Success is less than just features

January 12, 2007

DancingMango says (correctly) that Success is more than just features. He uses the “DeLone and McLean model for Information Systems (IS) success [pdf].” to show that the benefits come from (what I would call) impacts, not the features themselves.

DeLone and McLean model for IS success.  Slightly modified.

What is not obvious from this explanation is that more often that not feature bloat or gold-plating code are major hygiene factors, i.e. they need to be removed and simplified in order to deliver system, information and service quality. If you like, you can think of a parallel input to quality: simplicity instead of features.

This is initially a hard idea to sell to the business: deliver more benefits by delivering less features. The customer often thinks it’s her job to increase the number of features. After all, agile is about increasing throughput, right? We all need to remember user-valued features working in production that is the important measure. Non-user-valued features or features that are hard to find detract from the quality of the system, information and service and dissatisfy the user.

Removing hygiene factors that dissatisfy is often a quicker way to benefits than increasing features to try to satisfy.

Technorati Tags: , , ,

Success is less than just features

January 12, 2007

DancingMango says (correctly) that Success is more than just features. He uses the “DeLone and McLean model for Information Systems (IS) success [pdf].” to show that the benefits come from (what I would call) impacts, not the features themselves.

DeLone and McLean model for IS success.  Slightly modified.

What is not obvious from this explanation is that more often that not feature bloat or gold-plating code are major hygiene factors, i.e. they need to be removed and simplified in order to deliver system, information and service quality. If you like, you can think of a parallel input to quality: simplicity instead of features.

This is initially a hard idea to sell to the business: deliver more benefits by delivering less features. The customer often thinks it’s her job to increase the number of features. After all, agile is about increasing throughput, right? We all need to remember user-valued features working in production that is the important measure. Non-user-valued features or features that are hard to find detract from the quality of the system, information and service and dissatisfy the user.

Removing hygiene factors that dissatisfy is often a quicker way to benefits than increasing features to try to satisfy.

Technorati Tags: , , ,

Lean eating

January 6, 2007

I Can Make You Thin is a lean approach to eating (excuse the pun). Instead of eating a set amount at regular times, you eat when you feel hungry and stop when you feel full.

This is an implementation of the lean principle of a ‘pull system’. Pull systems occur in other places in real life. You wouldn’t go to the petrol station to fill your car up until the petrol gauge was near-empty. You wouldn’t keep on putting petrol in after the car was full. Toyota uses Kanban cards to let producers know that a piece of material is needed. Until the card is received nothing is produced. You check what needs buying each week before you do your shopping (although some of us do better at this than others). Overproduction is an important source of waste.
In the same way, with this ‘un-diet’, hunger is a Kanban card that let’s you know that it time to start eating. When you start to feel full, you stop. The other ideas in the book are directed at changing behaviours to support this. For instance most of us are pretty bad at paying attention to our bodies when we eat. We stuff the food into our mouths whilst we focus our awareness on something else. This makes it pretty hard to know when we’re hungry or when we’re full, until we are so completely stuffed that we’re going to be sick if we eat more. In this system, you s-l-o-w down the speed at which you eat and eat each mouthful consciously. In this way, you stand a much better chance at realising you are full before you stuff another mouthful in.

I’ve had a lot of fun over Christmas, eating whatever I want and still losing (and then maintaining) weight. This is in stark comparison to previous Christmases where I followed a Seefood diet religously: if I saw food I ate it.

I notice a couple of things from this different approach to eating. Firstly, I eat a lot less food but I don’t get hungry. Secondly, the proportion of times that I eat ‘bad’ food, e.g. high fat high sugar food, is much higher, although in food weight I reckon I eat about the same proportions as before.

Technorati Tags: ,