Still Life

P.: Richard’s a nice guy.
Z: He’s changed a lot since meeting a lady friend recently.
P.: (Pauses) Has he changed for the better?
Z: Definitely. Richard’s got potential.
P.: (Smiles)
Z: I like to think of him as a work-in-progress.

Life as Art

I’d never heard of someone being described as a ‘work-in-progress’ before. My friend Z. is an artistic, cultured kind of guy, so when he described Richard as a work-in-progress, he had meant it to be a compliment of sorts. The idea that Richard had the potential to be an artist’s masterpiece. Being a work-in-progress is part of that journey.

Zach’s use of the term ‘work-in-progress’ also reminded me of Lean. In Lean, you strive to first deliver value. You achieve this by minimising work-in-progress. That’s because too much work-in-progress blocks flow, delays value from being realised. Worst of all, it hides waste.

In Richard’s case, he’s the single piece of work-in-progress on his Assembly Line of Life. That fits nicely with Lean where you want to be working on one thing at a time.
From Journeyman to Master

But something’s still missing from the equation. Does being part of the status quo help us become a masterpiece? Does reliving the same year twenty times give us twenty years of experience? Sounds more like a death march to me.

Then it dawns upon me, the most magical ingredient of all.

Kaizen’s for life, not just on birthdays

In life, we are the artist as well as our own potential masterpiece. We become a work-in-progress from the day we’re born and remain one until we die. The Goal is to turn our life into our own masterpiece. To achieve that goal we need to continuously improve. Continuous Improvement forces us to learn. And to change. By changing for the better, we move closer towards our Goal. And so the virtuous circle takes shape to become the wheel that rolls us forward.

Make yours a masterpiece. Love something, change something, make something better.

Preparing for XP Days Benelux

Thursday, the XP Days Benelux start. The first sessions start at 10:00; the conference organisation is about done by then. Once the conference gets going, there’s not a lot of work for the organisers. From then on, the session presenters and participants have to do their bit. We’re not kidding when we say that “the focus of this conference is on practical knowledge, real-world experience, and active participation of everyone”.

Bigger and better than ever before

At least it’s bigger than before. The number of participants has grown steadily from 85 in the first year to more than 150 this year. We’ve always set a cap on the number of participants: 30 participants per track. That (plus or minus 10) is about the number of participants with whom you can have really interactive session.

Better?

We’ll know from the retrospective if we’ve improved on last year.

See you there

Or if you can’t be there, follow the conference via the FriendFeed XP Days Benelux room or read our presenter and attendees’ blogs.

More later.

Conversation overheard in a galactic corridor

(At an Agile conference in a galaxy near you)

A: I am Agamemnon the Agile.
P: That’s nice for you.
A: I am Leader of the Alliance.
P: There are many alliances.
A: Join us.
P: Thanks, but I prefer to keep my options open.

What are Real Options?

Real Options is a decision-making process for managing uncertainty and risk. It’s a simple and powerful approach that helps us make better informed decisions, as individuals and in groups, by understanding and responding to the psychological effects uncertainty has on our behaviour.

Real Options means:

1. You don’t have to decide now (aka ‘Decide at the last responsible moment’)
2. But you know when to decide
3. Keep as many options open for as long as possible
4. Actively gather information until you have to make the decision
5. Only commit when you must or when you have a good reason to.

A Real Option:

• Has a value
• Has an expiry date or condition
• Costs: cost of buying the option + cost of exercising the option.

The concept of Real Options was first coined by Chris Matts. You can read more about the original concept here.

The Real Options Space Game: The New Frontier

Pascal and I began working on the idea of a Real Options game after co-presenting a Real Options session at SPA 2008 with Chris back in March this year. Within a month, Pascal and I had a first version of the Real Options Space Game ready for trial in London. Since then, we’ve played it at Agile North and XPDay France.

The Real Options Space Game *New* Version 2.0

During our travels far and near, we’ve encountered many different species of Agilistas and made many friends. We’ve learnt to think more deeply about options and opportunities, for ourselves and in relation to others. Most important of all, we’ve stumbled across the secret to preserving galactic peace.

Meanwhile, Pascal and I’ve been tweaking and polishing the game thanks to the feedback from all the players. We’re pleased to announce that version 2.0 of the Real Options Space Game is now ready for play.

Go, go game play!

Come join us at XPDay London (11 - 12 December) if 1) you think you can take on the ultimate challenge in common sense; 2) you want to know the secret to preserving galactic peace (it’s this kind of general knowledge that gets Agilistas out of tricky spots of bother).

A simple question

Agile Coach: OK. A professional takes responsibility and is an openminded lifelong learner.

P: Yes. A professional knows what to do and does it.

Agile Coach: That sounds a bit mercenary. It somehow feels wrong to me. Is there no more to being professional?

P: (Embarrassed silence. Then) Let me think about it and I’ll have the answer by next week. Is that ok for you?

Agile Coach: Yes. I want to become a good professional.

What is the acceptance test for “a professional”? How can we recognise one? What are the essential characteristics of a professional?

Acceptance criteria #3: A professional acts ethically according to values

A professional acts according to a Code of Ethics

The ACM and IEEE have a Code of Ethics for Software Engineers. Here is the short version:

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC - Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.

8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Copyright (c) 1999 by the Association for Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers, Inc. Read the the full version

Read the short and the long version. Replace ‘Software engineer’ by I. Does this code of ethics apply to you?

A professional acts according to a set of Values

Daniel Dennett shows in “Darwin’s Dangerous Idea” that we don’t have the time or resources (or even the techniques) to completely analyse our ethical dilemmas. Rules and values offer convenient shortcuts to quickly resolve dilemmas in a reasonably good way.

That’s why I try to act according to a set of Agile Values.They act as warning lights for potential problems.

Communication

Of course, we talk a lot, write and read a lot of documents. But do we communicate well? Do all stakeholders of our project talk the same language, use the same metaphors and have a common vision? Do we verify if we understand others, for example by using the “9 boxes” interview technique?

Collaboration

