I’m not a Bottleneck at Agile North

Agile NorthKevin Rutherford has invited Rob Westgeest and me to present our “I’m not a Bottleneck! I’m a free Man!” session at the Agile North conference. The conference is held on September 20th, 2006 at the University of Central Lancashire, Preston.

Are you local?

In his invitation, Kevin described the conference as “a local conference, for local people”. Accessibility is important. We can’t all afford the time and expense to go to international conferences in exotic places like Oulu or Minneapolis. Events like Agile North and the XP Days all around the world, bring agile conferences nearer to the people. These events are rooted in the local agile communities and feature local speakers as well as “the usual suspects”.

A Local shopPeople tend to buy from people like them. Business people will listen to consultanty types explaining the wondrous advantages of agility, but they won’t be convinced until their competitors start telling stories of their satisfied customers, increased cash flow and cost savings. Both types of speakers have their own type of credibility.

As the creepy shop owners in Royston Vasey say: “Are you local? We’re a local shop, for local people!

Talking of creepy (what’s with the ridiculous images that are totally beside the point?)… a certain “industry thought leader” is using some loaded questions in a questionnaire on his site to claim that “97% of all respondents indicated that the agile alliance needs to introduce new speakers at their conference instead of having the same speakers every single year“.

As I explained above, real life is a bit more complicated than this black and white statement. As conference organizers, we try everything we can to get new people to come and present their experiences. Real people, real companies, real problems, real stories how they applied agile techniques. Do non-agile conferences (say, those organized by analysts or on “enterprisey stuff”) have a better distribution between “incrowd” and “fresh people”?

Do members of the Agile Alliance really believe in Agile?” he wonders, because some agile bloggers don’t have trackbacks and/or comments. Subtle… Hey James, spamming your way into people’s blogs via trackbacks is not the way to start a great conversation. I allow trackbacks… when they add something to the conversation.

p.s. was that answer the only useful one out of that whole survey? What were the other results?


XP Day Benelux : Call for Sessions nearly over

The Call for Sessions of XP Day Benelux is coming to an end. Just a short time left to send in your proposals.

We’ve already received a good set of interesting proposals from presenters from several countries. Send in one ore more proposals. We welcome pair presenters. Your proposal doesn’t have to be perfect: in true agile fashion, you will get feedback and you will be able to improve your proposal, before the program committee decides on the program. Session leaders get free access to the conference.
The conference is in the lovely town of Mechelen, just north of Brussels and easy to reach by car and public transport. It’s quite likely that there will be good food and beer

See you there on 16 and 17 November 2006!


New books: agile estimating, CMMI and requirements

Some new books arrived

Agile estimation and planningAgile estimating and planning

First off, Mike Cohn’s “Agile Estimating and Planning“.

I enjoyed Mike’s previous book “User Stories Applied”, which contained a lot of useful techniques, each contained in short, practical chapters, with plenty of examples. Agile Estimation and Planning has the same structure and light writing as User Stories Applied.

This book is the perfect companion to the User Stories book: you’ve got a bunch of cards with stories, what now? Your customer wants to know how long it will take, how much it will cost, how many people it will take.

The book starts off with a discussion of the disadvantages of estimating tasks and the advantages of estimating features. Then we see some estimating techniques in “story points” or “ideal days”. I share Mike’s preference for story points: they’re simple and reflect the intrinsic difficulty of the story. Thus, I expect a story’s points to remain constant. All the other variables that influence how long it takes (the skill of the team, size of the team…) are reflected in the changing parameter of velocity: how many points we can implement in one release. The principle (which Mike attributes to Tom Poppendieck): “Estimate size (points), derive duration (man days)”.

Then comes the other important point: planning by customer value. Mike describes how the customer can estimate value and prioritize stories, including some financial measures like Net Present Value. When we know the customer’s needs, we can schedule the stories into releases. Mike adds some extras to the basic agile (XP) planning process: buffering techniques from Critical Chain planning, to reduce uncertainty and planning multiple team projects.

Of course, you have to track and monitor the performance of the team and take the appropriate corrective action, or you wouldn’t be agile. Mike tells you how to do that, too. The book ends with an analysis of why agile planning works and a case study planning stories for a game.

If you’re new to Agile estimating and planning, this book will give you the practical information you need to start applying the techniques. If you’ve been doing this for some years, as I have, much of the material will be familiar, but you will still discover some useful techniques or explanations why it works. That comes in handy when you’re trying to introduce agile estimation and planning in your team or organisation.

