Agile Saturday talk: Scrum is Not Enough 2.0

I gave a talk in Agile Saturday organized by the good people of Agile Estonia. It was about how Scrum is not enough for solving the problems that a good Scrum implementation surfaces. Here are the slides.

Scrum is not enough v2.0

View more presentations from aritanninen.

Thanks to all organizes and especially Stan and Heiti who took such good care of us! It was a fun day with lots of excitement and good energy. :o)

I would love to hear your comments on my presentation! And if you are one of the people I shared a meter of beer with yesterday evening, drop a comment, too!

Update: I am on video, too!

Scrum Is Not Enough v2.0 from devtraining.ee on Vimeo.

OO Day 2009 presentation: Scrum Is Not Enough

Here are the slides for a presentation I gave with Marko today at OO Day 2009 in Tampere, Finland. We had around 400 people in the audience - more than there were attendees in Scan-Agile 2009!



Since the presentation was in Finnish so are the slides. I might write more on the subject later on.

Scrum Is Not Enough

View more documents from aritanninen.

Paper on TDD and architecture

Couple of years ago me and Marko Taipale wrote an experience report on our experiment in using TDD (in the strict, XP definition) to build a game platform. The idea was to try and see if an architecture would emerge like XP claims (it did not).

Originally the paper was intended as an experience report for the XP2008 conference but was rejected due to insufficient research data. It is fair to say that the paper is our take on the TDD controversy that raged at that time, and we did write it at Jim Coplien's suggestion.

The paper is a couple of years old but since at least two people asked for a copy I decided to put the paper online. Perhaps you will find it interesting.

xp2008_experience_report_marko_taipale_ari_tanninen.pdf

Testing In Agile presentation

I gave a thirty-minute talk about testing in agile projects in December's Agile Dinner in Helsinki. Here are the slides.

Testing In Agile

View more documents from aritanninen.

It was nice to have so many participants from TestausOSY visiting our dinner! Too bad not many stayed for the beers (read: actual conversation) afterwards.

Dr. Deming's Management's Five Deadly Diseases

Here is an Encyclopaedia Britannica Film from 1984 featuring Dr. Deming himself: Management's Five Deadly Diseases. Awesome.



1) Lack of constancy of purpose
No planning for the future
Lack of long-term definition and goals

"People haven't decided what it is that they're in business for. They really don't know. Do they define it in terms of a service? To produce product and service that has a market of the future? Or is just to have jobs - get paid? Have jobs, live a little while, then get into something else? Lack of consciousness of purpose means: short term thinking."

2) Emphasis on short term profits
Worship the quarterly dividend
Sacrificing long-term growth of the company

"Dividends. No matter what, creative accounting, shipping stuff out, no matter what. Make it look good. Devastating to long term planning with a plan to stay in business, through improvement of quality, of product and service. They cannot do it together."

3) Annual rating of performance
Arbitrary and unjust system
Demoralizing to employees
Nourishes short-term performance
Annihilates team work, encourages fear

"Pay for merit! Pay for what you get! Reward for performance. Can't be done! Unfortunately it can't be done short-range. In ten years? Perhaps. In twenty years? Yes."

"The effect is devastating, people must have something to show, something to count. In other words the merit system nourishes short term performance. It annihilates short term planning. It annihilates teamwork. People can't work together."

4) Mobility of management
No roots in the company
No knowledge of the company
No understanding of its problems

"Annual rating encourages mobility of management. Somebody does not get the top rating which means a raise he looks around for another job. People move around. Not having roots in the company. Not understanding the company, just trying to bring in some abilities, learn some more, move along. Management requires knowledge in the company, roots in the company, knowledge of the problems. A production of sales, and service. Takes a long time."

5) Use of visible figures only
No use of figures that are unknown and unknowable
Encouraged by business schools

"What are the figures of the multiplying effect of a happy customer? The multiplying effects of an unhappy customer? I don't see the figures. They're very important. Those who run the company without them have no company. They're not teaching transformation, they're teaching use of visible figures, creative accounting. How to maximize the price of the company's stock. Keeping up that quarterly dividend."

...

"We're [americans] number one, for under development. Are people not used, mismanaged, misused and abused and underused by a management that worships sacred cows. Style of management that was never right, that made good fortune for this country between 1950 and 1968 because the rest of the world was devastated. You couldn't go wrong no matter what you did. Those days are over! About time for american management to wake up!"

Open Space Session: Think!

Intro & thinking principles

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.

Leadership and self-organization

"The only truly self-organizing team I know of was Apollo 13 after the pop."

(Thanks for that one, Mom!)

Teams do not spontaneously materialize out of thin air, and just by accident happen to pick a goal that by coincidence is in line with the surrounding organization's objectives. Teams need to be formed, and they need to be given a purpose. Sometimes that is done by a memeber of the team and sometimes by an external party.

I call the process of forming a team and giving it purpose leadership.

Leadership is not only vital to self-organization it is usually a pre-requisite for it. Without leadership there is no team, and without a team there is no self-organization. Apollo 13 teams who are driven by a single, overwhelming imperative pushing them to self-organize are rare in the modern corporate world.

Besides team-forming and goal-setting leadership can serve other purposes in teamwork. These can be guiding the team's daily work, keeping the team on the right course, removing team dysfunctions and in general all activities that help the team. Whether this kind of leadership is needed or not, and wheter it should be internal or external to theam depends entirely on circumstance. What is important that leadership can serve a purpose and is probably needed in one form or another during the life-span of a team.

The idea that leadership is not necessary because teams self-organize is wishful thinking at best.

It will be interesting to hear what Mary Poppendieck has to say about this subject in her keynote tomorrow at Scandinavian Agile Conference 2009.