Mini XP Day Benelux 2015

April 3, 2015 in Mechelen, Belgium

Each spring we rerun the best sessions of the previous XP Days Benelux at the “Mini XP Day“.

This year we have 11 sessions that cover:

  • Improving testing, design and coding skills by “programming people”
  • Honing your Test Driven Development skills
  • Recruitment techniques
  • Going from idea to business value
  • Using feedback loops in Scrum
  • Improving the way you work and the way you work with others
  • Managing agile transitions
  • How students and teachers apply “EDUScrum” in school
  • Defeating the dark forces that hold you and your team back from taking action

There’s something for everybody who’s interested in agile, development and systems thinking.

Don’t take our word for it

Have a look at the  feedback from participantsphotos and articles about the conference.

Don’t wait too long to register for the conference, as it usually sells out.

See you there!

XP Days sketchnote


We’re off on an adventure!

The Dream Team Nightmare

The Dream Team Nightmare

It took a while to arrive because the book was out of stock at Amazon, but it’s finally here, just in time for the holiday break: Portia Tung‘s “Dream Team Nightmare“!

I sat down with a cup of coffee and started to read the book. Portia’s writing style is engaging and lively with lots of dialogue and very short chapters. At the bottom of the chapters you have to make a choice and then go to a designated page.

I’ve been on agile projects for years, so I expected to breeze through the book. After all, most teams face the same problems. I’ve solved them many times. Why should this “Dream Team” be any different?

After only a few pages I read

Patrick [who hired you as an agile coach] asks his secretary to escort you out of the office. Before you know it, you’re back on the street.

It feels like you’ve been punched in the gut. Thoughts swirl in your head. Should have. Would have. Could have. You decide to take time out to reflect on what happened. You’re not quite ready to give up doing a job you love. not yet.


Fired! On my first day. Game over. Do you want to play again? Of course, but now I’ll make smarter choices.

And… I was asked to leave the Dream Team and see if things would go better with another team. THE END.

“If at first you don’t succeed, stubbornly try again and again”, that’s my motto. So, one more try.

Aha! We come to a part where my mission is described as a user story with acceptance tests. That will help me to understand better what’s expected. I restart the book and start working with the team. I flip backwards and forwards as the book directs me to see the consequences of my choices. It’s getting smoother. And then there’s a conflict with one of the team members. At the end of the 5 days I present my recommendations. And then… nothing happens. THE END.

This agile coaching lark is harder than it looks.

This is frustrating. I’ve only scratched the surface of the book, read a few chapters and each time I reach a dead end. Reminds me of some projects I’ve been on.

And then I have a brilliant idea.

What would Portia do?

I’ve been lucky to work with Portia and see her at work. I will restart the last time and at each choice ask myself “What would Portia have done in this situation?” Portia would

  • talk to everybody to understand what motivates them
  • help the team to make their own decisions
  • reach agreement on the value we’re creating
  • get a good understanding of where we are
  • define goals together and clarify them with testable acceptance criteria
  • take some time to reflect regularly
  • help the team to create and explore options
  • lighten up the mood with silly exercises like “profile cards“, cookies and team lunches

I can do that. It’s just a matter of taking a bit more time before making a decision. Let’s start again, from the top.

Pinocchio-Blue-FairyThis time, with the help of Portia (sometimes in the role of Jiminy Cricket to keep me on the straight and narrow, sometimes as the Blue Fairy who grants wishes and saves the day) I progress through the book. There are still a few choices, but fewer and fewer.

The team starts working together to visualize their situation. Faced with the enormity of their task, they feel demoralized. We come up with three options to deliver value and involve the Product Owner.

And there it gets tricky. If I’m not careful, the unspoken simmering conflict between team and product owner/management erupts again: the company needs more than the team can deliver; the team blames the product owner for imposing unrealistic scope and deadline. THE END.

And that’s where it usually ends, but there’s another option. There’s always another option.

