This blog entry is about the open space session with similar title I held at Scan-Agile 2009. It took me a while to write since I have never actually organized my thoughts on this. My intention was not to host a session but after hearing fifteen sessions announced about tools and methods I felt compelled to since a very important ingredient was missing: thinking and the principles that guide thinking.
Photo courtesy my fellow conference organizer Ari Tikka.
I will start this blog like I started my open space session: let me share with you the three principles of the most productive Scrum team I have ever been in. These principles guided our everyday life from choosing technologies to improving our ways of working. Agile architecture absolutely requires them. But even though these principles have arisen from agile software development, they are valid for most aspects of life. I exercise them daily in my personal life.
The thinking principles are:
1) Do only what is needed
2) First the problem, then the solution
3) Challenge everything
Principle 1: Do only what is needed
Doing only what is needed should be a give but it rarely is. If you think about it it is almost going along with the energy minimum principle. Do the bare minimum required, no more, no less. The problem is that figuring out what needs to be done is sometimes much more difficult than just doing a whole bunch of things (and there goes the energy minimum principle flying out the window). Most people and organizations for that matter seem to be awfully busy doing stuff they have no idea why it needs doing.
If you really think about it doing only what is needed is kind of a super-principle - the desired end state of things. But how to only do what is needed? My two following principles help achieving that.
Principle 2: First the problem, then the solution
The principle first the problem makes sure all newly created things serve a purpose and exist for a reason. It brings focus and clarity of purpose to problem solving, and is essential for working effectively. Having a clear problem statement prevents solutions from piling up and causing you to miss the forest for the trees in the long run.
Here's a helpful sentence for implementing this principle: "Yes very interesting, but what problem does that solve?". I drive my peers nuts with that sentence.
Principle 3: Challenge everything
Please have a look at an earlier blog I wrote on the very subject.
Challenging everything is really easy, just ask "Why?" enough. About five times should do it, as pointed out in the open space.
Another open space observation from Jukka Laurila: challenging everything and asking why a lot is the key to rational improvement - as opposed to religion.
By the way asking "why?" drives people nuts, too.
Relevance to agile
Not only do these principles align nicely with agile and lean, I daresay they are necessary for both. What else is lean about except pull, and only delivering when there is a need? Where do you think KISS comes from, and YAGNI? Why, from doing only what is needed and understanding the solution before applying a problem. It is all about minimalism.
Now on to agile adoption. I have heard of too many teams and companies having problems with adopting agile. Usually because they haven't thought about why they think they need agile hard enough. Introducing an agile practice or a concept is much more easier once you have a problem the practice solves. Instead of implementing dogma blindly, think, find concrete problems that agile can help solve and adopting agile becomes so much more easier.
Extreme real-life example
My intention was to host a completely non-technical open space session but alas - I had to bring in an example from my old life as software architect. Unfortunately that example tipped the entire discussion into architecture and the difficult job of software architect and other techy topics and I think over half of my audience vanished. Mea culpa.
In any case, I have written about my experience in my earlier blog about challenging everything. I spent two months getting rid of a single extra parameter in the integration interface to a system. Suffice to say, had anyone in my old organization been careful to first define the problem before coming up with a solution - or defining the need for all the functionality behind that extra parameter - man-months would have been saved.
Oh yeah, and the architecture of four systems would have been simplified. As a function of features complexity increases exponentially, remember?
Thought experiment: broken legs
Sometimes you have to look in deep to find purpose for work, and challenge quite a few surface-level goals by asking why a lot. A thought experiment I sometimes torment my friends with goes like this:
You break a leg and go to the doctor's to get it fixed. The doctor puts a cast on the leg. Why are casts put on broken legs? What problem do they solve?
"Because broken legs are supposed to be in casts!"
Yes, but why? Why are casts needed?
"Because broken legs are supposed to be fixed!"
Why do broken legs have to be fixed? What do you care?
"Because it hurts, stupid! And I can't walk with a broken leg!"
Bingo! The problem solved by casts is immobilization and pain making your life miserable.
By the way my open space audience aced this experiment and got the correct answer in two tries. Sometimes I've squeezed people for twenty minutes before getting them to think deep and get the right answer. Good job!
The Koskela Principle
This is a bit redundant but since I brought it up in the open space it is only fair I share it here. I coined the term The Koskela Principle years ago to describe the attitude of Second Lieutenant Koskela, the Finnish hero from The Unknown Soldier. My apologies to my foreign readers but I cannot translate the following without losing all connotations to Finnish culture or spending a day describing them.
The Koskela Principle: "Asialliset hommat hoidetaan, muuten ollaan kuin Ellun kanat."
That about says it all.
By the way, Lt. Koskela understands Lean.
Summary
Do only what is needed - it's almost like pull.
First the problem, then the solution - to avoid waste.
Challenge everything - to remove existing waste.
If you attended my open space session, it would be nice to hear from you! I did promise a few attendees to blog about my session and it would be cool to know if this blog reached you or not. I welcome everyone's thoughts, of course!
I am unsure how to end this blog since it is a bit of a rambling account of the open space, so I shall end it with a period.
I'm totally with you on asking why and defining the problem. But sometimes, especially when people get excited about something, you can piss people off. Which I am quite willing to do if I think it serves a purpose, but sometimes i do feel like just giving up. I think the "reputation" of the guy who asks tough questions has both helped me and shot me in the foot at the same time. Latter usually comes from people who have a hard time admitting that they were wrong or take questions as an attack against their idea. Also if the "Why?" is obvious to some people but not me, I tend to get a bit of grief, which sometimes can be a bit unmotivating.
ReplyDeleteHeiti, join the club :)
ReplyDeleteAt the time that "most productive" scrum team was going on everyone was seeing us as "those 3 bastards who want to shut everything down".
As Ari said, asking "why?" drives people nuts. Why? In my experience because most of the people give their enthusiasm too much space. When techies see something new they want to try that out, which is a good thing, but instead of doing pilot projects and such they (or better, we) tend to try applying those things in our own "real" work. If you bring that to its extreme, they would even build up some "problems" (that maybe are not evel real ones) just for the sake of trying out something new.
Now imagine this situation: you find a team that found a new technology, liked it, built their own "problem" so that it can be solved by applying that technology, then you ask them "why?" a couple of times and make visible that what they're doing is not needed. They will for sure hate you. On the other end, you've just made your company not wasting some moneys.
My experience says that in the long run people will start respecting your opinion, but yes, for a while you're just seen as the negative guy, unfortunately.
Do you recommend to challenge Everything. Also the original problem definition? If yes I'm with you.
ReplyDelete