Q: What has a value, an expiry condition and if you choose to exercise it early you must know why?
A: A Real Option of course!

“Commitment”, the long awaited book on Real Options, is out!

Congratulations to Olav Maassen, Chris Matts and Chris Geary on their graphic novel. It’s a marvellous work of art, knowledge and storytelling! It’s great to see the theory explained in such an engaging, lucid, succinct and fun way.

The most impressive 2 things of all about the book (and there are so many), is the rate of information transmitted by the authors and the amount of information recalled by the reader long after they’ve reached the end of the tale.

“Commitment” is a great example of the saying, “A picture is worth a thousand words”. Never have I read a book that gives the reader so much useful information at a glance and sticks in the mind and can be applied immediately.

So what’s reading “Commitment” worth to you? You can wait to borrow a friend’s copy or buy your own (it’s also available as a Kindle version). The quicker you learn about Real Options, the earlier you can apply it at work and at home, the better you’ll be at handling uncertainty to achieve better outcomes.

Happy decision making!

“We have always had as much time as we have ever had. No more, no less.” – Anon.

In the modern life of daily hustle and bustle, of striving, failing and achieving, we are prone to forget vital things. One of them is this: Time is the most precious asset we have.

Imagine life as a finite timebox. We have as much of it as we have ever had. When the bell tolls, the size of the timebox isn’t open for negotiation.

Instead of thinking yourself time-poor, think of yourself as time-rich. Distinguish between a want and a need. Now how would you choose to invest life time?

And if you haven’t already, see “The Odd Story of Timothy Green“. It’s a story about life, love and living. It’ll really make you think.

Performing a Root Cause Analysis for a simple bug takes too much time

In a previous post I described how we performed a root cause analysis for a simple bug: one incorrect value  in a dropdown. Performing such a heavy analysis (which generates a lot of rework) may not be appropriate for every bug.

Here’s how another team handled a very similar bug: one value missing from a dropdown.

The fast way to deal with simple bugs

• There’s a bug: in one screen one of the dropdowns misses one value: “X”. This bug is unexpected: in all other screens the behaviour of the dropdowns is correct, each of them contains “X” as the final and default value. This bug only appears in one screen. Why only this screen? What’s so special about this screen? Isn’t this the same code for all dropdowns with the same behaviour?
• The bug is reported during internal testing. The bug can be repeated very easily.
• Developers grumble (I told you the “Thank you” step in the  algorithm to write perfect code was difficult!)
• A developer takes the bug and fixes it: an extra value “X” is added to the dropdown in the screen
• Tester validates: go into the screen; open the dropdown; the value “X” is there. Bug closed.
• Software gets shipped to customer
• Done. Next bug!

Easy.

A few days later…

• Customer files a bug report: each time they enter this specific screen an “X” gets added to the dropdown. Enter the screen twice, you see “X” “X”. Enter again, you see “X” “X” “X”. And so on…
• Developers grumble: “Not another stupid bugreport!“
• A developer takes the bug and analyses it. “Some idiot has added ‘X’ to this dropdown. Let’s remove that.“
• Tester validates: go into the screen; open the dropdown; no “X” is added. Bug closed.
• Software gets shipped to customer
• Done. Next bug!

Easy. Only took a few minutes to fix and (a few days later) a few minutes to test. And another release to build, ship and install.

A few days later…

• Customer reopens their bug report: when they enter the screen, there is no “X”. To be clear: they expect exactly one “X” in this dropdown (and all similar dropdowns in other screens). Not zero. Not an infinite number.
• Developers grumble. “When will they make up their mind?“
• Developer takes the bug and fixes it: an “X” is added to the dropdown unless there’s already an “X” in the dropdown
• Tester validates: go into the screen, one “X”; go into the screen again, still one “X”; go into the screen again, still one “X”; go into other screens; go into this screen, still one “X”. Stop the application. Restart the application. Go into the screen, one “X”; go into the screen again, still one “X”. Bug closed.
• Software gets shipped to customer
• Done

Easy. Only took an hour or two to fix and (a few days later) an hour to test. And another release to build, ship and install.

And they all lived happily ever after

Except for the customer who grumbles “how can I trust them with the important stuff if they can’t get the simple stuff right?”