Instead of saying “It’s impossible to deliver this scope by this deadline!” you can ask “What do we need to achieve the goal before the deadline?” Two other agile teams “Predator” and “Green” can help the Dream Team. The teams apply Real Options to decide on the day when they have to decide. Meanwhile they create and explore more options to achieve the company’s goal: different ways to select scope and divide the work between the teams.

Finally, a happy end

From there it’s relatively smooth sailing. By now I see the trap on page 216, where I fail to ask the team to review and improve my recommendations because I’m rushed, coming by a mile. If only it were this easy in real life to take a step back for a moment and take the time to think…

And then we arrive at the final chapters: the team present their delivery options and their improvement actions. Everybody’s energized to work on those actions. I don’t know if they’ll live happily ever after, but the adventure continues.


Observations and recommendations

  • There’s a list of recommended tools on page 203. Appendix 5 contains the coaching tools used in the book. It would be useful to have some links where I can find out more about each of the tools. Maybe something for the Agile Adventure site?
  • I loved seeing the Current and Future Reality Trees in use. It would have been great to see a “Conflict Resolution Diagram” be used to bridge the gap between root causes and improvement actions. What are the underlying conflicts that have led and kept the team in its unhappy situation? Maybe something for the next agile adventure?
  • Flipping back and forth between chapters isn’t always practical in a paper book. But you can have your cake and eat it too. I bought both the paper and e-book version: the e-book to play, the paper book to loan
  • There are a few illustrations in the book: current/future reality trees, profile cards. A few more illustrations would have made the story a bit more vivid: what does the kanban board look like? What does the team area look like? No need to make it into a graphic novel. Henrik Kniberg‘s “… from the trenches” books are a good example of how illustrations can make the story more vivid.

Done. What’s left on the holiday reading backlog?

Some more light reading, because I don’t want to be that agile coach who hasn’t written production code for a decade.

ebdojo_xlargecover elixir_xlargebetajaerlang2_xlargecover lotdd_xlargecoverellnestam_cover150

Can anyone recommend a good e-book about Clojure that covers core.async?


Agile Tour Brussels 2013

What is Agile Tour Brussels?

Agile Tour Brussels 2013 logoThe purpose of Agile Tour Brussels is to gather in one place Agile practitioners and people wanting to know more about Agile. At Agile Tour Brussels you will meet a mix of attendees who are completely new to Agile, experienced or experts.

See you in Brussels on Sept 27, 2013

The program has been published and registration is now open.

The program features 5 parallel tracks with 30 sessions by speakers from Belgium and abroad. The conference is held at the EPHEC school in Brussels.

See you there

I’m helping out with the organisation, mainly doing the administration and registration. You’ll find me at the registration desk. In the afternoon I’ll present a session about how to use Real Options to make architectural decisions. This will be the first time I present this session in English, after presenting it in french and dutch.


XP Days Benelux 2013 – Call for session proposals

XP Days Benelux is an international conference where we learn to bring software to life and grow mature systems that support business needs.

It provides an excellent environment for exchanging ideas, hands-on exercises and extreme experiences.

The best way to learn is to facilitate a session. We like sessions where you explore ideas as well as questions.

The conference will be held on 28 and 29 November, 2013 in Mechelen, Belgium.

The best way to learn is to facilitate a session at XP Days!

We’re looking for sessions where you explore ideas as well as questions. Sessions that dig deeper, going beyond the basic techniques and practices. We really want to find out why/how things work or don’t work. We invite you to propose:

  • hands on coding/design/architecture sessions;
  • discovery sessions – open ended workshops that explore new topics, common problems, promising techniques, or burning questions;
  • experiential learning sessions; get people learning by doing & reflecting; for example games or simulations.

We’re not only interested in agile and software related topics but we also want to explore boundaries and cross borders. What can we learn from other disciplines or sciences?

Available timeslots are 75 and 150 minutes.

We also welcome short experience reports (30 minutes) that focus on what didn’t work and why.

Do you have an interesting story, idea or question?

Send us your session idea today.