Of course, we’re all in the same room (except for the testers and the systems engineers and the support team and…). But do we all really collaborate? Do we have common goals across the whole value chain, including partners and suppliers? Are we all aligned towards that common goal? Do we succeed and fail as a team or am I rewarded for personal successes?

Feedback

Of course, we always work with short iterations. But have we built in mechanisms to give us rapid and regular feedback? Do we steer our project based on the feedback? How long can we afford go “steady as she goes”? Is our feedback cycle shorter than that? What do we do when our feedback mechanisms give us bad news?

Simplicity

Of course, we know about YAGNI and DTSTTCPW. But do we really work to keep things simple? Do we invest the refactoring time and effort to keep our software simple and malleable? Do we reflect and adapt our processes to keep them simple, lean and efficient? Do we relentlessly strive to make everything simpler?

Quality

Of course, we know that “Quality is Free“. But do we really believe that? Do we keep our standards for quality high when we’re under pressure — especially when we’re under pressure? Are we tempted to take shortcuts and “fix it later”? Do we support each other to resist the pressure to do things “slow & dirty”? Do we welcome issue reports and perform root cause analysis so that we can implement Jidoka and Poka Yoke?

Respect

Of course, we all respect each other. That goes without saying, which is why this value was left out of the original Agile values. But then why do we still see deathmarches? Do we respect the value that each team member brings to the project? Do we respect the ‘other’ teams with whom we have to collaborate?

Trust

Of course, we trust each other. But, do you really trust everyone on the team to make correct changes to your code? Do the developers really trust their management’s judgments and decisions? Do managers trust their team’s estimates and technical choices? Do we trust the onsite customer’s choices and priorities? Do we trust that everyone on the team will take responsibility? Always?

Transparency

Of course, we’re transparent; you just have to come look at our whiteboard and burndown chart. But do we really make all information visible, including the bad news? Do we really share the project risks with everybody involved, including the customer?

Do I Pass the Test?

There are few people who would dispute the ‘goodness’ of these values or the code of ethics guidelines, yet they’re hard to follow. We’ve all seen people who’ve compromised these guidelines under pressure. We’ve all been in situations where we were at least tempted to compromise or lacked the courage to stand up for our values. I certainly have.

Read the the full version of the code of ethics and ask yourself: do I pass all of those acceptance tests?

What can I do today to improve my ’score’?

What small step can I take today to become more professional?

A simple question

Agile Coach: OK. A professional takes responsibility.

P: Yes. Many projects go wrong because so few people really take responsibility.

Agile Coach: Blaming is much easier, isn’t it? Is there more to being professional?

P: (Embarrassed silence. Then) Let me think about it and I’ll have the answer by next week. Is that ok for you?

Agile Coach: Yes. I want to learn more about becoming professional.

What is the acceptance test for “a professional”? How can we recognise one? What are the essential characteristics of a professional?

Acceptance criteria #2: A professional is openminded and a lifelong learner

Other people might have good ideas too

Recently I heard a bunch of “Agilistas” dismiss CMMi offhand. I know of CMMi implementations and training that were poorly done and resulted in not much more than extra overhead. Some people don’t understand the spirit and only know the letter. I’ve seen the same with Agile. Despite flawed implementations, CMMi contains a bunch of interesting ideas and techniques. The spirit of CMMi is compatible with my Agile values.

At another Agile gathering hackles were raised when a presenter dared to suggest that the Lean practice of “Standardized Work” might be usefully applied to IT work. “We’re not production workers!” they cried. Others dismissed practices because they would be used by “evil managers” to create “plug-compatible programmers”. My hackles went up when a session presenter recently dismissed first all managers then all salespeople as ignorant and evil.

A professional can’t afford a closed mind.

Other discplines, other approaches and other professions have interesting ideas. The most interesting training I ever followed was a sales training.

I like conferences where I can see and meet presenters with different backgrounds and ideas. For example, I like the diversity in subjects and delivery of the Benelux XP Days, but I worry that there are few sessions that present something I disagree with. I wonder why there are so few sessions that explain what went wrong with Agile.

I seek to perceive more than I seek to be perceived. I seek and find value wherever I can.

Mistakes are a learning opportunity

We’re trained to dislike and avoid mistakes. However, mistakes do happen. How we react to them allows us to see who the professionals are.

A professional says “Thank you!” to a bug reporter.

When we learn of a mistake we get the opportunity to do some deep learning and improvement. We learn from the answer to two questions:

• “Why didn’t we detect this problem earlier?” What’s wrong with our tests? Why wasn’t this case covered? How can we detect this type of issue sooner? How can we improve our tests? If we do this consistently, we implement “Jidoka” so that we’re alerted immediately when something goes wrong and can fix the problem while it’s still cheap to correct.
• “Why did we make this type of mistake?” What is the root cause of the problem? What is it that allows this type of problem to occur? How can we change our work or methods so that this type of problem can’t occur? If we do this consistently, we implement “Poka Yoke” or mistake-proofing because the cheapest issue to fix is the one that doesn’t happen.

I welcome reported mistakes as a learning opportunity.

Continuous Improvement

Standardized Work documents the best way we know of doing something. Tomorrow we’ll do better. It’s important to celebrate today’s successes. But we know we can do better next time, if we learn and improve.

A professional always looks for ways to do things better.

Thinking tools like Systems Thinking, Theory of Constraints, Lean and Agile help me to make sense of the situation, see places to intervene and find creative ways to make things better. Personal Agility tools like Congruence, Agile Fairytales and other games allow me to become a better person, colleague, friend and coach every day.

I have done my best today; I can do better tomorrow.

Invest in learning

All of this improvement and learning costs time, effort and money. Companies and people facing difficult times fear they have none of these three. Yet, when the going gets tough the smart keep learning.

A professional invests in learning.

I meet new people at work, conferences, training and talks. I learn something from each person I meet. Every situation has interesting angles that make me see new things. Books, both fiction and non-fiction, make me travel to different worlds, introduce me to new people, new ideas. I read about a subjects that are outside of my normal expertise and work. For example, this year I read about physics, evolution, consciousness, free will and philosophy and I re-read fairytales.