Except for the developers who grumble “how can we get any work done if we have to keep fixing these stupid bugs?”

Except for the testers who grumble “why do we have to retest every bugfix a thousand times? Can’t ‘they’ get things right the first time? We need fewer releases, more detailed specs, more elaborate test scripts, more time to test and, above all, a lot more testers to get any quality in this application.“

I’ve been going on a bit lately about the value I get from of performing “Root Cause Analysis” when I encounter a bug.

A simple algorithm to write perfect code

You don’t have to watch the presentation. The message is this: each time there’s a bug:

1. Someone finds a problem and reports it to you
2. Thank the reporter
3. Reproduce the problem
4. Add (at least) one failing test
5. Correct the problem
6. Rerun all tests and correct your correction until the tests pass
7. Improve your tests
8. Improve the way you write tests
9. Look for similar problems. Goto 2
10. Make this type of problem impossible
11. Perform the actions that were identified during the Root Cause Analysis

 But that’s just common sense!

We’re all agile lean continuously improving test driven extreme programmers, aren’t we? Doesn’t everybody do this?

Yes… but…

• It takes too much time
• We can’t do this for every bug because we’ve got too many bugs
• We don’t want to waste time on bugs, we prefer to spend time adding valuable features
• As Dijkstra said: “ program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.”
• <your objection here>

Just a little taste

The presentation tells the story of a team that performed a Root Cause Analysis. Here’s another team’s story:

Coach: Can we try a small Root Cause Analysis experiment?

Dev: Yes, but… we don’t have a lot of time.

Coach: Do you have one hour? We can timebox the experiment.

Dev: Sure, but… you can’t do anything useful in one hour.

Coach: Maybe you can’t; maybe we can.

Dev: ???

Coach: Have you seen any interesting bugs lately?

Dev: Well, I just fixed a bug. But it’s so trivial you won’t discover anything useful.

Coach: Thank you! Let’s see.

I love clear bug reports

First we look at the bug report:

GIVEN a swizzled foobar (*)

WHEN I change its properties

THEN I EXPECT to be offered a choice between 'A', 'B' or 'Z' for the status

BUT I'm offered 'A', 'B' or 'C'

(*) all names of domain objects have been changed to protect the innocent and the guilty

 Let’s apply the algorithm

Coach: have you thanked the reporter yet?

Dev: no…

Coach: Let’s do it now.

Dev: ok… <Calls product Manager>

Dev: Hi, I just called to thank you for reporting the bug about the property dialog of the swizzled foobar.

Product Manager: <surprised> OK…

Dev: The report was so clear the bugfix almost wrote itself. Thanks!

Product Manager: You’re welcome!

Coach: OK. We’ve now done the hardest part; Let’s do the next steps.

Next step: reproduce the problem. That’s quite easy: start up the application, select a foobar, swizzle it and open its property dialog. Look at the dropdown control for the status: it presents options ‘A’, ‘B’ and ‘C’.

Coach: We have a manual test procedure. Can we automate this test?

Dev: No. This is user-interface code. We’ve performed some experiments earlier and decided that it wasn’t worth the time and effort to create and maintain automated tests for the user interface.

Coach: OK.

Fix and Test

The fix was really simple

Buggy :

 status.add('C') ;

Fixed :

 if (foobar.swizzled()) {
   status.add('Z') ;
 } else {
   status.add('C') ;
 }

Rerun the application, perform the manual test: the correct options are now offered.

Result! Bug fixed! High Five! Job well done.

Hmmmm… The fix is indeed simple and the bug is now gone. But that IF is worrying. I’ve seen (and had to maintain) code that was riddled with IFs: each time a bug was detected, the developers added an IF for the specific conditions and expected outcomes described in the bugreport. Let’s add a post-RCA action: let’s read and discuss the ANTI-IF campaign.

Dev: You see now: this is a trivial bugfix, there’s nothing to learn here.

Coach:Maybe. We’ve only spent 10 minutes yet. Let’s see the rest of this code

Show me the code

If I take off my glasses, squint a bit and look at the code, this is what I see:

void showProperties(Foobar foobar) {

}

Red lines are user interface code, calls to the UI toolkit. Green lines are simple java, C#, ruby… UI-independent code.

Guess where the bug is… In the Green code. But we can’t test it, because we can’t test user interface code. So, that doesn’t help us.

