Thinking for a Change

The XP Day Program. pt. 5

Testing. Coding. Testing. Coding.

Here are three more “technical” sessions for programmers and testers.

Emmanuel Gaillot and Christophe Thibaut show, in the form of a “Kata” exercise, how you can apply Test Driven Design in a functional language in their “Fugue about Paradigms and Functional Programming“. We’ve all seen TDD demos before, but this one is different in many ways. The particpants in the Paris Coding Dojo have developed several forms of programming exercises. In a Kata, the presenters solve a programming problem live, using TDD. The aim of the session is to take small, clear steps so that everyone in the audience understands how and why the presenters take each step. In this session, Emmanuel and Christophe will use the Haskell functional programming language instead of the more familiar object-oriented languages. It’s a great way to introduce an unfamiliar programming language. The session also raises the question if the functional programming paradigm leads us to solve problems differently.

Anko Tijman will present and discuss ways to “Build and Agile Test strategy“. Agile methods have done much to emphasize testing and bring it to the attention of developers. The gap between testers and developers has become smaller. Anko will tell us more about extending agility deeper into the testing profession.

Vera Peeters asks a controversial question: “Is JUnit overdesigned?“. Could it really be that a tool written by Mr Kent “You Aren’t Going to Need It!” Beck contains some stuff you don’t need? I’m shocked! How many of your unit testing framework features do you use? How much do you use of other frameworks’ features? What is the cost of frameworks, of reuse? When is it more effective and economical to write than to reuse? Discuss these and other burning questions in this workshop.

The XP Day Program. pt. 4

Starting off on the right foot..

“The beginning is a very delicate time” opens David Lynch‘s “Dune“. This is true of projects too. The following sessions can help you get started.
In “Agile Planning“, Sven Gorts and Hans Keppens explain how planning is done in agile projects. This is a nice introduction to the subject with real life examples. If you want to know how it’s done, come to this session.

“Planning for non-functional requirements in agile projects” by Johan Peeters and Paul Dyson is a simulation where you get to experiment with different techniques to prioritise, estimate and plan non-functional requirements. Whereas the agile methods have a lot to say about functional requirements (“stories”), very little is said about more pervasive, application-wide quality requirements. Some time ago I discussed with Johan about agile planning. He agreed that it could work for features, but not for security requirements. Johan argued that you couldn’t plan security requirements in an agile manner. I said you could. I just didn’t know how. Now, Johan knows how. It works. See? I told you so! 😉

In “Agile Factors“, Rachel Davies and Steve Freeman lead a workshop where the participants look at the important things to agree on before you start a project. Agile methodologies leave lots of room for variations and tuning parameters and expect teams to tune regularly. How long will your iterations be? When do you hold the standup meeting? Which one of those are important to agree upon before the start of the project? Which points do you really need to have consensus on before going further? Bring your ideas to this workshop and explore them with the other participants. Next time you start a new project or a new iteration, you will have a better idea of the what you need to settle quickly.

… and keeping on going

Once you get going, you need to keep going, check where you are and adjust your course. The following sessions will help you do just that.

In the “Continuous Integration” session, Vera Peeters and Sven Gorts explain what continuous integration really is. Small increments, a system that’s always working and rapid feedback are essential to keep going and to keep on the road. This session explains how you do continous integration and what’s in it for developers, testers, managers and customers. This is one of the base practices and principles. If you don’t have continuous integration yet, come to this session to learn how and why. If you integrate continuously, come to this session to contribute your experience.

Steve Freeman and Mike Hill will teach us “Story telling with FIT“. FIT is a wiki-based tool to write acceptance tests, conceived by Ward Cunningham. Acceptance tests clarify communciation between customers and developers. This very interactive tutorial concentrates on the communication aspect of acceptance tests: it’s all about creating a common language with the customer and within the whole team. If you really want to know what your customer wants, this session will help.