I set aside time and money to keep learning. I will keep learning for the rest of my life.

‘SimBlogging‘ offers a his and hers viewpoint where Pascal and Portia timebox-blog as a pair on the same topics simultaneously

What Went Well

I finally got to see Heathrow Terminal 5, where I met up with Portia. We got an upgrade on our ticket thanks to the friendly British Airways lady at the checkin desk. A good start.

10 hours later, in Phoenix, the heat, sun, blue skies, pools, palm trees and cacti are a bit of a shock after grey, dreary and wet Brussels and London.

Our “Mirror Mirror on the Wall… Why Me?” Agile Fairytale BOF was met with enthusiasm and we kept playing the game during dinner and drinks, resulting in plenty of “Aha! moments”.

We played the “Quality vs Speed” game that looks at the tradeoff between releasing early and finding/fixing bugs. We managed to win thanks to our clear, simple and adaptive process built upon our shared team principles of “Quality AND Speed”. We might have done better if we had collaborated with the other teams, but at least we shared our process with the others. During the retrospective we discussed if the model of the game is still relevant to Agile projects. When we work with short timeboxes and give priority to DONE stories (without known bugs), the main tradeoff is one of time vs scope. And then we can apply the Business Value principles, which is another game altogether.

Several other sessions provided new learning or illustrated material I already knew:

• Experiencing the coping stances and congruence by sculpting the stances.
• Selling ideas to management (or anyone else for that matter) where we experimented with different techniques to sell ideas to a manager. I got to play the manager, which is always fun. I tried to be helpful and sympathetic to the person who came to me with their idea, but I failed to help the “seller”. Clearly, management is not as easy as it sounds.
• In the “Just Enough Leadership” session we got to experiment with the “wisdom of the crowds” to see if a team came up with better rankings. The session included collected metrics, including one measure of correlation between individual and team scores that might indicate who led the team. We didn’t go very deep into the metrics, but correlation does not mean causation. In our team, we switched leader very quickly. We led by example: someone said “Lets…” and the others followed. If you have a good idea, there isn’t any need for endless debate to come to a consensus. Go for it and see if you’re followed, because a leader is defined by their followship.

Although “I’m an Introvert”, I enjoyed the many discussions and talks with photographers, magicians, testers, jokers, would-be Evil Queens, managers, bloggers, stars and coaches from many countries that make up the audience of the AYE conference.

We ended our travels in Phoenix with a visit to the Heard Native American museum, where we learned more about the Inuit and Pueblo people with their “Katsina” and scary ogres.

Complaints with recommendations

The AYE “conference“, is a 5 day training course with 5 trainers. Either make it a conference with a set of diverse presenters who bring different perspectives or call it training.

The conference kicks off with the warmup tutorial (also known as the “Steve and Don show”) which explains the basic tools and terminology and MBTI types. Many participants wrote their MBTI type on their nametags. Is this a way to advertise “this is how I am and want to be treated”? The emphasis on MBTI types throughout the conference is a bit too strong for my taste. I see MBTI types as preferences, not something “that I am” and that can’t be changed. I would recommend:

• ensuring that there is a clear disclaimer about MBTI, that these are preferences, that this is a default that we will fall back on when we are stressed. Our MBTI type is not a fixed pattern that determines how we work and act.
• working with mixed teams, instead of by MBTI type, so that we can be more effective by exploiting the diversity of the team, one of the lessons of the “Mirror Mirror on the Wall… Why Me?” Agile Fairytale.

‘SimBlogging‘ offers a his and hers viewpoint as Pascal and Portia timebox-blog simultaneously

What Went Well

Journey to Arizona: My AYE adventure started at Terminal 5 where I met up with Pascal to fly to Phoenix, Arizona. Thanks to Julie, a Senior Customer Service Agent from British Airways, we both got upgraded to World Traveller Plus. I’ve gained considerable insight into the airline industry having worked in the industry for the past 6 months. Working with people with a passion for airplanes and travel has allowed me to experience air passenger travel with new eyes since.

Beautiful Arizona: The November weather in Arizona is glorious. The skies are a bright, clear blue and the sun simply glows. I found myself sitting outdoors in shortsleeves, basking in the shade to avoid being burnt to a crisp. Now that’s something that’s never happened to me before. Another striking thing about Arizona is the strips of carefully tended green grass. Back in London, it rains a lot by comparison and so the grass is mostly green. Here in Arizona, I find myself scanning the landscape for grass and appreciating each strip because I know someone decided to plant it there and have continued to look after it since.

The Folks at AYE: My biggest takeway from AYE is the high concentration of open and friendly participants. The number of participants was capped to 75 which gave us a chance to really mingle with the 5 organiser-trainers, Don Gray, Steve Smith, Esther Derby, Johanna Rothman and, of course, Jerry Weinberg. Most important of all, the smaller-than-average conference gathering gave the participants a chance to get to know one another better.

Agile Fairytales at AYE: Following on from Don’s friendly suggestion that we run the Snow White and Seven Dwarves Kanban Game as a Birds-of-a-Feather session at the conference, over 23 people attended the session. Pascal and I continued to play the game with other participants over the course of the conference after lunch and during dessert. It goes to show that playing at the dinner table is no bad thing!

People, People, People: For me, going to a conference is all about meeting people. My write-home-on-a-postcard characters have to be: Evan the Standup Comedian (who played a key role as the protagonist in the chaotic, yet triumphant Satir Change Model exercise), Jeremy the Magician (with his scented marker and chameleon playing cards), Chris the Aspiring Dog Whisperer (with understands dogs AND people) and Cheryl, Rob and Mark from Team Blackberry (who get to develop funky tools to help us better manage our time and ourselves).

Session Highlights:

• Go for Quality, Go for Speed: a simple yet thought-provoking game invented by Jerry based on iterating over a bag of marbles (representing a codebase) to see which team would get rid of the black marbles (bugs) to deliver a bag full of clear marbles (good code). As an observer, it was reassuring to see that the winning team’s iterative inspect-adapt approach helped achieve Quality AND Speed. Hurrah!
• Other sessions I enjoyed and learned from include: Choosing the Right Coaching Approach: Congruent Coaching, How do You Feel About Change? Experience the Satir Change Model and Just Enough Leadership.

