October « 2006 « Thinking for a Change

Oct

Drawing your process. Backwards.

Draw me a process

Rob and I made a small, but useful change to the “I’m not a Bottleneck! I’m a free man!” session at Agile North. During the second half of the session, we ask the participants to draw their process. Many participants have difficulty doing this. Where do you begin? Where do you end? Where are the boundaries? What to include, what to exclude?

At least now we know where to start…

Start at the end

We now tell the participants to start with the customer. Our work only generates “throughput” (value to the company) when the customer pays us in some way for something of value we give them. So, start by drawing the customer.

From the customer, work backwards. What does the customer receive, that they value? A piece of running software? Where does that come from? And so on, up the value stream. We noticed that the participants didn’t get stuck drawing their process. It did take some effort to get started. We are so used to thinking forward. It may take a while before you switch from “The customer gives requirements” to “The customer receives running, valuable features”.

The idea comes from the practice of Lean consultants to walk and map the value stream backwards, from the customer to the source materials. This helps you keep the customer perspective and see opportunities for “Pull” scheduling.

In Will Self’s novel “My idea of fun“, the main character and his evil guru (“The Fat Controller”) take a mental voyage from a cotton shirt they bought, all the way back to the cotton pickers near the Nile. Will Self invented the term “Retroscending” for this exercise. Next time, you think about your software process, try to retroscend.

Oct

Agile Retrospectives

In yesterday’s post, I told how Rachel Davies encouraged us to reflect and improve using “Retrospectives”.

Great advice, but how do you convince people to hold a retrospective? How do you organize a Retrospective? How do you get useful information? What do you do with what you learned during the retrospective?

The classic book about retrospectives was written by Norm Kerth. It answers all of these questions, and then some more. There is a particular emphasis in the book on creating a “safe environment”, where everybody can contribute without fear. Especially when the project hasn’t gone too well (and you could well learn a lot of useful information), you need to do a lot of work to get rid of the “poisonous” atmosphere that may have built up in the team. I spoke with Norm at SPA2006 and attended his keynote. If I have a team that’s really in trouble, I’d want Norm to come in, because he has the experience and techniques and knows how to deal with difficult situations. And he can tell great stories.

Ester Derby and Diana Larsen have published their “Agile Retrospectives” with the Pragmatic Programmers. As usual with the Pragmatic Duo’s books, it’s a thin (+/- 160 pages) book with large readable fonts and many illustrations. There’s less information (the first 40 pages or so) about how to lead retrospectives than in Norm’s book. This is more a book for people who know what retrospectives are and can get more information from other sources, like the “Retrospective Facilitator’s Gathering“.

As the book says at the end of chapter 3 “Leading Retrospectives”: “You are probably an expert at what you do now. Facilitation draws on different skills than most of us develop working in software. Facilitation also requires a different perspective. It takes time and practice to feel comfortable with new skills.” Effectively facilitating a retrospective (or any other event) takes a lot of skill. Having such a short introduction to the skill of facilitating retrospectives, this book is more aimed at people who already know what retrospectives are and have performed some. There’s not enough information for newbies, who are better served with Norm’s book.

Where the book shines, is in the second part. Here, we find a large list of activities we can perform during a retrospective. Each activity starts with a “Purpose” section, so you can select the right activities for the goal you want to reach. The activities are organized in several sections, for each phase in the retrospective:

Setting the stage
Gathering data
Generate insights
Decide what to do
Close the retrospective

I found some interesting activities that I can apply and some ideas for new activities. The handy reference format is a useful tool when planning a retrospective. When you run regular retrospectives, participants can get bored with performing the same activities over and over. Having such a wide selection of activities to choose from, makes it easier to keep retrospectives “fresh” or selecting the appropriate activity for the group and situation.
This book is recommended for people with some experience with retrospectives. As with most things where humans are involved, a word of caution is in place: be careful, you’re dealing with people’s emotions and feelings. A retrospective after a succesful project is relatively easy. A retrospective for a challenged or failed project is hard and dangerous. Get a pro or some training before you embark on such a venture.

Retrospectives are absolutely essential to become and stay agile. But be careful out there. “Coach” or “facilitator” is not a term that should be taken lightly. It takes skill and experience.

Oct

Agile North

I spent a nice day at Agile North in Preston, on Sepember 20th. The Agile North group organized this one day Agile conference.

Rob Westgeest and I met at Manchester Airport with Kevin Rutherford, who drove us deftly to Preston, just before the approaching traffic jams.

The conference started with a keynote by Rachel Davies, current chair of the Agile Alliance. The talk told us how Rachel got into agile software development and her advice on moving to agile software development. Her theme was a common one among experienced agile practitioners: it’s about the values and principles. You’ll have to tailor the practices to your own situation. Start with a documented agile methodology, any methodology, the one that seems to fit your environment best. Start delivering and reflecting upon what you do. Adapt the method. And again. Use retrospectives for the reflection part (more about that later).

The first session was a goldfish bowl, organized by Charles Weir (on the left of the picture, seated on the table) about “Dealing with Customers”. Unlike most goldfish bowls I attended, this one was relaxed and featured some interesting discussion and tips on how to work effectively with customers. The audience had a nice mix of experienced people who could tell stories of success and failure, and people new to agile, looking for ways to improve their customer relationships.

The session was not about great ideas and breakthroughs. Most of it were small, simple ideas that everyone could apply, few of them specific to agile development. It does take sustained effort to create and maintain a great customer relationship. And again, the advice was to solve your worst problems (or bottlenecks) and to adapt to local circumstances.

I would have liked to attend the Rails session too, but you can’t be in two places at the same time…

Kevin Rutherford After lunch, Rob and I organized the “I’m not a bottleneck! I’m a free man!” session. In this two hour session, we first introduce the “5 focusing steps” in a simulation, where the participants are asked to implement a paper boat and hat folding company. The workers got paid in chocolates.

In the second hour, some people come forward with a process that they want to optimize. The other participants act as Theory of Constraints consultants, coached by Rob, Kevin and me.

In the picture, Kevin proudly displays the result of his team: at least one way each to “exploit”, “subordinate to” and “elevate” the bottleneck of the customer. This particular system has a loop in it: software is tested and if it is defective, it is fixed and tested again. If you’re going to map this process to find bottlenecks or make a “value stream map”, it’s easiest if all the loops are unrolled and you get a linear process. How do you unroll the loop? You could take the average situation (e.g. it takes one fix-retest cycle on average); you could take a specific examples (e.g. feature XYZ went through 3 fix-retest cycles); or you can put a fork with probabilities in the diagram (e.g. 80% of all cases do not need retesting, 15% need one fix-retest, 5% need two fix-retest cycles).

The last session of the day was about agile in large organisations. I was quite interested, as I currently work for a largish organisation myself. The presenter didn’t get to finish his story, because there was a rather large amount of push-back and questioning from the audience. I didn’t get the message of the session. I’m still interested in the subject, so I’d like to see the rest of the slides.

Finally, we had a panel, where the audience could ask the “experts” questions. Rob and I had to decide which one of us would be on the panel. Rob lost, so he had to answer all the difficult questions 🙂

Agile North ended with a quick pint at the pub (kindly sponsored by Kevin) and an even quicker drive back to Manchester to catch our flight back to Belgium. All in all, a good conference, nice turnout, well-organized, interesting sessions and discussions with other participants. Thanks to the organizers for inviting us. I’ve enjoyed the conference, hope you have too!

Thinking for a Change

Categories

Blogroll

Drawing your process. Backwards.

Agile Retrospectives

Agile North

Event Calendar

Archives