2006 April « Thinking for a Change

Agile Open: Agile Documentation

The last session of the first day was about Agile Documentation. This wasn’t a session someone had prepared in advance. We discussed a bit about the topic. At first, there was a bit of confusion about what we were talking about. Part of the discussion was really about requirements. What information do you need to start the project or to determine the impact of new requirements upon the system. Another part was about what documents we need to write during and after the project.

What documentation do you wish for?

At the end of the session, someone asked the question “If you arrived on a project, what documentation would you wish to be there?”. The image contains the list of what we wanted.
Agile Documentation

We quite liked to have an installation manual and documentation about the development environment, to be able to see the application and get stuck in developing some new stuff. To understand the big picture, we like to see the “system on one page” and some explanation of all the (seemingly) weird decisions that have been taken during the project.

For people outside of the development team we recommend an operations/maintenance manual, which contains all the information you need to keep the application running. Some users might need a user manual or online help.

Acceptance testing documentation

What I’m currently struggling with is: “How can we test the quality of documentation? Can we write acceptance tests or fit criteria beforehand to drive the writing? TDD: Test Driven Documentation?”

Answers on a postcard…

Agile Open: Presentation Zen

Presentation Zen

First session in the afternoon, we did the “Presentation Zen” session. We looked at a few examples of modern presentation styles, starting from Garr Reynolds‘ Presentation Zen site. We formed 4 groups and asked each team to give a presentation about what they liked and disliked. The teams presented their findings, first in a rehearsal, then to the people who weren’t in the session. It was a fun session (an important part of “presentation zen”), with a lot of creativity. Let’s hope we can reduce the number of bullet points in the world. Stop reciting bullet points today; start telling stories; start answering people’s questions.

Presenting the zen way

Presentation Zen 1

Vera, Willem, Kristel and Lieven explaining that you have to structure your presentation with the audience and your goal in mind.

They started out with a distracting, dense bulleted page. Then they presented the same information in several slides, using humor, asking questions of the audience and keeping us awake with their quattro presentation technique.

They stressed the fact that slides and documentation (handouts) should be different.

Presentation Zen 2 Bernard, Stijn, Hans and Paul presented themselves and what they liked and disliked in the different presentation styles.

They didn’t like the frenetic pace and many slides of a Dick Hardt or Lessig presentation. They feel it’s too intense and too easy to lose the focus of what the presenter is trying to tell.

They did like funny presentations, creativity and keeping the attention of the audience by the use of repetition, something you’ll encounter a lot in “Lessig” style presentations.

Presentation Zen 3 Johan presented the idea that the slides should underline, strengthen or summarize what the presenter is saying. It’s not the slides that tell the story, it’s the presenter.

I liked the fact that this team didn’t explain the different techniques, they showed them. “Show, don’t tell” at work…

Presentation Zen 4 Klaas used a “Takahashi” style (a single word per slide, in big bold letters) throughout his presentation. He explained what the different styles were about.

This is very much a presentation style where all the attention is focused on the presenter and the story they’re telling. The slides are sparse and stark. Klaas did need more words and more time than the previous team to explain what the different styles were about. Sometimes, an image does say more than a thousand words.

What’s it all about?

What is that “Presentation Zen” thing all about and why host such a session at Agile Open? It’s not about powerpoint gimmicks and who has the most slides in his deck. It’s not about getting rid of bullet points. That’s just a symptom, not the root cause.

It’s about communicating our ideas effectively; getting the story across. It’s about storytelling and fun; engaging the audience. If you want to talk to people about agility (or any other subject that you feel strongly about), you first have to make sure that they don’t fall asleep, that they listen.

Agile Open: Thinking for a Change

Thinking for a change

Marc Evers and I hosted a “Thinking for a Change” session. Not the whole session, just the “Current Reality Tree” to discover root causes of problems participants brought to the session.

Thinking for a Change 1 Team 1: the build keeps failing

On the left, the first group. They analyzed a problem where a team had a failing build for days on end and didn’t do anything about it.

You have to wonder why they put the automated build and tests in place. What was their goal?

Team 2: balance between work and life

Thinking for a Change 2nd group The second team, on the right analyzed the root causes of a situation where the balance between work and life wasn’t right. This was due, amongst other things, to long travel times between home and workplace. We had a similar situation during the session at SPA 2006.

You can use the thinking tools for other things than technical problems.

Thinking for a Change 3rd group

Team 3: getting two teams to work together

The third team analyzed a situation where development and operations teams didn’t work well together.

This situation was quite similar to the one I present to explain the technique, except that my example talks about one team and this situation was about the whole company. I managed to resolve the problem for one team. It will take a bit more thinking and effort to solve it for the whole company.

Finding the root of all evil

The teams found some potential root causes for their problem, but they needed a bit more time than the 90 minutes we spent today. I hope the three “customers” got a bit more insight in their situation. I find the Current Reality Tree a very useful tool to concentrate on a problem. All too often, we jump directly to a solution, before we really understand the problem. The CRT steps force me to go slowly and study the problem in depth, before I can start to think about solutions, with the Future Reality Tree.

I use the Thinking Processes every day, together with the other people who are involved in the situation. I don’t need to explain the technique, we just do it. All it takes is a piece of paper, a pen and a few people who want to solve a problem.

Agile Open: Day One

Agile Open today! When we organize an event, I always feel like I did when exams started: after all that preparation, it’s finally started. No more stress, just do it!

Planning a conference

First thing in the morning, everyone briefly presents the session ideas they put on the conference site. Some sessions got invented on the spot. Usually, these are of the type “I have a problem with X. Who can help me solve this problem?”.

After that, everybody votes for their favourite session by putting stickers on the session descriptions. Then, it’s a simple matter of scheduling the sessions in 6 slots in 2 tracks, taking into account the constraints:

A session leader can’t do two sessions at the same time
We have one large room and one smaller room.
We have one beamer.

We made a definite schedule for today and a tentative one for tomorrow. Tomorrow we’ll revisit the schedule and may reschedule, based on the new information we’ve gained.

What do you really want ?

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…