What’s so special about XP Days?

For one thing, we constantly try to apply XP, agile, lean, systems thinking, theory of constraints and all the other stuff we talk about. It wouldn’t be an agile conference if it wasn’t organised by using agile values, principles and techniques.

For example: how is the way we build the program agile?

Collaborating to get the best possible sessions

We don’t think BDUF is appropriate or possible, not even for a session description. Therefore, we ask session authors to send in a simple proposal: title, subtitle, presenters, description. It’s the equivalent of a story card: the promise for a conversation about the session.

Once the proposal is sent in, the author(s) can incrementally fill in more information, as the session becomes clearer. There’s a separate deadline for submitting proposals (July 13th) and finalising the proposals (August 28th), to avoid “student syndrome” and last-minute session hurried submissions. Within those two timeboxes, the authors work at their own (sustainable) pace.

Session authors help other session authors by asking questions and giving feedback using the “Perfection Game“. The proposal authors (and the conference organisers) act as “peer coaches“. Through the magic of questions and feedback, the proposal author iteratively improves their proposal(s). Aren’t session authors helping their “competitors” in the race for a place in the program? We typically get 3 proposals per slot, so the competition is fierce. Well, nobody said collaboration was easy. In the end we all benefit from a better conference program. And the organisers see who applies the agile values and who just talks about them.

Isn’t this coaching only useful for beginners? It certainly helps new presenters to marshal their ideas. But, as we’ve experienced while pair programming, experienced presenters get new insights and clarity when “juniors” ask naive questions.

Kickoff 2011 goals-s

The most powerful coaching questions focus on goals and benefits for participants. Why should someone come to this sessions? What is the one idea you want to get across? What will participants be able to do after attending this session that they couldn’t do before? How will you know this session was a success for participants?

A common problem with session proposals is that the authors try to “pile on” too many ideas. The usual session feedback reads “not enough time”. The solution is not to take more time, but to present less material more thoroughly. Think deeply: what is your Minimum Viable Product? If there’s any time left in your session you can spend it on interaction with participants and exploration of your central idea, rather than adding more ideas.

Release early, release often

A session proposal is not a session. You may have created the greatest session proposal, that doesn’t mean you’ve got the greatest session. There’s only one way to know if your session design works: implement it, release it and get feedback from participants. We therefore encourage presenters to do “tryouts” of their session. We offer places to do this at the Agile Belgium and Agile Holland meetups. You may be able to schedule a tryout at a local user group or in your company. Or just invite a few friends and colleagues to try out your session.

Seasoned presenters know that it takes at least three iterations to get all the details and the timing right.

Preparing to select sessions

Now that we’ve iteratively improved session descriptions, the most difficult task is to select the sessions for the program.

Near the end of the session improvement process we ask all session authors to select the sessions they want to see in their “ideal track”. We use these votes as a start of our selection process.

We also use these votes to calculate the “value” of a draft program. We do this by calculating the Program Attendance Factor (PAF) for each voter. The PAF value indicates how many of their preferred sessions a voter can attend, given the layout of the program. To count, a preferred session must be in the program and it must not be at the same time as another preferred session. A program that has a higher total PAF has more value for voters, because they can attend more preferred sessions.

In preparation for the program committee meeting we create a card for each session. Making a conference program requires a lot of visual management:

  • The color of the card indicates the type of subject so that we can quickly see if the program has a good balance of sessions
  • The names of the presenters are clear so that we can ensure no presenter has more than one session in a day (sustainable presenter pace)
  • The card has coloured dots to indicate the type of session and the experience level so that we can see at a glance if there’s a good balance for participants with different learning styles and experience
  • The cards have different sizes representing session length so that we can’t put them in program slots of the wrong size

The program committee reviews all session proposals before the program committee meeting. There are so many proposals that program committee members can’t review or even read them all. Therefore, the committee divides the sessions among its members and trusts that the other members have good judgment.