A small step for a programmer…

We don’t have any tests, so any refactoring is going to be risky. Let’s do some simple, safe refactoring: let’s move all the Green and Red code together.

Now the code looks something like this:

void showProperties(Foobar foobar) {

}

Exactly the same code, it does exactly the same thing. What have we achieved? Nothing. Yet.

Another small step

Now that we’ve got all the green code together, what does it do? Essentially, it fills in a number of variables (like the list of values for the status), which are filled up with values to put into the UI controls.

Let’s do another small, safe refactor:

• Create a new class. I don’t have a good name yet, let’s call it “Stuff” for the moment
• Move every local variable in the green code into the Stuff class
• Create an instance of Stuff in the function
• Fill in all fields of the instance, just like you fill in the local variables

Again, nothing really changes. We’ve just collected all local variables in one object.

Our code now looks something like this.

void showProperties(Foobar foobar) {
 // GREEN
 Stuff stuff = new Stuff() ;
 stuff.status.add('A') ;
 stuff.status.add('B') ;
 if (foobar.swizzled()) {
   stuff.status.add('Z') ;
 } else {
   stuff.status.add('C') ;
 }
....
 // RED
 statusDropdown.setOptions(stuff.status) ;
}

Finally, a real refactoring

Now the code has been reorganised, we can finally do a real refactoring, still taking small steps because we’re working without a safety net.

Let’s extract the green and red code in separate methods. Our code now looks like this:

void showProperties(Foobar foobar) {
 // GREEN
 Stuff stuff = prepare(foobar) ; // TODO: find a better name
 // RED
 display(stuff) ;
}

Note to self: “Stuff” and “prepare” aren’t very descriptive. That’s probably because we don’t understand the code well enough yet. Let’s revisit naming when we understand better.

We’re now 30 minutes into the Root Cause Analysis

A giant leap for testing

Aha! We now have a method “prepare” which contains the bug AND doesn’t depend on the UI. Can we test the code now? Yes we can!

void swizzledFoobarsHaveZStatus() {
 // GIVEN a swizzled foobar
 Foobar foobar = makeAFoobarSomehow() ;
 foobar.swizzle() ;

 // WHEN I change its properties
 Stuff stuff = foobarPropertyDialog.prepare(foobar) ;

 // THEN I EXPECT to be offered a choice between 'A', 'B' or 'Z' for the status
 assertEquals(3,stuff.status.getSize()) ;
 assertEquals('A',stuff.status.get(0)) ;
 assertEquals('B',stuff.status.get(1)) ;
 assertEquals('Z',stuff.status.get(2)) ;
}

This test fails before the fix. It succeeds after the fix. We now have an automated regression test for this bug.

Improve your tests

This test raises a lot of questions:

• What if the foobar isn’t swizzled? Are the options ‘A’, ‘B’ and ‘C’ correct in this case? Should we add a test?
• Are there any other special cases for status depending on the properties of a Foobar?
• Are there any other fields that depend on the properties of the Foobar?
• Are there any other properties of the domain that are important?
• ….

This could be the start of a really great conversation with the Product Manager and testers!

Result: we’re 45 min into the RCA and we’ve written an automated regression test of that bug in supposedly untestable code.

Names

Those stupid names “Stuff” and “prepare” irritate me. Now that we’ve got automated tests for this code, we can refactor more audaciously.

What is “Stuff”? It contains the data as its shown in the View of the Foobar property dialog. It’s a ViewModel. Let’s rename it to FoobarProperties.

What does “prepare” do? It creates a FoobarProperties and stuffs values into it. What does FoobarProperties do? Nothing, it just sits there and contains these values. We might as well move the code from prepare into FoobarProperties:

void showProperties(Foobar foobar) {
 FoobarProperties properties = new FoobarProperties(foobar) ;
 display(properties) ;
}

And now the unit test becomes a unit test of FoobarProperties, a pure processing class, no longer of the mixed processing/UI class FoobarPropertyDialog:

