|
|
Another session about Business Analysis. I recognise a lot of the tools and the presenter uses a similar approach to mine: derive required capabilities from the business value drivers.
However, like most of the other analysis sessions, there was too much talking and not enough listening or doing. There was no participant interaction, just a long, monotone discourse.
Olla let the participants see the difference between Push and Pull scheduling, first with examples from his past flipping burgers, then with a simple simulation. We had to work together to fold paper airplanes. This time I was the lucky player who got to be the bottleneck. We then told each other about similar situations in our work life. Most of the stories were about integration testing being the bottleneck.
Participants liked the pull system better: less waste, less stress, better quality.
I’ve sent Olla a complete perfection game about the session, but here are some of the highlights:
To make it perfect
- Use an example that is “pure push”, not the mixture of push and pull used at McDonalds
- Explain the advantages and drawbacks of each method
- Link push and pull to IT, to help participants see the connection
- How do we proceed if we want to install a pull system?
Tsutomo contacted me before the conference to exchange game development ideas and I met him and his Japanese friends at the Thoughtworks office. Unfortunately, I couldn’t attend the session because I wanted to take part in the two sessions described above. I only got to see the end of the game, but the game seemed to be a success: participants were really involved and they got better insights into Kanban. Tsutomo got some good feedback to improve the game. The game is published on Tsutomo’s site. I hope to see this game again, improved with player feedback.
Closing
Thursday evening’s banquet set a speed record: one dish had only just been served or the waiters asked if they could remove the plate and plunk the next dish on the table. In contrast, Jared Spool’s closing keynote, although entertaining and informative, set a length record. What with all the announcements, people were fidgeting to leave. The evening ended with a few drinks and lots of discussion of agile, lean and organisations.
I didn’t participate in Friday’s open space sessions, just said goodbye toĀ a few people. After a breakfast meeting and a visit to the Museum of Modern Art came the long flights back to Belgium. Another Agile200x has gone. Next year’s conference will be in Nashville, Tennessee, home of Country music š
Most of today’s sessions are about business analysis. This Feature Injection approach looks a lot like what I do, but explained at a very high level. Essentially it boils down to:
- Identify Value: make sure you have a business value model which defines the type of value projects seek: increase revenue, decrease cost, protect revenue, reduce risk, increase information…
- Identify Capabilities: what is the minimum set of capabilities we need to realise the value(s)?
- Get lots of examples: understand what exactly happens in different circumstances
Or stated differently:
TO realise < identified value> AS A <actor> I NEED <identified capbility>. GIVEN <example situation>, WHEN <example action> THEN <example outcome>.
Now we just need a way to find those pesky actors who deliver the value.
This session focused on the requirements that don’t neatly fit into the User Story mold: non-functional qualities, implementation and design constraints, cross-cutting concerns. How do we represent these?
- Write specific User Stories. E.g. AS A CTO I NEED the solution to be deployed into environment X SO THAT our support costs remain constant. The advantage is that the rationale is clear. The disadvantage: this story is never done.
- Add extra constraints to the User Story. E.g. AS AN accountant I NEED report X in 5 seconds SO THAT….. The advantage is that the information is directly associated with the story and has user meaning. The disadvantage is that there are usually several criteria, so the User Story might get very complicated.
- Add constraints to the “iteration definition of done” or “release definition of done”. E.g. all modified or new functionalities must be documented in the User Manual before the iteration ends. Advantage: useful for recurring needs. Disadvantage: may lead to implementing and testing these requirements late, so that nothing is really DONE until the end of the iteration or release, batching up work at the end.
- Add acceptance criteria. E.g. GIVEN a session at the conference WHEN I select the details THEN the full session description is displayed within 3 seconds on any web browsing device. Advantage: concrete, leads to lots of questions as we explore scenarios, leads to automated acceptance tests. Disadvantage: where do you put the tests: story, module, application, global?
- Other techniques like planguage or simplified text descriptions of constraints.
One extra tip I would add: define service levels.
Service levels
For many non-functional criteria we can define a limited set of “service levels”. For example we could have three security levels:
- Top secret: nobody can see it, until it’s published in the newspaper
- Private: only the person concerned + HR can access the information
- Public: anybody can access the information
Or we could do the same for response levels:
- Blistering: answers within one second
- Snappy: answers within 3 seconds 98% of the time
- Relaxing: answers within the time to take a lunch break
Now, instead of discussing (haggling) over details of non-functional requirements (“is 1.5 seconds fast enough? No? 1.4 seconds?…”) we put each story into a service level “bin”. Most User Stories can be classified quickly. We can annotate the User Story with the appropriate set of Service levels in each of the dimensions. We can subject the User Story to standardised acceptance tests that verify if the implementation does indeed comply with the rules of the service level.
For those few stories where the standard service levels aren’t a good fit, we can create customised criteria and tests. And of course, we’ll review and update the service levels when we see that the classification doesn’t fit any more. As long as we keep it simple, with few levels, we can communicate and work efficiently.
More games
This afternoon I go to see two more games:
 Games, games games
 We innovated with The Bottleneck Game to be able to accomodate more participants: Portia and I ran two parallel simulations with two groups. Between each round, everybody got back together to share lessons and improvements. As it was only the second time we’d run the game this way, we were a bit nervous. But the game went very smoothly. By the end our smiling participants were uncertified Theory of Constraints consultants. From now on, they’ll see bottlenecks everywhere.
