Posts Tagged Toyota

It isn’t Agile because you say so

I have yet to observe a process that wouldn’t benefit from a dash of Agile. Or why not a really healthy dose. From being frowned upon by many in the late 1990:s, it has become mainstream to realize that there’s something really important in the agile message. Whole companies are run with agile values at the core. Like IKEA. Like H&M. (Yeah, I’m from Sweden.) Or Toyota (Lean is very, very similar to agile. I’d say that at the core it’s the same thing.)

While more and more people are trying to relate to the concept of agile, we also run the risk that the meaning is devalued and kidnapped. It’s highest fashion to label yourself Agile. There are several problems with that. If you fool yourself you run the risk of not going at your full potential. Or if it’s just “play pretend” you risk really fooling others and they might not realize for a long while that they could have ran so much faster. And of course, false agile also risks giving the “movement” a bad name it truly doesn’t deserve.

You find lots of people that say they are agile. Yet, when you probe it some it’s clear that it seems to have totally different meaning to many. Like it didn’t matter. But it does matter! Agile is a stance, an attitude, a philosophy, a core value even. It’s something you must comprehend. Something you must give some time to soak your being. Something you must truly believe in before you have the right to use the label. I’m totally sick of hearing people excuse shortsighted moves with a sloppy “we are agile”. That’s wrong in so many ways. Agile is all, 100%, totally and utterly about sustainability, about the long term.

All “casual” agilists out there should be forced to really try an agile process. Why not Scrum? Of course, running Scrum doesn’t make you agile. But you can’t give Scrum a real chance without starting to get an idea about what the concept of agile is about. Then hopefully the casuals will be humble enough to first stop calling themselves agile and then working hard with themselves and their views to really earn the label.

Or maybe they’ll find that it’s not for them. I don’t think agile leaves many people indifferent (given that they given it some thought and started to grasp it). Rather, you either love it or hate it. When the agile values become clear to you there are no longer any gray areas. If you have a strong belief in your fellow human beings you’re likely to find agile being your thing. At the very core of agile there is this strong conviction that most people really want and can contribute. In agile land there’s no room for cynics.

Does your organization want the agile label? Then start with removing all processes that are in place for monitoring that people contribute or are doing their jobs. Install mechanism that make it clear to people what’s expected of them and what they can expect from others. Make each and every process fully transparent. Demand authenticity from everyone, including yourself. Make sure you learn from experience, good, bad, in-between. Yours and others. Don’t save any effort, whatsoever, to enable communication. And keep asking yourself, every day, every breathing moment. Are there some remains, somewhere, of your non-agile past? Hunt them down. Remove them! Ban phrases like “that’s not how we usually do it” and “we’ve already tried that”.

, , , ,

1 Comment

The learning organisms that should be us

I blame the financial crisis on our disability to learn from our experience. We’re in it because we overstimulated the economy (I think few people actually argues with that.) And we were in the last mess for the same reasons. Yet, when the leaders of the world, people who supposedly should be the best we have for dealing with these big issues, when these leaders tackles the problem all they can think up is to stimulate it more. People are demanding more. Already stimulus worth 5 trillion US dollars has been launched or decided and they plan to make that a lot more. Now if that isn’t a failure to learn from mistakes, then what is?

Learn from your mistakes. It’s said often. Yet, when I try to focus my surroundings on what we can learn from the situation we’re in right now, I feel like I’m often not heard. Almost like if people (probably including myself) shy away from thinking too much about the past. Nextopia, by Micael Dahlén, seems to explain why this is so. Evolution has  favoured looking forwards, rather than backwards.

I have to agree with Nextopia here. When you’re about to do something of any importance it’s crucial to focus forward. But I’m equally sure about how important it is to also learn from the past. And when better to do it than when the past is just a few hours, days or weeks away? Håkan Åberg correctly identifies this in his blog about drawbacks (sorry, only in Swedish). Though I wouldn’t limit the importance of learning to mistakes. It doesn’t really matter if things went extremely well or disastrously bad or anything in between. You have to make sure you learn from experience, your’s and other’s.

Agile, stay agile!

Being a big fan(atic) of agile values and principles and having good experiences from running and participating in SCRUM and XP projects I’d say that you could probably skip all SCRUM principles, but one, retrospectives. Correctly applied, even if you’re running the most rigid process to begin with I bet that you’d end up with something rather SCRUM-like after a few years or so. However, running SCRUM by the book in all but retrospectives you’ll probably end up in a big mess instead. Well, no, daily stand-up meetings, lots of communication and other things important in SCRUM will probably save you from drowning, but you won’t go at your full speed possible.

Play to win or don’t play at all

To reach full speed you need to learn from experience. And going at your full speed is what it takes to win and keep harvesting victories. I’ve found that it’s good to train your awareness about when you’ve just experienced something. When the bell rings it’s time to take a few seconds to ponder; “what took me to here?”, “where could I have ended up instead?”, “what would have taken me there?”. And this should be a recursive process. You’re looking for the root cause, not just some symptoms on the way.

At Toyota (whohoo, you saw it coming?) they take this with finding the root cause really seriously. They apply a technique called The five whys. Keep asking why until you find the root cause. This sometimes takes five whys, sometimes less. Say you’re manufacturing ski jackets. A customer calls complaining about a loose button on her almost new jacket. That I’m-experiencing-something bell rings. Why did we ship a sub standard jacket? Because the button was probably not loose during the quality assurance. Then, why is that button loose? Because the sewing thread gave away. Why did it give away? Was it because the thread was too weak? No. Then why? Because the edges of the holes in the button are too sharp. OK, so inform the subcontractor that we need buttons with smooth hole edges. And make sure the subcontractor applies five whys too find out why they shipped those buttons. But.. why didn’t we find this problem when we tested the jacket design? Because back then the buttons where different, we changed it later when we found out that they were hard to use with bare hands in the cold. Why didn’t we rerun the button stress test when we changed the buttons? Because we forgot. Why did we forget that? Because our checklist doesn’t enforce it. Fix the checklist. But also take some time to reinject the awareness of your company’s high quality values in your organisation. This shouldn’t have happened regardless of the shape of that checklist. Buttons are probably popping from lots of those jackets out there without the customers telling you. You’re brand just took a blow. Don’t let it happen again. Learn.

Movie sequels often miss because?

Alright, so that was a bad experience. Evaluating a success also should seek that root cause. But to my experience that’s not as linear as five whys. It’s more about not jumping to conclusions. I know not all agree with me, but I just don’t think The Matrix Reloaded was nearly as good as the first Matrix movie (which I hold as one of the best movies ever made). They reloaded it with the wrong things. They jumped to conclusions I think. It’s like they thought that the really cool thing with the first movie was those never-seen-before special effects. Wrong! Those were cool, but not the really cool thing. Personally I think that what made The Matrix so cool was something about the story itself. I think that if I had been in charge I would have encouraged my team to not spare any effort in evaluating what really was the thing. And then of course to think really hard about wether it was even possible to advance things with a sequel. Maybe it would have been better to try find out what caused that story to emerge and see if it was possible to find more good stuff at the well.

In big and in small

Five whys. Sounds heavy? It isn’t. But even so there are lighter practices that one can apply too. Like before you go to sleep, think a bit about the day. Figure if there where good stuff that can be improved even more and/or you should do more often. Or were there some drawbacks that you really could have avoided. Did you remember to spread some happiness around you today? You get the picture. When you’re going to sleep it’s not a performance anyway so looking backward some won’t hurt. When you rise to meet the next day you can apply full focus forward again.

, , ,

7 Comments