void swizzledFoobarsHaveZStatus() {
 // GIVEN a swizzled foobar
 Foobar foobar = makeAFoobarSomehow() ;
 foobar.swizzle() ;

 // WHEN I change its properties
 FoobarProperties properties = new FoobarProperties(foobar) ;

 // THEN I EXPECT to be offered a choice between 'A', 'B' or 'Z' for the status
 assertEquals(3,properties.status.getSize()) ;
 assertEquals('A',properties.status.get(0)) ;
 assertEquals('B',properties.status.get(1)) ;
 assertEquals('Z',properties.status.get(2)) ;
}

Improve the way you test

Now that we have a unit test for FoobarProperties we can add more tests for different cases. Looking at those tests we’ll see that some properties of a Foobar are independent of its state. E.g. we always have a status ‘A’ and ‘B’. We can include those invariants in our tests. We’ll talk with the Product Manager first and together extend the testcase.

We can now see that we consider too much code as “UI code” and therefore not testable. If we separate ViewModel code from View code, we can cover more code with fast unit tests.

Look for similar bugs

Coach: are there other places in the UI where we display or change the status of a Foobar?

Dev: Yes… Maybe 3-4 screens and dialogs

Coach: Did we make the same mistake there?

Dev: Let’s quickly test the application. It would be quite embarassing if we got the same bug report for another screen…

Dev: Ooops! We made the same mistake in one other dialog. The other dialogs are OK.

Coach: Let’s note the dialog to be fixed and move on, because we’ve only got a few minutes left in our timebox and I’d like to do the next step first before fixing this bug.

Dev: What more can we do?

Make this type of problem impossible

Now, before we fix the buggy dialog, we’ll apply the same safe refactorings to make the code testable, add tests to demonstrate the bug (and serve as regression tests once the bug is fixed) and then fix the bug. If we consistently test our ViewModel code and validate our ViewModel behaviour with the Product Manager, we’re less likely to overlook certain cases.

The fact that this bug appears in some dialogs and not in others tells us that we’re looking at different code. Some code takes into account the “swizzledness” of a Foobar, some code doesn’t.

But we can do better: why is this code duplicated? Ideally, we’d want one instance of the code that decides which status options to show. Otherwise, if the rules change (or more likely, if we discover we’ve missed an existing rule) we’ll have to remember to update all the pieces of code that determine status options of a Foobar. So, once we’ve extracted and fixed the ViewModels from both our buggy Dialogs, we’ll extract the common code that determines the status options. Of course, this common code will have unit tests that verify this common behaviour.

Afterwards, we’ll do the same to the Dialogs that were implemented correctly. We can do this refactoring gradually, once the two bugs have been corrected. Ideally, we’ll do this if we have to change the code of those Dialogs anyway, to fix a bug or add a feature. Even if we don’t touch these classes, we’ll make sure we refactor them within X time, so that we don’t have to remember these “dangling” refactorings too long.

Some developers have taken the “swizzledness” into account, some haven’t. Let’s share our findings with the team and the Product Manager. We may have to organise a session to clarify some of the subtleties of our domain. Once they’re clear we can encode and document them as automated regression tests, so that we get a failing test next time we forget to take into account one of those subtleties.

 Dev: Hey, coach, your hour is up! Shall we get a coffee?

Coach: Great! Let’s step away from the keyboard

Looking back (over a cup of coffee)

What have we done in 60 minutes?

• Isolated code that contains a bug from “untestable” code
• Added an automated test that shows the bug and can be run as a regression test after the fix
• Simplified the code by separating the ViewModel from the View
• Identified a new class of testable code, the ViewModels
• Found another bug before anyone noticed
• We know how to make code testable and better factored for this type of bug
• We know how to avoid this type of problem and be ready for changes in the domain

 Looking forward

During the Root Cause Analysis we noted a number of actions to be taken. We make each of these tasks visible (for example, by adding them to the Kanban board):

• Extend the FoobarTest to cover more cases, in collaboration with the Product Manager and testers
• Test and fix the  second Foobar status bug
• Make the code that determines the allowed status values common between the two bugfixed dialogs. Validate tests with the Product Manager
• Refactor the other dialogs that display Foobar statuses so that they use the common code
• List the subtleties of the domain and organise a knowledge sharing session with the Product Manager
• Ask the team to review and discuss the ANTI-IF campaign
• Let’s read some more about ViewModel architectures. If it looks useful we’ll make this a standard way of designing our user interfaces. If we do, we’ll have to see how we transition gradually to such an architecture.