Cultural Day Out: Of course, no conference adventure is complete without a visit to the environs. On our last day in Phoenix, Pascal and I visited the Heard Museum where we learned about the different Indian tribes in the Arizona region. We had first come across this aspect of the sad and turbulent history of America on our visit to Toronto at Agile 2008. It reminded me of the importance of learning from history because it’s only by learning from our mistakes that we stand a chance of breaking the cycle of misunderstandings and atrocities. Esther demonstrates how retrospectives are a great way of transforming our experiences into lessons learnt.

Complaints With Recommendations

• The AYE sessions I attended encouraged audience participation, but the session takeaways remained vague. It would be great to make explicit the learnings and actions from the discussions, as a group, to reinforce the lessons learnt so they can be applied more easily.
• Day 1 saw the introduction of the Myers-Briggs Indicator Type (MBTI) with everyone identifying their type. Unfortunately, some people wrote their type on their name badge and started saying things like, ‘I’m an introvert, that’s why I’m not very good at networking’. It would be more useful to emphasise a preference is just that rather than who you are. That’s because we can all learn the less preferred behaviour to become more congruent.
• The only session to hold a retrospective was the Agile Fairytale Mirror, Mirror BoF. It would be great to apply the Agile practice for all sessions as a way to get feedback from participants to help improve them.
• I wish I’d spent more time chatting and sharing with other participants outside of the sessions. I could start or continue a conversation by email of course!
• I wish I’d seen more of Arizona and its exotic fauna - nothing beats a bit of funky cacti against blue sky. I suggest hiring a car and doing a bit of a road trip next time!

Last night saw the largest gathering ever to attend Mirror, Mirror on the Wall… Why Me?, an Agile Fairytale session on improving personal effectiveness, created by adults for everyone. More than 20 people converged to learn how to create their own happy endings on Day 2 of the AYE Conference in sunny Phoenix, Arizona.

Rediscovering the lessons we learnt as children but have since forgotten

We began the session with a speed retelling of Snow White and the Seven Dwarves - a story of murder, intrigue, passion, poisoned apples and, of course, an Evil Queen. It was great to see sceptic-looking faces brighten with smiles as the story unfolded. The room soon filled with laughter at the thought of Sneezy being a friendly kind of dwarf who’s creatively efficient because he’s allergic to work.

You can read more about the Snow White and Seven Dwarves Kanban game here. The game and all related materials are freely available under the Creative Commons license. You can also download the game and play it for free* with your team, family and friends.

If you’re an avid Agile Fairytale game player, you can read about the experience of your British Agile Fairytale counterparts and see how they fared.

Making Money with Agile Fairytale Projects

The highlight of the evening had to be the project pitches as each of the three teams presented their project proposition, outlining their project’s goal, its deadline and a team staffed with Agile Fairytale characters.

Mirror, Mirror on the Wall… Who’s the fairest of them all?

Many thanks to everyone who attended! The overwhelming enthusiasm of the participants was a sure sign that Pascal and I were among folks who take responsibility for ourselves by continuously seeking to improve.

Heartfelt Lessons Learnt by the Group

• The only person we can change is ourselves.
• Everyone has value.
• Stop being a misanthrope: we should appreciate people more.
• By looking at what we think of others, we can learn about ourselves.
• It’s up to us as individuals to take responsibility in a relationship.

One participant declared, ‘I can see how the game can be a catalyst for team building. I’m going to play it with my team the moment I get home!’

Agile Fairytales coming to a place near you

Mirror, Mirror on the Wall… Why Me? will be showing next at XP Days Benelux later on this month. The Agile Benelux contingent are world-renowned for their sense of fun, so I’m looking forward to what promises to be a most excellent European mini-adventure of self-discovery.

*The Snow White and Seven Dwarves Kanban game is licensed under the Creative Commons Attribution-Share Alike 2.0 UK license.

A simple question

Agile Coach: How do you define “professional”? What is a professional?

P: Erm… I don’t know.

Agile Coach: Then how can you know if you are one?

P: (Embarassed silence. Then) Let me think about it and I’ll have the answer by next week. Is that ok for you?

Agile Coach: Yes, that would be very professional of you.

What is the acceptance test for “a professional”? How can we recognise one? What are the essential characteristics of a professional?

Acceptance criteria #1: A professional takes responsibility

If I see it, I own it: I’m responsible for resolving issues

If we see the world as it really is, and not as we want to see it, we can’t fail to see problems. A problem is the difference between the way the world is and the way we want to see it.

Responsibility is the way we respond to a problem. Responsibility isn’t given; it’s taken. Taking responsibility means we make the choice to do something about the problem. Responsibility means taking action to bring the world a step closer to how we want to see it.

No one else is going to solve my problems for me.

I can do it: I’m responsible for my work and my skills

If I take responsibility for doing something then I’m responsible for doing it well. To do it well, I’m responsible for ensuring that I have the necessary skills or enlist help from people with the right skills. I’m also responsible for my learning and growth.

No one else is going to manage my life and career for me.

We made this: I’m responsible for the results of the team

We succeed and fail as teams. It’s no good if my part of the work is done, but the whole isn’t done. If I see a problem with teamwork, I’m responsible for solving it. I expect and trust my fellow team members to take responsibility.

No one else is going to solve our problems for us.

Where does it stop? I take responsibility one level up

How far do I need to go? I can’t be responsible for the whole world. A good rule of thumb is to look “one level up”, go one level higher than the level I normally work at. For example, if I’m a programmer I will take responsibility for my code *and* for the code that my team produces. If I see a problem with team code, I’m responsible for solving it.

No one else is going to determine how far I need to take responsibility.

But it takes more than that to be a professional

Watch this space.

Playing the Business Value Game is serious fun

Goodbye Helsinki

What others think

Doing a standup retrospective with 60+ people.

Let me know if you wrote about the Business Value Game or took pictures of the event.