Are we there yet? Do you get that question often? Do you know the answer? Does everyone on your project know where you are? “Writing on the Walls” by Emmanuel Gaillot and Christophe Thibaut lets participants explore different very simple techniques to make project status very clear. If you want to be agile, you have to change course. You can’t do that unless you know where you’re going and where you are now. Warning: after this session you will have an urge to put flipcharts, whiteboards, index cards and post-its on your walls. Don’t resist the urge. Let everyone know where you are.

Famous for 15 seconds

Kevin Rutherford included this blog in the “Carnival of the Agilists“, a twice-monthly posting of noteworthy blog entries about agile. This week’s entry puts this blog and the XP Days Benelux conference in the spotlight.

Have a look, if you haven’t yet, to Emmanuel Gaillot’s “Borrow the first 5 minutes” and Dave Nicolette’s “Lean: process over people?” blog entries. Can’t say I agree with Dave’s conclusion that Lean is for those who don’t trust people…

The XP Day Program. pt. 3

Lean, not Mean

I’m happy that there are two “Lean” sessions on Friday’s program, as I believe Lean ideas are one of the main inspirations of Agile methods.

I present the “Toyota Way of Managing Projects“. Readers of this blog know my fascination with the Toyota Way. In this session, we explore the 14 principles of the Toyota Way, their equivalents in agile methods (if they exist) and how I’ve applied them in “real life“. If you think we have nothing to learn from manufacturing, come to this session so that we can have a heated debate. If you want to explain to a manager where all these weird agile ideas come from, you could do worse than use Toyota, the most successful manufacturer, as an example. The similarities between the Toyota Way and agile are striking. Coincidence? I think not. This session has already run at XP Day France and will be presented at XP Day London.

In “Haste makes waste! Oh no, it does not!“, Rob Westgeest, Tjakko Kleinhuis and Willem van den Ende use a simulation game to explain the Lean concept of “Flow” (one of the 14 principles) and how this can be applied to software development. What’s not to like in this session? It’s about a central concept of Lean; there’s a fun simulation; participants are involved actively; the session introduces a new idea and shows how it applies to software development. That’s the quintessential XP Day Benelux session.

Invest. 5 minutes at a time

Emmanuel Gaillot has written a brilliant blog post about getting out of vicious cycles. It’s easy (for an outsider and to most insiders) to see when a team is in trouble, spiralling down towards a crash. If you’ve got a bit of experience in agile methods, you can come up with several ways to get out of trouble. Most of these changes involve going slower to recover some of the debt you’ve accumulated. But, like the White Rabbit, time is something these troubled teams don’t have. What now?

Emmanuel shows how you can start by “borrowing” 5 minutes of your employer’s time. Don’t ask for permission. Don’t tell anyone. Just do it. Invest those 5 minutes in some improvement, preferably on a bottleneck. Watch how this improvement saves you time. Reinvest that time into another small improvement. Before you know it, you’re reversing the vicious spiral and turning it into a virtuous cycle.

Now, we’ve all seen (or been part of) these teams where there’s never enough time. That’s the surest sign of a team in trouble: when they start saying “We don’t have any time to…”. That’s when they most need to take the time, slow down to go faster. It sounds paradoxical, but it works. I once gave a team the advice to dedicate half of their iteration to “debt-paying” work: refactoring, bringing the disused unit tests back, automating deployment. This team’s velocity had been dropping faster and faster each iteration. Slowing down was hard for this team’s leader to sell, but they had the courage to do it and they got back to a reasonable velocity. Don’t let your team get this far behind. Invest a few minutes now to save half an iteration later.

This reminds me of something Jim McCarthy says in the first of his “23.5 rules of thumb ot ship software”: people come up to him and tell him: “Great talk, Jim. But you’re talking to the wrong guy. You should be talking to my boss.” Jim’s reply is “I’m talking to exactly the right guy!”. It is your job to improve things around here. You can’t wait for someone else to do it for you. Do something. Do it now. What’s five minutes?