Dev: Well… I never expected so many issues and ideas to come out of a Root Cause Analysis of such a simple bugreport. Let’s hope we don’t do too many of those Root Cause Analyses, because they generate a lot of work.

Coach: ????

Dev: That was a joke, coach.  I’m sold. Now, let’s get back and fix that bug we found.

My Devoxx presentation on Real Options is now available on Slideshare:

Decisions, decisions, decisions

On Friday march 29th I’ll present a session about Real Options and other techniques to take better architectural decisions at a better moment. Billions of years of evolution have equipped us with these wonderfully irrational brains that sometimes get in the way of making good decisions. With a few simple but counter-intuitive techniques we can make our decisions a bit less stressful and more useful.

See you in Paris.

Calling All Bookworms

What better way to celebrate this Thursday than with World Book Day in the UK?

I love everything about books. Holding them, reading them, writing them, reviewing them, talking about them and re-reading them.

If you do too, then here are a few suggestions to make the most of World Book Day and beyond:

• Two Ted talks on creativity and artistry: Young-Ha Kim on “Be an artist, right now” and Elisabeth Gilbert on “Your elusive creative genius”
• Visit your favourite bookstore or one you’ve never been to before. If you’re in London, I recommend visiting Waterstone’s in Picadilly Circus or Foyles in the Royal Festival Hall where you can enjoy a good read with tasty cakes
• Read the first ever Agile Choose-Your-Own-Adventure “The Dream Team Nightmare” available on Leanpub for only a bit longer, soon to be published by Pragmatic Bookshelf
• Treat yourself or a friend to a bargain bookbag of 10 brilliant Agile books individually totalling $142.61 on offer for only $50

Happy World Book Day!

La conférence Agile France 2013 se tiendra les 23 et 24 mai 2013 dans le cadre agréable du Chalet de la Porte Jaune, près du chateau de Vincennes.

Vous avez encore jusqu’au 2 mars pour envoyer vos “pitch” pour des sessions. Il ya déjà plusieures excellentes propositions. J’envoie ma proposition dans quelques instants.

Qu’est-ce que vous attendez?

The conférence Agile France 2013 will be held on May 23rd and 24th at the lovely Chalet de la Porte Jaune, close to the chateau de Vincennes.

You have until March 2nd to send in a “pitch” for a session. We’ve already received many interesting session ideas. I’ll send my proposal in a few minutes.

What are you waiting for?

Ils sont fous, ces agilistes!

April 26th in Mechelen, Belgium

Mini XP Day reruns 12 of the best sessions from last year’s program in 3 parallel tracks. The conference takes place in Mechelen in Belgium (between Brussels and Antwerp).

There’s room for 90 participants and the conference usually sells out. So register now to ensure you don’t miss out on this great event.

Picture from the “Product Box” session at XP Days Benelux by Yves Hanoulle

22-23 March in Brussels, Belgium

Agile Open Belgium is an open space conference in the tradition of Agile Open conferences.

You determine the subjects on the program.

Join us on 22 and/or 23 March in Brussels.

Favourite Days of the Year

St Valentine’s Day has become my third favourite day of the year, the first being Christmas Day (a family and friends day) and the second being New Year’s Eve (a day to dust off those cobwebs and line up one’s mind furniture for the year ahead).

That hasn’t always been the case, of course. Growing up as an ugly duckling has meant that many a Valentine’s Day would fade into another-one-of-those-days-to-forget, year after year, for much longer than I care to remember.

Embrace Others and Yourself

And then one year, not so long ago, I decided to embrace St Valentine’s Day. Why shouldn’t I celebrate it, too? After all, we can all go to the ball just like Cinderella. If we so choose.

I’ve come to learn that the simplest way to enjoy St Valentine’s is by bringing joy to others and myself.

What does this mean? Do something nice for someone else. A simple Thank You email / note / card will suffice, telling them how much you appreciate them. If you’re feeling particularly generous, gift something to someone they cannot or rarely buy for themselves. It’s no  coincidence that flowers are the most popular gift on Valentine’s Day. And they don’t have to be only for a romantic partner. They could be for someone you love. A friend, your mum, your sister, your dad.

Remember to also do something nice for yourself. Go for that walk you’ve been meaning to for ages. Or treat yourself to a little something you’ve always wanted but never got around to getting.