Real business requirementsReal Business Requirements

The second book is about “Discovering REAL Business Requirements for Software Project Success“. In this book, Robin Goldsmith claims that many projects get in trouble because they don’t have the real business requirements to work with. The problem is twofold:

  • Real, meaning that we touch on the essence of what the customer needs.
  • Business requirements, meaning that we understand the business needs and its goals, before we decide what part (if any) we will automate. All too often, what we write are Product requirements, the way the system(s) should behave. But have you ever asked yourself if the system was really the best solution to the customer’s problem?

The book gives a lot of techniques to discover the business requirements. You can use these techniques both with heavy upfront requirements efforts or agile story writing.

I think stories are a great way to describe business requirements. You can use them to stage small “plays”, where people acting the different roles go through a certain scenario, based on available stories. As soon as the play reaches a dead-end without a suitable story, you know you need to write another story. That’s just one of the many ways you can both generate and verify requirements.

What I like most about the book, is that it contains a lot of such “tests”. You can use these tests to verify if your business requirements are really business requirements. Hmmm, can you do test-driven requirements discovery? I think so. I’ve been using some of these techniques in a TDD manner: if the requirements test fails, you need to discover some more requirements, until the test succeeds. Red-Green-Refactor, it’s not just for code!

CMMI AssessmentsCMMI assessments

Marilyn Bush’ and Donna Dunaway’s “CMMI Assessments. Motivating Positive Change” deals with performing CMMI assessments to ascertain the state of a process improvement effort, as opposed to performing an audit to rank the company on the CMMI’s maturity scale.

Many of the obstacles for a succesful assessment are the same as for a retrospective: the need to create trust, to create (and maintain) a constructive atmosphere, to ensure that we work to improve the next project, not to complain (or blame) about what happened in the previous project and to avoid people “gaming” the system to look good. With an assessment, the dangers are even greater, because there is always that maturity ranking. All too often, the maturity level, not the process improvement, becomes the goal. This and many other potential problems are recognized and addressed by the book. Some claimed benefits sound quite familiar:

  • Assessments effect change by involving and motivating organizations in efforts of self-analysis. Or, as the cool kids say: “Hansei”. It is stressed that all workers involved in the work should be involved in process improvement and assessments.
  • Assessments effect change because they help the workers in an organization understand that Processes, not People, need to be fixed. It’s never a People Problem, it’s always a Process Problem; how very Toyota Way!

Agile Retrospectives

I think using CMMI assessments to motivate people to perform process improvement is a bit of an uphill battle:

  • the idea of ranking practically invites gaming
  • the staged representation “forces” a certain order in your process improvement efforts. I prefer to attack bottlenecks or to improve flow by removing muda when I see them.
  • a “real” assessment is quite a heavy, resource-intensive process. We need something that can be done a lot more frequently, to get faster feedback and to keep people motivated by seeing regular improvement. Something like Retrospectives. Buy Norm Kerth’s book if you haven’t already and look out for Esther Derby’s new book.
  • there is a lot of confusion about what CMMI actually is. Is it a model, a process improvement technique, a process?

CMMI and agility

Ohmygod, Pascal is straying from the one true Agile path. It starts with doing waterfall projects; before you know it, he’s onto the hard stuff, like CMM!” 🙂

Is there a conflict between agility and CMMI? A bit, but not a lot, I think. But I need to learn a bit more about CMMI. For me, CMMI is not a process. CMMI is a set of questions about process and how to ask them (assessments and appraisals). Processes or methods like XP, SCRUM or any give the answer to a lot of these questions. For example, Philips showed that you can be easily appraised at CMM Level 2 by applying XP and Scrum.

One can disagree with the questions or the fact that they are grouped in maturity levels (I prefer the continuous representation), but I think we can all agree that any method should be able to answer questions like “How do you discover and manage requirements? How do you plan? How do you manage risk?…”. As long as they are open questions…

My view is contradicted by what’s written in “CMMI SCAMPI Distilled” [Ahern et al] on pages 32-33, where they compare hacking, agile and “Planned development”, as represented by CMMI and SCAMPI (based on the work of Boehm and Turner). Phrases like “CMMI can be applied to a large class of software-intensive efforts. As projects become more complex and increase in size, Agile methods are less applicable and a planned delivery approach contained in CMMI is often the preferred approach.”. So, CMMI is a method now?