Playing to learn about the Theory of Constraints

It’s 5 pm on a Thursday night and everything’s already pitch dark outside. We need at least 7 players to play the Bottleneck Game created by Pascal Van Cauwenberghe but we only have 6 eager participants. Being an Agile Coach has taught me to be resourceful (think Macgyver), so I roam the corridors for a couple more minutes in the hope of netting a few Agile enthusiasts keen to learn a thing or two about process improvement and bottlenecks.

To my surprise, I don’t just find one, but two volunteers: Darren and Paul. Both Darren and Paul have been extremely helpful and supportive with our fledgling Agile teams to date. I’m glad the promise of an Agile game and Halloween chocolates prove more enticing than a visit to the gym. It’s also a sign that I’m working with a learning organisation.

Favour Brain over Brawn

The Bottleneck Game (also known as ‘I’m Not a Bottleneck, I’m a Free Man!’ teaches us about the Theory of Constraints (TOC). According to the Theory of Constraints, every organisation has at least one constraint which limits the system’s performance in terms of it’s goal. The theory states that we can improve a system’s throughput learning how to recognise and deal with a system’s constraint (also known as a bottleneck).

The 5 Focussing Steps

Step 0: Make the goal of the system explicit.
Step 1: Find the constraint.
Step 2: Exploit the constraint.
Step 3: Subordinate everything to the constraint.
Step 4: Elevate the constraint.
Step 5: Rinse and repeat.

Lessons We Learnt Today

• If you’re rushing, you’re probably stressed - slow down instead and you’ll improve your quality as well as increase your throughput
• Apply improvement changes one at a time
• Always measure the throughput before and after applying improvements to verify their effects on the system
• Cross-training helps improve the throughput of a team
• Small, incremental changes can make a big difference to throughput.

Process Improvement is the New Sliced Bread

Don’t let inertia become the constraint. Help your team and your organisation become more agile by striving to be a bit better than you were yesterday every day. Thanks to Alison, Suresh, Bhavna, Paul, Mark, Darren, Jo and Genevieve for being such professionals as employees of The Boats and Hats Company!

The Theory of Constraints is clearly a hot topic as Pascal’s also run the game with one of his clients over in Paris. You can read a more comprehensive account of the Bottleneck Game as played by our French Agilista counterparts here.

Learn About Bottlenecks with Your Friends and Family

Origami isn’t just for work, it’s for learning, too! The “I’m not a Bottleneck! I’m a Free Man!” game by Pascal Van Cauwenberghe and Portia Tung is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.

Good morning Helsinki

I flew into gray and rainy Helsinki yesterday and met up with Willem and Marc to go to Helsinki Marina, where the first Scandinavian Agile conference will be held. This is the first edition of the conference and they are already sold out with 250 participants. The night before the conference, organizers and speakers have discussions, dinner and drinks. Not too many drinks, because I have to “work” tomorrow: in the afternoon Markus, Marko and I will run a Business Value Game.

Morning sessions

The day kicks off with a keynote by Gabrielle Benefield about the introduction of Scrum in Yahoo. Many of the lessons learned sound very familiar:

• Go deep Agile with a few of the most important teams, rather than spread Agile thinly over a lot of teams.
• Technical excellence, attention to quality and good engineering practices are essential.
• Grow slowly with teams that volunteer. Don’t overstretch your coach capacity.
• Involve management. Inform, address fears and explain “what’s in it for them”.
• There will always be people who don’t like or want Agile.
• Don’t just change the process; change the structure of the company.
• Bribe people with snacks.

Next up is Bjarte Bogsnes‘ session called “A journey beyond budgeting - because the future ain’t what it used to be”. The talk is about budgeting and management at Statoil Hydro and several other companies. The key principles of “Beyond Budgeting” are

• Performance is about outperforming peers.
• Do the right thing based on values, principles and sound business judgement.
• Resources are allocated case-by case. No big-bang budget allocation process once a year.
• Business follow up is forward looking and action-oriented.
• Performance evaluation is a holistic assessment of delivery and behaviour. Did we get the right results in the right way?

Traditional budgeting ties three activities together: forecasting, setting targets and resource allocation. There will always be conflicts among these activities. Statoil separates the three. A forecast is not a target or commitment. A forecast is a call to action, it gets issues on the radar screen as soon as possible.

Designing KPIs that reward correct behaviour is hard. Statoil uses two principles: connect input with output (what’s the yield in new oild fields vs eploration cost?) and compare with others (where is Statoil in the “league table” of oil companies?). Individual goals and bonuses can skew behaviour, so use with caution.

The whole model is based on trust and regular follow up. It seems this provides a budgeting and management model that is compatible with Agile values and principles. Except for the individual goals and bonuses…

More info on the Beyond Budgeting Roundtable.

Next, Lasse Koskela and Jukka Lindström hold a mock-debate between Scrum Iterations and “iteration-less” Kanban.

Afternoon

The Business Value Game is up next. I’ve prepared 7 sets of game props. With 6-7 people per team, we should be able to accomodate up to 50 participants. More than 60 people turn up. I’ve never run the game with so many teams and so many people. Luckily Markus and Marko are ready to help after a crash course in Business Value Game coaching.

The first two rounds, where I explain how the game works and the teams learn to work together, are noisy and difficult to control with so many people. Gradually, people learn to work together and they work more and more effectively. After every two iterations we hold a short standup retrospective to share lessons learned between the teams. At the end of the game participants reflect on how their company prioritises (or fails to prioritise) projects. At the end there are lots of smiling faces and people ask for more information about this and other games. Have a look on my site for a partial list of games. There are more to come. All of those games are available with a Creative Commons license. Download them, customize them, play them and let us know what happened and how we can improve the games.

Evening

The day ends with a panel discussion about “Agile in Scandinavia”. Most of the questions and issues sound very familiar are are not specific to Scandinavia.

The conference ends with drinks, snacks and conversations.

The conference is a real success with so many people for a first organisation. Well done Agile Finland!

Today’s a special day for my team: we’ve got one more day before our Iteration 1 Show & Tell and, of course, it’s Diwali, the Hindu festival of light. During the second part of our standup this morning (what we call ‘Information Broadcast’ where we share useful information among the team outside of the 3 usual three questions answered in a standup), I’m told that everyone will be praying to Lakshmi, the goddess of wealth and prosperity. It’s natural to want a share of good fortune, so I ask by way of a reminder: ‘Will anyone be praying for us to reach a burndown of 0 story points by Thursday morning?’ And everyone laughs.

This is Day 18 with my team and I’ve learned many things from them including some Agile lingo in Hindi:

• Grahak means Customer
• Sahayog means Collaboration
• S’mmaan means Respect

How did I come across such useful learnings? It’s thanks to one of the first team exercises we did: translating the team’s values as well as the Agile Values into Hindi. Seeing the team tackle that translation exercise is one of the most memorable events I’ll be taking with me when the time comes to move on to my next Agile team. I hope the translation exercise will somehow help Agile endure.

Off to Amsterdam

Vera and I travelled to Amsterdam to play the Business Value Game at the first Agile Holland Conference in Amsterdam. The one day conference was set in the “Montessori College Oost“, a school with a very distinctive architecture.

In the train to Amsterdam we started the development of a new training workshop on discovering, hunting and fishing for User Stories. The Stories are out there, but they’re not easy to catch. Fortunately, there are some simple techniques we can use to get on the right track. Unfortunately, explaining simple ideas is very hard.

Money, money, money

When we arrived, Martien van Steenbergen was already explaining participants how to play the “Serious Crazy Money Game“. Players had to buy and sell products from each other during the day as way to get to meet new people and learn something about value, trust and cooperation. The XP Game and the Business Value Game were among the products. We had come to give away the Business Value Game.

Business Value Game

Three teams of 6-7 people competed to play the new Business Value Game v1.1. You can see from the pictures that they have this combination of total concentration and immersion with fun that characterizes learning moments.

Becoming a team

The first two rounds took a long time: we need to explain the rules and techniques and the group of strangers needs to become a team. After two iterations we held a standup retrospective to share what each team had learned, which strategies they were using and to resolve issues. After the retro, there was a coffee break.

Back from the coffee break, the teams started to work faster. Whereas the first two iterations and the retrospective take 45 minutes, the next two iterations have to be completed in 15 minutes total. Despite the time pressure and the will to win, the players stuck to the Agile values of Communication and Collaboration. Even when we tried to divise the team by giving chocolate bonuses to the “account managers” who managed to get “their customer’s” projects released, the players kept looking at the whole. They prioritised in the interests of the whole team. Some account managers even chose chocolate bonuses that they could share with the rest of the team.

Most of the teams didn’t notice the “small print”: some of the customer requests have extra conditions or information that have a large impact on the team’s decisions. We had to remind the players to look at customer’s request carefully and to ask us for more information.

Lessons learned

And what have we learned today? Amongst others:

• Carefully read and ask what the customer really means and really wants. “Don’t guess! Ask.”
• The economic benefit of releasing sooner.
• Business Value is primarily useful on Epic level, less on User Story level. In some cases, looking at the business value of individual stories helps us to prioritize stories.
• The difference between iterations and releases. The difference between iteration planning and release planning.
• The difference between potential value, features developed but not released, and actual value, features released, deployed and paid for.

For me, the lesson of the Business Value Game can be summarized as follows:

Business Value is not a value.

Business Value is a function.

Business Value is a function of what you value.

Too often, prioritisation or selection of projects is done by “gut feeling”. When we introduce Business Value, we start a conversation about values. Which factors will we take into account when we prioritise?

• How much money we can make in the short term?
• How much money we expect to make in the long term?
• How (un)happy a customer is?
• How hard the customer shouts?
• How much we like the customer?
• How well the customer knows our CEO?
• The size of the bonus for the salesperson who sold the project?
• How late the project is?
• Constraints?
• Deadlines?
• How (un)happy our team is?
• The capacity of our team?
• Strategic objectives?
• ….

That’s the conversation the teams have during the first iterations. Once they know the factors they value and the weight of the factors, they can prioritise effectively.

How do you prioritise your projects? What does that say about your values?

---

Do you want to learn about “Business Value”, prioritising your backlog, portfolio management and all the challenges that salespeople and account managers face daily? Do you want to experience the benefits of working with short iterations and releasing early? Do you want have fun while you learn? Download the Business Value Game, print the cards and organise your own game.

The Business Value Game by Vera Peeters and Pascal Van Cauwenberghe is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.

Or come and play the Business Value Game at:

• The Scandinavian Agile Conference in Helsinki, Finland on October 29th, 2008
• The XP Days Benelux in Eindhoven, The Netherlands on November 20-21, 2008

Bottlenecks in Paris

This week I was in Paris to host an “I’m not a Bottleneck! I’m a Free Man!” or “A l’aide! Mon Processus m’étrangle!” workshop to help a company to apply the Theory of Constraints.

The workshop is fun and playful. We simulated a team making paper hats and boats. The team got paid in Belgian chocolates. Participants enjoyed learning about The Theory of Constraints. In the retrospective, most participants noted that they liked the relaxed atmosphere, the fun way of learning and the friendly cooperation.

And yet, there were a few moments where the participants felt uncomfortable and voiced their disagreement with the material.

Say NO to the exploitation of bottlenecks!

Step 2 of the “Five Focusing Steps” tells us to exploit the bottleneck. As the throughput of the system is determined by the throughput of the bottleneck, we need to do everything we can to increase the throughput of the bottleneck. We need to get as much value out of the bottleneck as possible.

When I asked the participants how we could exploit the bottleneck in the game, many people bristled at the suggestion. They felt I was trying to ’squeeze’ the unfortunate worker who was (by design) the bottleneck of the game. To them, this smacked of “Taylorism” or “Fordism“.

It took some convincing and explaining to get the participants to look for ways to exploit their overworked, stressed and sweating colleague. Adding more people seemed like a simpler and more powerful improvement technique.

Go on, exploit the bottleneck! It’s just a game.

Now, what did the team come up with to get more output from the bottleneck? How did we make the bottlenecks in the game and in the real processes more productive?

• Ensure that there’s a small buffer of work in front of the bottleneck, so that the bottleneck is never idle due to lack of input. Install a ‘pull’ system so that whatever the bottleneck needs arrives just-in-time when the bottleneck needs it.
• Reduce interruptions, so that the bottleneck can stay concentrated on their task and get into the “Flow state“.
• Reduce task switching. Finish each task before starting on another. Focus on the task at hand and don’t worry about upcoming tasks.
• Prioritise the work to be done by the bottleneck, so that they always work on the task that brings the most value.
• Reduce waste in the bottleneck’s work, so that the bottleneck doesn’t spend time on non-value adding work.
• Ensure that the inputs and tools of the bottleneck are of the highest quality so that they don’t waste their time finding and correcting errors or dealing with machine breakdowns.
• Even out the workload (Heijunka) to combat the waste of unevenness (Mura) and overburdening (Muri)

At the end of the day, each team had several exploitation ideas that they could work out the next day. Exploiting the bottleneck is usually quite easy as it doesn’t require investment and doesn’t involve many people.

And yet, these simple changes can add a lot of value. For example, we recently almost doubled the productivity of a development team by installing some simple measures to reduce interruptions and by prioritising work better so that there was less task switching.

If that’s what “being exploited” means, you can exploit me too!

The result of all that exploiting? A bottleneck that’s less stressed and less overworked and yet has higher productivity. A bottleneck that can concentrate on their job without all those energy-sapping distractions and wastes. In their final retrospective, the team that doubled their productivity noted that this project was a lot less stressful than their usual projects.

Participants in the workshop learned that there are better, easier and cheaper ways to improve processes than to add more people. They learned that “exploiting” in the Theory of Constraints is very beneficial to the bottleneck, despite the negative connotations of the word.

Would a “softer” word have helped? Would another word evoke less resistance? I used to think so. Now, I think that we need to go through that resistance that the word exploit evokes. If we let the participants of the workshop optimise the game’s process on their own, they will probably get no further than throwing more bodies at the problem. The Theory of Constraints is simple, but its consequences are counter-intuitive. By dealing with the resistance to the idea early, participants learn to break through their existing patterns. Having seen Eli Goldratt in action, I appreciate he’s no proponent of the “softly, softly” approach.

And it gets better

After participants have accepted the exploit step, we move on to “Subordinate every other decision to the bottleneck”, which leads to another set of counter-intuitive ideas. For example, the participants learned that they could get more output from their processes by slowing down certain people.

Resistance in Amsterdam

Lean has another set of counter-intuitive yet effective ideas. On Friday, the suggestion that “Standardized Work” could be useful in IT was met with strong resistance by participants of the Agile Holland conference. More about that later.

I’m starting to enjoy resistance. In my experience, resistance from myself and others means that we’re on the right way, that we’re trying to do something different. Because if we want to get a different result, we will have to do something different.

What have you resisted this week? Now imagine that the thing you resist is not your enemy but your friend. What would the world look like if that were true?

---

You can download the Bottleneck Game from the Agile Coach site.

The “I’m not a Bottleneck! I’m a Free Man!” game by Pascal Van Cauwenberghe and Portia Tung is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.

Image courtesy of ‘Freedom Toast‘, licensed Creative Commons, Attribution Non-Commercial.

Reader to Writer - Yet another comic Agile moment

M: I’ve read your blog.
P: What do you think about it?
M: I’m not sure if I’ve got the right word for it. (Long pause)
P: Go on.
M: What I like about it is that I can tell you’re obsessive about what you do.
P: (Stunned silence. Then) Thank you for the feedback.

Just Blog It!

To be a blogger, you have to blog. Here’s how to create a blog in less time than it takes to order a beer in a crowded saloon on a Friday night:

1. Ask yourself: ‘What are my interests or reasons for blogging?’ Write down each thought or idea on a separate mini Post-it. [3 mins]
2. Review each Post-it by thinking out loud and elaborating on the reasons why you wrote it down. [5 mins]
3. Pick the Post-it that makes you feel most energised just thinking about it. This forms the ‘hook’ that will keep you writing as well as attract visitors to your blog. Let’s call this the Hook Post-it. [1 min]
4. Talk about the Hook Post-it some more. After all, it’s special. Why does it make you feel energised? Where did you first come across the thought or idea? Why’s it important to you? [2 mins]
5. Pick one or two or three coherent words associated with your Hook Post-it. Congratulations! You now have the title and theme for your blog. [1 min]
6. Select a free blog provider - for instance, www.blogger.com or www.wordpress.com. (I prefer using wordpress because it generates cleaner HTML markup than blogger. Cleaner HTML means a better reading experience for your readers who use feed readers.) [1 min]
7. Register with your chosen blog provider. [1 min]
8. Create a blog with your chosen title. Congratulations again! You’re now the proud owner of your very own blog. [2 mins]
9. Select a particular thought or idea related to your Hook Post-it. Write a sentence or two about it. Don’t overthink it. Just keep writing. [5 mins]
10. Review and preview what you’ve written. [2 mins]
11. Publish it! [5 secs]
12. Send your friends the link to your blog and ask them for feedback. [1 min]

Nice To Haves

• Add tracking to your blog so that you can see how many visitors you get and where they come from. Google Analytics provides pretty, graphical data. The statistics will spur you on to write some more. If you’re using wordpress, go to Dashboard | Blog Stats (which uses Google Analytics behind the scenes).
• Why not buy your own domain name? These days, a domain name is cheap as chips and you can get website and email forwarding for free so you can impress your friends with a personalised email address. If you want to remove ‘wordpress’ from your blog URL, you can buy the domain name and full mapping from wordpress themselves.

To blog or not to blog

If you’re still unsure, begin by asking yourself: ‘What’s in it for me?‘

If I could only attend one Agile conference this year, it would have to be XP Days Benelux 2008 because:

1. It’s created by Agilistas for Agilistas.
2. It attracts genuine practitioners of Agile.
3. It’s organised in an Agile way.
4. First time speakers are given priority over more well-known or experienced presenters to encourage knowledge and experience sharing within the Agile community.
5. Presenters mingle 100% with participants beginning with the conference opening dinner.
6. The Games Night promises to be V. SPECIAL.
7. Everyone understands that the most effective learning and innovation comes from having fun.

The tickets are selling like hot cakes, so buy yours soon if you enjoy hunting werewolves while sipping beers brewed by Dutch monks!

My Top Picks

Presenters I’ve met and heard lots about, but have yet to see in action:

• The Best Way to Introduce Agile by Nicole Belilos
• Agile Metrics by Dave Nicolette

Sessions that look especially intriguing:

• Critical Chain by Christophe Thibault and Olivier Pizzato
• Coaching Self-Organising Teams by Joseph Pelrine and Ben Fuchs
• Both sides of the story! Go out and motivate people to make exciting changes by Gino Marckx and Bernard Vander Beken - I helped out with the 9 Boxes presented by Bernard and Pascal at XPDay France earlier this year. No doubt Gino and Bernard are a combo to be seen to be believed!

Sessions I’m looking forward to co-presenting:

• Mirror, Mirror on the Wall… Why Me? - Pascal and I will be presenting this at a conference for the third time this year and it just gets more and more fun!
• The Business Value Game by Vera and Pascal - My first ever conference was XPDay London 2004 where I played the XP Game run by Vera and Pascal. It’s a real honour to be co-presenting with these two!

‘Exoftware has been ranked 6th in the 2008 Deloitte Technology Fast 50, a ranking of the 50 fastest growing technology companies in Ireland. Rankings are based on average percentage revenue growth over five years. Exoftware grew over 1300% percent during this period.’

- Deloitte Ireland

One of the hardest things about becoming agile, both for the organisation and for the individual, is that Agile challenges parts of your brain other project delivery methodologies don’t reach.

Continuous Improvement is a tough job, but someone’s got to do it

I’ve gained an incredible amount of insight and experience by working at Exoftware as an Agile Coach since January. One of the things I love most about my job is the fact that I’ll always be learning. After all, continuous learning is the only chance we have of improving ourselves.

What Makes Exoftware Special

I’ve worked for a number of organisations, both large and small over the past decade, and Exoftware’s different for 5 key reasons:

1. Exoftware walks the talk: We strive to apply the Agile Values of Communication, Simplicity, Feedback, Courage and Respect, with our customers and among ourselves.
2. Exoftware acts with integrity: We tell it like it is even if the message isn’t easy to deliver or receive.
3. Exoftware’s a learning organisation: We understand that success is defined by continuous improvement. The best learning comes from making mistakes, so we fail early as well as pool the experiences of our coaches.
4. Exoftware creates an environment where we can be courageous: Everyone who works for Exoftware is part of the same team. Our clients are an extension of that team. We’re stronger because we work together.
5. Exoftware really cares: We continuously improve because we care about what we do. That’s because we’re in the People business.

Business Value Game v1.1

Thanks to the feedback and ideas playing v1.0, Vera and I have released an update of the Business Value Game.

What’s changed?

• The session description contains more examples and explanation to fill in the iteration score sheet.
• Some corrections to the text in the manual.
• Client cards can be folded to stand up for extra clarity.
• Rebalanced the process improvement cards to make process improvement more attractive.
• Story cards are numbered to make it easier to see if all cards are available.
• Pictures of the game being played, by Portia Tung.

There are no major changes, this is mostly fine-tuning of gameplay. We have lots of ideas for challenging prioritisation cases. To incorporate all those ideas we’ll have to make a 9 iteration version of the game.

Go out and play!

Do you want to learn about “Business Value”, prioritising your backlog, portfolio management and all the challenges that salespeople and account managers face daily? Do you want to experience the benefits of working with short iterations and releasing early? Do you want have fun while you learn? Download the Business Value Game, print the cards and organise your own game.

The Business Value Game by Vera Peeters and Pascal Van Cauwenberghe is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.

At an Agile Conference

Agilista: A top Agile presenter always has a ‘thing’.
P.: Really? Like some kind of disease perhaps?
Agilista: (Rolls his eyes) No, something that makes them special.
P.: Ah. (Long pause) I tell Agile Fairytales.
Agilista: I’m being serious you know.
P.: So am I.

---

Agile Fairytales Hits the Mainstream

This Tuesday evening marked another of Agile Firsts. It was the first time for me to run an Agile Fairytale on client site. Agile Fairytales helps us remember the lessons we learned as children but have since forgotten. Who knows? Perhaps this event heralds the start of Agile Fairytales going mainstream after its first appearance at XPDay London 2007.

A Laugh a Minute

Fifteen of us bundled into a sleek, glass-walled meeting room to transform it only moments later into the play space for Mirror, Mirror on the Wall… Why Me? You can read more about the Snow White and Seven Dwarves Kanban game here. You can also download the game and play it for free* with your team, family and friends.

Having Fun is Serious Work

Many of the participants described the session as fun and full of laughter. The highlight for everyone was the chance to mingle with colleagues we had never met before, tasked with assembling a project team with a tangible goal and deadline. And the twist? We had to staff our projects with Snow White and the Seven Dwarves, all the time leveraging their strengths, recognising the value everyone brings to a team, warts and all.

And they all lived happily ever after…

Many thanks to the game players for their invaluable session feedback in exchange for Haribo Tangfastics and marshmallows. “Thanks!” to Natasha, Graham, Jo, Bhavna, Lissa, Ashutosh, Neeraj, Bruce, Chi, Nick, Ponvizhi, Sanjeev, Suresh and, of course, Andy.

Agile Fairytales Coming to a Place Near You

If you want to learn how to become a more effective team player and team builder, come play The Snow White and Seven Dwarves Kanban Game at AYE and XPDays Benelux. I look forward to seeing you there!

*The Snow White and Seven Dwarves Kanban game is licensed under the Creative Commons Attribution-Share Alike 2.0 UK license.