So why is St Valentine’s Day my third favourite day of the year? Because it gives us a chance to express our love and appreciation for others as well as for ourselves.

Happy Valentine’s Day!

“A man never steps in the same river twice because neither the river nor the man are the same” – Gopnik with Heraclitus

From Pregnancy to Parenting

If being pregnant is like being Frodo in Lord of the Rings, then being a parent is like being Neo in The Matrix. My #1 Lesson Learned as a new parent is that my next move changes the map. Not only does this force me to constantly confront the edges of my comfort zone, it’s taught me a thing or two about a baby’s mind.

A Beautiful Mind

According to Alison Gopnik, “When we change the way we think, we also change the way thinking feels to us. When what we know changes, our experience changes, too.” It follows then that a sign of learning is that we change our minds based on the information we obtain. A mind that remains unchanging doesn’t just belong to a stubborn personality, it’s proof of a mind that has ossified. And we all know that when something stops growing it’s dying.

“Let’s play Pretend!”

If each human being is a “creation of the human imagination”, as viewed by Gopnik, then the world’s our oyster. In order to change the world around us, we need to begin with an open mind and who better to learn from than babies and children?

How much of the Unexpected do you encounter on an hourly or daily basis to keep you on your toes? Begin by watching Alison Gopnik’s talk on “What Babies Think” on Ted.com.

Miserly Wishing

Some people are stingy with their wishes. “I have only three wishes, so I must make each of them count!” they tell themselves. The result of this miserly attitude to wishing often results in wishes that barely resemble what people really, really want. And, more importantly, what they really, really need.

Meaningful Wishing

To discover what really matters to you, try answering this question from artist Candy Chang: “Before I die I want to…”

Infinite Wishing

I’ve heard tell that in the original version of the Genie in the Lamp there was no constraint on the number of wishes one could make upon setting the genie free.

Plenty More Wishes in the Sea

So go on. What do you wish for? Come up with one wish after another. And remember, when you wish upon a star, you’re a step closer towards turning that wish into a reality. After all, everything we do begins with a thought. For the lucky ones, it begins with a wish. For those who persevere, we can make our wishes come true.

Here’s wishing you a Happy 2013 and beyond!

Happy 2013 one and all!

My baby daughter was born just before Christmas. Many thanks for all your words of encouragement and wisdom on parenting to date! They’re much appreciated.

Keep the tips and advice coming as I find them super invaluable! Always learning. Always improving.

To make more of the future, we have to learn from the past. In order to learn from the past, we need to take time out to reflect. Only then can we can identify improvement actions effectively and do them. I might not like what I see when I look back but it’s always worthwhile.

WHAT WENT WELL

• Do at least one thing a day that scared me, from challenging the status quo to confronting my own incongruent behaviour
• Playmaking: I say “Play once a day to keep the doctor and priest away” – Used play to repeatedly transform conversations and situations by helping people (re-) connect with each other. Watch my talk on infoq.com
• Identify my goals and go for it: I set myself SMART goals and achieved them – including writing my first book and the first ever Agile Choose-your-Own-Adventure novel “The Dream Team Nightmare“, presenting an idea worth spreading at TEDx “Enterprise Gardening: Transforming workplaces into somewhere we belong” and growing a family of my own

WHAT WENT WRONG

• Being too judgmental: This remains one of my top flaws. While making judgment quickly is a pre-requisite for an effective consultant, it’s also a self-limiting habit, especially for a coach who wants to improve herself. Going forward, I will focus first on facts then bring in intuition and experience
• Slow to improve: In order to improve quickly, I will make every interaction a learning opportunity and apply what I’ve learned as quickly as possible to a) test its effectiveness; b) get in the practice of applying it; c) release the value of that learning
• Too much work-in-progress: I find it difficult to prioritise my workload and procrastinate when it comes to less interesting work. Instead, I will work on one thing at a time and release the value of that item as quickly as possible before starting work on another

LESSONS (RE-) LEARNED

