Thinking for a Change

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.

Some new books arrived

Agile 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 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 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!

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.

I’ve been away at a “Mastering the Requirements Process” course led by Suzanne Robertson of the Atlantic Systems Guild.

I’m looking for a method/process/techniques to gather (or “trawl for” as Suzanne calls it) requirements, to integrate with my customer’s existing process. The “Volere” tools seem quite suitable, especially the techniques to define the context, goal and business events. I often see teams jump directly into defining the product, “what will the system do?”. Before thinking about what, you have to know why.

What is the context and goal of the business in your current project? Do you know? Have you asked? Is success of the project defined as how close you come to the business goal?

What could happen if you don’t have the answers to these questions?

Your product scope might become too large. Feature upon feature gets added to the product. On what basis? How can you decide if this feature should be in or out of the project? How can you prioritize requirement, unless you have some way of guessing how much they contribute to the business goal?

People might disagree about whether the project is succesful. There is a danger with saying “a good product is one that conforms to requirements.”. What kind of requirements? Product requirements? What good is a product that does everything we agreed it would do, unless the product requirements are linked to business requirements. Have you ever been in a project where the customer was dissatisfied, even though you implemented all the requirements? Maybe you misunderstood each other. Maybe you had a different definition of success.

Start asking those business questions today. That means you have to understand the lingo. At least ask “why?” a lot…