|
|
 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.
This was originally a one-day tutorial, now shortened to 90 minutes. The session started with a round of questions from participants about issues encountered with Business Analysis and the Business Analyst role. For example:
- BA as product owner, but the BA doesn’t own the product nor is directly invested in it
- BA as a wall between development and customer
A lot of the time was taken with basic Scrum items and Steve ran out of time near the end. Takeaways from the session:
- Agile BA principles:
- People trump process: the BA is a facilitator, is there to improve communication
- Inspire the vision: the BA helps align the team behind a common vision
- Do it incrementally: break down use cases into user stories, gradually
- Do it iteratively: the BA as a scrum team member, part of the “pipeline”. Do analysis breadth first.
- User Stories vs Use Cases
- User stories are units of planning, small independent, throwaway pieces. You need acceptance tests to flesh them out.
- Use cases describe how an actor gets value. Break down the problem space in valuable transactions. Permanent memory of the transaction. I do something similar, but I’d rather call them business processes.
I really didn’t like the idea of “demonstrable” features instead of “done” features, as it’s way too easy to have “90%” complete features from start to finish.
To make this session perfect:
- Assume that people know Scrum and focus on the meat of the topic: what does a BA do and especially HOW do they do it?
- Either plan the session around the concerns that participants bring OR have a tutorial with your own agenda, to avoid running out of time
This session introduced the three Throughput Accounting metrics and showed how agile practices (with a wide definition of “agile”) influence the three metrics:
- Throughput: how much value we add per unit of time
- Inventory: how much money is tied up in work in process
- Operating Expense: how much money is being spent regularly to keep the system running
JB’s talk with just a flipchart introduced several agile practices one by one and showed their effect. Some of the practices were illustrated with stories and jokes. There were questions and remarks from the audience, so participants were engaged, but most of the stories got a lukewarm response. That’s probably because we’d all just come back from lunch 🙂
At the end, the important concept of the bottleneck appeared. This tells us where to focus our improvement efforts. If we improve elsewhere we’ll get no effect, at best. We might very well make the situation worse. Come and experience this at our Wednesday morning session The Bottleneck Game: Discover ToC, Agile, Lean and Real Options through play.
To make it perfect:
- Make sure that all points (including the bottleneck) are covered, for example by using a checklist or a list of stories/acceptance criteria that have to be covered in the talk.
- Make sure that all references to studies and results are clear. E.g. “a study I read some time ago” isn’t very convincing.
- Follow this session up with an interactive exercise (like the Bottleneck Game), to let participants see how the ideas apply to their situation, not some abstract agile process.
The most fun and useful session of the day. George and Giora introduce a “battle mapping” technique to better understand how different stakeholders stand in relation to (agile) change. Once we know the lay of the land, we can formulate a strategy to deal with the situation. We need to know who will positively or negatively affect the change and interact with them accordingly. The strategy tells us where to concentrate our efforts for maximal effect, to “choose our battles wisely”.
The session was a good mixture of presentation, fun and interactive exercises. Through the exercise on a real case we saw that this was indeed a useful technique. We’ll continue to work out the exercise to guide some work on a future project.
To make it perfect:
- A battle or army metaphor can be suspect. Emphasise that all of this has to be done with respect.
- Make it clear from the start what the context and limitations of the talk are: this is a tool, like the Theory of Constraints, which tells us two things: where to intervene with the most effect and a general idea of the kind of solution that needs to be found. Knowing how to deal with the different situations is up to the user of the tool and depends on the context where the tool is applies.
Lessons learnt today
- Three session about agile in the real world
- Two techniques (Theory of Constraints and Battle Mapping) to focus our effort in large change projects
Wednesday, play day
Portia and I run two games today:
Therefore, a limited selection of sessions I can go to:
Thursday
Morning
Afternoon
That’s it. For now.
It’s a big list and I’ve probably missed several interesting sessions. By the look of this and the previous list, I’m going to have to miss a lot of interesting sessions. If there are any sessions I really need to go to, let me know in the comments.
This is of course not the final list. I reserve the right to decide at the latest responsible moment which sessions I’ll attend.
Agile 2009: so many choices, so little time
The moment comes nearer when I have to decide which Agile 2009 sessions I want to attend. With so many sessions, the choice is difficult. So, let’s start by making a shortlist.
Monday
Morning:
Afternoon:
Tuesday
Morning
Afternoon
That’s a lot of options!
Many options means I have many choices to get value for money.
As Portia says: “It’s always better to have more options than too few.”
Choosing is for later. First let’s go see some of Chicago and fulfill some of the acceptance criteria of my “tourist” User Story.
TO make the long trip worthwhile
AS A tourist
I NEED to see or do things that are uniquely of Chicago
Acceptance tests:
- Have I seen “Nighthawks”?
- Have I seen one building or exhibition that’s unique for Chicago?
Agile 2009, Chicago 24-28/08/2009
 Next week Portia and I will present two sessions at Agile 2009 in Chicago. And we’ll be attending lots of other agile sessions, if we manage to choose from the massive program.
Besides that I hope to meet agilists from all over the world, see a bit of Chicago and finally see Edward Hopper‘s “Nighthawks“. Incidentally, I discovered Nighthawks after listening to Tom Waits’ “Nighthawks at the Diner“. I wanted to find out more about the inspiration for the album. Tom’s diner is warm and cosy, filled with misfits with tall tales; Hopper’s diner feels as cold as outside and is filled with people who don’t have anything more to say or a place they want to go to.
Both Hopper and Waits are worth checking out if you want to know more about Americana.
I’m not a Bottleneck! I’m a Free Man!
In this game we apply theTheory of Constraints’ “Five Focusing Steps” to improve a simple simulation process. Step by step, we apply Agile, Lean and Real Options techniques to improve the work and its results.
Portia describes some Bottleneck Games we played recently. The techniques we present are really simple and broadly applicable, not just in manufacturing, where the techniques were developed, or in IT organisations, where we apply them most of the time.
After this session you can use the game materials to teach these concepts in your company. After this session you will be able to apply the techniques in your company. After the session, you will see bottlenecks and opportunities for improvement everywhere. You will look at the world differently.
The number of participants is limited to 60, so come to the session on Wednesday 26th of August at 9:00 sharp.
The Business Value Game
The Business Value Game pits 6 teams against each other to achieve the highest possible income by planning effectively. Each team has a limited development capacity and several customers who want their project implemented NOW. By creating a “Business Value Model”, an agreement on the way to value projects, teams can optimise their income without much time. Portfolio and program management doesn’t have to be complex if you’re value-driven.
After this session you can use the game materials to teach these concepts in your company. After this session you will be able to apply the techniques in your company. After this session, you will look at “business value” and project prioritisation differently.
The number of participants is limited to about 50, so come to the session on Wednesday 26th of August at 16:00 sharp.
Ask for help: will you help lead the Business Value Game?
The teams in the game need coaching from someone who’s familiar with the game and its concepts. If you’ve led or played the Business Value Game before and want to help us run the game, contact us.
See you in Chicago!
|
|