1. Use what I know: It’s all too easy and wasteful to talk the talk without walking the walk
2. Sustainable pace: Work at a pace that allows me to think fast and/or slow as necessary so that I can do what I love well forever. Working at a sustainable pace gives me the head space to think and act more congruently
3. Be gentle with myself and others: Instead of expressing passion in terms of metaphors of violence and destruction, use nurture to help ideas and people grow
4. Try things out: Experiment and put ideas to the test in order to see if they’re any good before casting them aside; challenge assumptions
5. Help those who want to help themselves: When asked if we want to improve, most people’s answer is “Of course!”. This is often followed by inaction in spite of the individual’s initial response. Invest wisely on what, whom and how I spend my time to maximise the Return- On-Investment for everyone involved
6. Slow down to speed up: As the rabbit said, “The hurrier I go, the behinder I get”. Check out Carl Honore’s talk on Slowness on Ted.com
7. Follow my dreams: Only I am capable of realising my dreams. Figure out what they are, envision them coming true, then reverse-engineer what it’ll take to get me there and take one baby step at a time

Back to the Future

How was 2012 for you? What will you make of 2013?

Ho! Ho! Ho!

December is one of my favourite months of the year. Call me a traditionalist. I value a time when many people converge on giving, sharing and generally making that extra bit of effort in being kind towards one another.

The Christmas Challenge

While Christmas day itself can be a sizeable test of one’s personal agility, the real challenge I find is with giving the right presents. I know, I know. “There’s no right or wrong when it comes to gift giving!” I hear you say. Only there is. It’s all too easy to get things “too wrong”.

So here’s my strategy for gift giving this Christmas:

1. Be value-driven – Don’t just settle for spending money on tat. Figure out what the recipient is passionate about and values then go from there. Don’t be seduced by the sheer prettiness of shiny packaging. Believe you can find something that’s substantial and well-presented
2. Set a budget – Do this for both your overall gift budget and amount per individual. Setting a budget allows you to calculate the relative Return-On-Investment of a gift for everyone on your list and helps you distribute the joy more evenly
3. Spend time browsing – Giving a “good” (aka valuable) gift is a test of how well you know the recipient. If you’re stuck for ideas, put on your creative thinking hat and imagine what they would like. I recommend investing at least 15 minutes browsing per person or gift. Within that time box, challenge yourself to come up with at least 3 ideas to choose from before making a decision
4. Ring a friend – Ask for help. Borrow ideas. Find out what others are buying their family and friends. Remember, you can always ask recipients directly for their wish list with no obligation to buy
5. Give a gift of skill or service – What shareable special skills or interests do you have? Consider giving personal service tokens such as “This certificate qualifies you for 3 months worth of lawn mowing” or “Your child is entitled to 6 music lessons” or “This voucher gives you 3 arts and crafts sessions guaranteed to wow your friends”

Christmas doesn’t have to be commercial

If you’re still feeling “Bah! Humbug!” about Christmas, remember that commodification is in the eye of the gift giver. Imagine what a fairy godmother would give to someone you love.

Last but not least, when someone gives you a gift, you can always give the gift of gratitude.

Eight months ago, I applied for a new job as “Mum-To-Be”. My first release will be around Christmas Day, plus or minus two weeks. I’m hoping for a calm and smooth release instead of the “big bang” kind we see all too often on software projects. If the release goes well, I will be promoted to “full-time Mum” (part-timers need not apply).

“It’s a 24/7 job for life regardless of whether or not you have a day job. Are you sure you’re ready for this level of commitment and this kind of responsibility?” asked the Quiet Voice in my head to which my Heart and Mind both replied, “We’ll do our best.”

The Magical Role of Mum

Given the importance of the role of Mum (and of course the equally important role of Dad), you’d think there would be a definitive parent job description, complete with responsibilities, skills, qualifications and attributes clearly laid out and readily available to everyone.

Only it turns out that parenting is one of the most controversial topics you’ll ever stumble upon, be it in the playground or by the water cooler at work. And no such definitive parent job description exists.

A Case of the Vital Vacancy

That’s when I decide to apply my hard-learned principle of “Use what I know”. I know I want to do a good job and since motivation is key to a job well done, I look to Dan Pink’s theory on motivation (aka drive) for inspiration. According to Dan, developing and maintaining motivation requires three vital ingredients. Dan gives a compelling talk on Ted.com on the theory.

1. Autonomy – Be self-directing
2. Mastery – Improve continuously
3. Purpose – Serve something beyond our own needs

After all, life’s a marathon not a sprint. Sustaining good performance is equally as important as attaining a level of good performance in the first place.