/me confused… I’ll let you know when I’m less confused.


Toyota Way in Geneva

I met Freddy Mallet and Jacques Couvreur at XP Day France, after the Toyota Way session. They invited me to come to Geneva and present the session, whenever I was in the neighbourhood. So, on the way back from Milan to Belgium, I stopped a few days in Geneva.

Hortis Hortis organized the Toyota Way seminar and provided some food and drinks for a discussion afterwards. The audience seemed quite interested. So much so, that Freddy had to stop the discussion and remind people that there was food and drink waiting for us. There was a good mix of managers, IT people (both developers and systems engineers), someone from local government who wanted to know if Lean was applicable to politics and even a magician.

I finally met Franco Martinig from Methods & Tools, after having exchanged many emails about articles and his gracious sponsoring of the XP Days Benelux and Agile Open conferences.

Discussion continued until the business center closed. Afterwards, we went to a bar in the lovely district of Carouge (founded by Sardinian immigrants), to talk more about the state of agility in Switzerland and Belgium.

I spent the next days exploring Carouge, the Rhône and lake area of Geneva and walking on the plains of the Saleve mountain.

Telepherique du SaleveThanks to Freddy, Hortis and the Geneva Agilists for the great reception. Hope to see you again soon.

Lake with Saleve in background Saleve

That’s the last of the touristic blog entries. And now, back to our regular schedule of Agile/Lean/Toc entries.



Essap – Day 3

Day 3


Matteo presented a “Bowling Game” Kata, to show how TDD works, in very small steps. After the Kata, we ran a Randori, where we tried to write a roman-to-decimal converter. At first, the team made some progress, but then got bogged down by the combination of unfamiliarity with java, TDD and the difficulties of the problem. I’ve now participated in a few Randori’s and I’ve seen this pattern a lot: people get into trouble and try to program themselves out of trouble, thereby making the situation more difficult. What can we do when things bog down? Step away from the keyboard. Revert back to the last working situation, erasing all code that was written since then. Take a break. Draw something on the whiteboard…

Meanwhile, Jacopo and I sketched out different approaches on a (paper) notepad. We tried simplifying the problem by breaking it in two parts; we tried a data-driven approach with very little logic; we tried a more algorithmic solution; we went through the data backwards, then we tried to go through it in the other direction. Programming problems have lots of solutions, each with their advantages and drawbacks. We explored several alternatives on paper and in our heads. We were the final pair in the Randori and finally implemented the algortihmic solution the team had embarked upon, despite the weird Italian keyboard, which seems to hide the { and } keys 🙂

During the lunch break, I wanted to see if we could do a simple Ruby implementation, without any loops or ifs. Of course we could! I haven’t been programming lately: getting people to follow a waterfall methodology takes up too much of my time. I realized that I still like to program. TDD (or should I say BDD?) is the fastest and most fun way I know to write working software. These little Katas are great exercises to explore different ways to solve problems. On the train from Milan to Geneva (read more in the next entry), I worked some more on the Roman numerals and on a Sudoku solving program.


During the Randori, we noticed that few participants had experience with java, the programming language chosen for the course. This could pose a problem during implementation. Pairing with people who know java helped, but we still lost a lot of time with the complexities of the java libraries (who invented java.util.Calendar and what were they smoking?) and infrastructure (web server, database) that we didn’t really need. Time to adapt again: we focused on the domain code only.

XP in Milan

Matteo, Luca, Allesandro and I went to Milan to meet with the local XP User Group. We talked about the activities of both groups, how we’re organized and the state of agility in Belgium vs Italy. We continued the talk at a nearby Chinese Pizza restaurant, were we had a mix of pizza and Chinese food.

Some members of the user group volunteered to pair program at ESSAP, to add a bit more java experience. On Thursday and Friday, there were lectures on acceptance tests, continuous integration and retrospectives. Of course, ESSAP ended with a retrospective and a party.

Read more about ESSAP.

Ciao! Essap Participants

Ciao Jacopo, Luca, Alberto, Francesco, Alessandro, Davide, Andrea, Piero, Matteo, Sergio, Federico, Alessandro, Alejandro, Uberto and the members of the Milano XP UG. Hope to see you again. In Italy, Belgium or at one of the fine agile events around the world. Hint: if you like beer with your agility, don’t miss XP Day Benelux in Mechelen.

I couldn’t stay for the whole course. On thursday morning I was off to Geneva, to meet with Freddy Mallet of Hortis.