One of the participants who played the role of consultant when so far to as to plot the game on his portable whiteboard so that we knew our cycle time and could see where there were hiccups in the process.
The Business Value Game was too crowded and noisy.Ā We wanted to limit the number of players because we know that too large teams have difficulty to reach consensus. Unfortunately, the room wasn’t large enough to let extra participants sit on the sides as observer.
In this interactive workshop we got to tell stories with the help of different sets of cards. A simple, fairytale-like set of cards led us to tell a meandering story about foxes, witches, queens and treasure. A more complex set of cards with multiple meanings led to a nightmare-like, surreal story with incoherent jumps.
Telling stories allows us to add meaning and emotion to the information we’re giving. The cards add a tactile and visual element to touch on more of our learning modes, not just hearing or reading. These techniques are useful for retrospectives, training and coaching.
Another interactive session, where Jenni and Ole used a flirting metaphor to help us to connect and communicate better with our co-workers. The session was built around and eight step model:
- Radar: first you have to be aware of yourself and your environment
- Target: you have to choose who you need to connect to
- Move in: show interest in the other’s perspective and connect
- Back of a little: give the other person the room, the option, to connect with your or not
- Open up: share something personal
- Dance: have fun together
- Get real: overcome problems together
- Enjoy!
The flirting metaphor was unexpected and could have been awkward, but Jenni and Ole’s humour and the openness of the participants made it a fun session.
Thursday
There are a lot more interesting sessions on Thursday. Looking at the program the theme for the day is likely to be “Business Analysis” because I think it’s essential and we’re still not getting it right. Unfortunately, that means I’ll have to miss Tsutomo Yasui’s Kanban Game.
More about today’s sessions later.
 Keynote: Alistair Cockburn comes to bury Agile, not praise it
The morning keynote starts with a paraphrase of Marc Anthony’s speech for Caesar’s burial. Agile was an upstart, applicable to small co-located teams. The techniques have now become part of the norm and we’re extending the principles to apply to an ever growing area of projects. Alistair goes back to the themes familiar from his writing:
- Software is like an endless cooperative game with only three moves: invent, decide and communicate
- The speed of development is determined by the speed of ideas spreading
- Craft is essential
- Use Lean processes. Lean production techniques can be applied to design processes: limit work in process, keep things flowing…
- The right process depends on the circumstances. Tools like the Theory of Constraints inform us to design the right process.
- Design is knowledge acquisition: we’re learning about the domain and about the solution.
 Luke has a whole set of Innovation Games to help teams solve problems and be creative. All of these work really well for a co-located team. Two of those, “Buy a Feature” and “Prune the Product Tree” are now available as online tools for remote collaboration.
Buy a Feature helps prioritise by giving player a limited budget to spend on features. Each player can’t buy a feature by themselves, so they have to work together to get their product in the backlog. Prune the Product Tree helps creating a product roadmapĀ by letting players add features on a tree, with different functional areas and time horizons. The different trees can then be overlayed to come up with a roadmap that combines the input of the different players.
This was a presentation only, we didn’t get to see the games themselves. To make it perfect I would:
- Show the games “in action” by having several slides that show (sort of stop-motion) how a game sessions runs
- Make the slides a bit simpler, overload them less with information
I’ve bought the Innovation Games book, some light reading on the plane home.
Steve explained the role and attitude of the facilitator: the facilitator is there to help the participants get the result to want, is neutral and does not have or use authority. Then came a number of characters who represent roles people take during meetings. Roles include the “Gladiator”, who fights everything just for the pleasure of the fight, or the “Orator” who likes to hear themselves talk so much that they can’t stop.
We then played in groups: each of us got to randomly pick one at first and later two cardsĀ with roles on them. We were told to have a discussion on the topic and play the roles we’d picked. Only facilitators made their role known at the start. At the end of each round we had to guess which round everyone had played. In the first round I got the role “yourself”, so I could switch between different roles I usually take. With the exaggerated roles, each round was a lot of fun. Steve then gave us some facilitation tools:
- Interrupt, ask, redirect, commit
- TheĀ starfish
- The circle of questions
- The Margolys wheel
- The Parking lot
More about the patterns, roles, tools and books on Steven’s blog.
A fun and instructive session. To make it perfect I would:
- Have a slightly smaller group: it was hard to hear the conversation with so many conversations going on at the other tables
- Have smaller tables: again, hard to hear each other when you’re sitting far away
- Give the “facilitators” in the game some help or tools to deal with the antipatterns. As the session is structured now, we see the antipatterns in action, then we get facilitation tools to deal with them, but we can’t test the tools and see if they work.
Chris explained the Responsibility Model, a six step model of how we react to a problem and (if all goes well) end up taking responsibility for dealing with the problem. That’s hard, because the reactions are built into our emotional brain. We can’t skip any of the steps, but by being aware of them we can move on faster to more productive behaviour. If we want more leadership and more productive behaviour we have to take responsibility.
Games day
Wednesday is games day. Portia and I run
If you like our games, you can get them from http://www.agilecoach.net and play them in your company, user group or family.
In between our two games, we can go to two more sessions. More about those later.
|
|