Words from the Wise

But there’s no need to take a wannabee’s word for the real deal when it comes to parenting. Here’s what my parenting friends tell me:

“You’re going to learn at the fastest rate since you yourself was a child. Fasten your seatbelt and enjoy the ride!”

“Hope you enjoy every second! It is an amazing adventure. It won’t be easy, but it will be rewarding.”

“We’ll miss you a lot – looking forward to hearing how Agile works with kids!”

“You’re going to have more fun than you can possibly imagine!”

“Forget about 2-week sprints. Prepare for 2-hour sprints day… and night!”

“Hope the release goes according to plan!”

Generosity of Parents

Amidst the hustle bustle of city life, one of the most surprising things about parenting is how willing people are in sharing their experiences. The good, the bad and the ugly.

“When’s the baby due?” they’d ask.

“Christmas,” I’d reply. “I’d appreciate any tips or recommended reading,” I’d add.

And while not everything might make sense to me right now, I’ve learned to squirrel away their advice because there are some lessons I don’t need to learn by making costly mistakes.

Advice Worth its Weight in Gold

Here’s some of the recurring advice I hear:

• “You’ll know what to do when the time comes”
• “Trust your instinct”
• “Get as much sleep as you can now and enjoy it!”
• “If you’re calm, the baby will follow your cue”
• “Everyone will tell you their way’s the right way. Listen and do what’s right for you”
• “Spending time with my children is a conscious decision and the best one I’ve made”

Their collective wealth of experience inspires me with several thoughts:

• Be kind and gentle to yourself
• All you can do is your best and keep improving
• Sustainable pace

It seems that parenting and Agile have a great deal in common. It certainly seems like a good test of one’s personal agility. How do you put your agility to the test?

I’m Pascal, I’m a bug writer

I started writing bugs when I was 15-16 years old.

It all started innocently with some small BASIC programs on a home computer. But I soon moved on to the hard stuff: Assembler, Forth, C, LISP, Smalltalk, C++. Before I knew it I was working on products with several millions of lines of code and tens of thousands of recorded bugs.

After discovering Extreme Programming I decided to kick the habit.

I want to share with you the eleven step algorithm I used to get better.

I’m Pascal, I’m a recovering bug writer

Enjoy a scary read for free

To celebrate this Halloween, we’re giving away free downloads of The Dream Team Nightmare, the first ever Choose-Your-Own-Adventure style story about Agile for 48 hours from 30 – 31 October inclusive.

The Dream Team Nightmare is great for ghostbusters because it’s packed full of ideas of how to make friends with the ghosties and ghoulies they meet every day. Coupon code: FrightNight.

Enjoy the scary read! Read it with friends and colleagues to trigger a conversation for daring change!

What reviewers say…

Vera Peeters, software developer and co-creator of The XP Game, says:
“Portia is trying to write down stuff from her own excperience since a long time. Now she finally found her format. It’s a great idea to make it an adventure! It is different, it is playful, it makes it fun to read and read again and to study. As always, Portia will inspire you and will challenge you to think about what you are doing.”

Steve Holyer, Agile Coach, says:
“The only way to learn Agile coaching is by doing. ‘The Dream Team Nightmare’ lets you experience a week as Agile coach for the Dream Team in a “choose-your-own- adventure” style book. It’s totally fun and surprisingly like real life.”

Staffan Noteberg, author of “Pomodoro Technique Illustrated”, says:
“The Game of life is to try, learn and adapt through small and frequent experiments. Portia’s book gives you the unique opportunity to understand Agile in an experimen- tal way. The palette of problems and creative solutions, presented in this book, will surprise experienced Agile practitioners as well as new enthusiasts.”

Olaf Lewitz, Agile Coach, says:
“‘The Dream Team Nightmare’ is the most compelling and intriguing ‘business novel’ that I have read so far. The message is so well wrought into the narrative flow that you barely notice you are learning a lot. The style of making assumptions, validating them to keep track of what you learn and plan to do is that of an effective change artist. To explicitly identify options, deferring decisions to keep options open, not only makes reading this gamebook very exciting, it is also part of the method you see applied. I highly recommend this book to agile readers of all experi- ence levels. You will learn. Let Agile Adventures entertain you!”