Before the program committee meeting, the proposals are put into four categories:

  • the sessions we really want to see in the program. Each program committee member can “champion” a session
  • the sessions that we won’t consider because they’re incomplete, withdrawn or inappropriate
  • the sessions that were selected in the voting process
  • other sessions

Sessions on the board

We have large sheets of paper that represent each of the days with drawn slots that are just the right size for the session cards.


Building a program happens in three rounds:

  1. Create a first version by putting the championed and most voted for sessions in appropriate slots. We do this track per track. For example: first fill a track on both days with technical sessions, then fill a track with process sessions… It’s OK if some slots are still empty.This first step should go quite quickly, without too much discussion. The goal is not to create a perfect program; it’s not even a workable program. We just need a version to start iterating.
  2. We spot a constraint violation, for example. a presenter who does two sessions in one day or we’ve selectedtoo many sessions of one type or subject. We resolve the constraint by swapping the problem session with another same-sized session already on the board or not on the board. We may also spot improvements in balance or PAF score. These are also performed using swaps. The only constraint is that we can’t introduce constraint violations by this swap. We keep iterating until the program stabilizes. We select a few “backup” sessions that we can add to the program in case one of the selected presenters can’t come.
  3. We internally publish a draft version of the program. All organizers can review the program at their leisure to spot any constraint violations or improvements. We often have to take a bit of distance to spot these. When nobody has any more improvement ideas, we contact the authors of selected and rejected proposals. Sometimes presenter availability can introduce new constraints (for example, the presenter can only be present on the first day but his session is scheduled on the second day). In that case, we go back to swapping sessions to resolve the constraint.
  4. DONE. Until something happens like a presenter dropping out.

Getting better

Kickoff 2011 retro-s

We continuously improve this session proposal-improvement-review-selection process. We’ve incrementally built a tool that supports our workflow. New features get added just-in-time as we notice irritations or get new ideas for improvement. Most of the organisers participate in other conferences where we “‘steal” the best ideas. In return, we invite everybody to “steal” any idea they like.

In summary: creating a proposal, growing and refining it, coaching other to improve their proposal, doing tryouts and refining the session is a lot of work. And then you might not even get selected because there are so many great proposals.

Is it worth it? What’s the worst thing that could happen? You spent some time to understand an interesting subject better. That’s not so bad, is it? If you get selected or if you just attend, you get to spend two days with open, intelligent, helpful and experience people to explore and discover interesting new ideas and problems. And one of those ideas or problems could be yours.


Ignore the cost accountants at your peril, because they won’t ignore you

Why should I learn about cost accounting?

It may not be immediately obvious, but the way your company manages its finances, costs and budgets has a profound effect on the way projects or products are started, run and terminated. You may have been in situations where you sat back in amazement at some incomprehensible management decision and thought “what were they thinking?”

They were probably thinking about budgets and costs. You will be surprised again next time unless you learn to understand and dialogue with your CFO and cost accountants.

Fun with cost accounting

Pierre Hervouet and I have created a session that explains the basics of cost accounting (based on making and pricing cocktails) and presents three alternative views you may find useful:

  • Throughput Accounting
  • Lean Accounting
  • Beyond Budgeting

The session doesn’t certify you as an accounting master, but it provides food for thought and pointers to plenty of material you can dig into if you want to know more. The materials (currently only in French) are published on the agilecoach site.

Join the conversation

Why don’t you go see your CFO or cost accountants today? Ask them what’s keeping them up at night. You may discover that you face much the same issues and that the solutions are similar. Yes, yes, accounting and budgeting are getting more agile, more lean!

The Agile Alliance has a new “Agile Accounting Standards” program to “Engage with FASB’s Emerging Issues Task Force to promote and develop an Agile Accounting Standard that will better define and standardize internal IT development costs for organizations that use an iterative or agile software development methodology” because  “The phased gate language [of the current standard] results in significant confusion and challenges of interpreting how to map the iterative work that happens throughout an Agile project lifecycle and is becoming an increasing urgent issue.