I met Michael Sahota at Agile 2009. Gino Marckx, fellow Toronto agilist, recommended I talked with him.

Michael has created a Scrum simulation based on the XP Game. I regularly get asked if there’s a Scrum equivalent of the XP Game. I’m sure there must be, but this is the first one that I know of that’s published. If you know of any other published, free games let me know.

What I like is:

• One hand drawn overview of the whole process and game. Portia does something similar when she plays the XP Game: one poster with a post-it figure moving from step to step as the team progresses through the game. The poster remains in the team workspace as a handy reminder of the process.
• Making the backlog visible with a story board.
• Changes are republished with a Creative Commons license.

Agile Tour Toronto

I had more discussions with Toronto agilists Peter Yu and Syrous Delavari from Intelliware. Gino, Michael and the guys from Intelliware organise Agile Tour Toronto on October 20th. I won’t be able to attend. If you’re in the neighbourhood of Toronto around then, don’t miss this event. It’s sure to be fun and interesting.

Agile 2009 roundup

I already wrote up the different sessions I attended:

• Agile 2009 report: Monday
• Agile 2009 report: Tuesday
• Agile 2009 report: Wednesday
• Agile 2009 report: Thursday
• Agile 2009 report: Thursday afternoon

Time to do a conference retrospective.

What Went Well

• Chicago (at least the part I saw) is a pleasant mix of big city with plenty of green and lake
• The Art Institute, Field Museum and Museum of Contemporary Art provided several hours of stunning and interesting exhibits. After some searching, I got to see Nighthawks up close
• Mapping the Agile Enablement Battlefield by George Schlitz and Giora Morein gave me a new tool to think about agile enablement in large organisations
• Several analysis sessions in the program shows that we’re interested in finding out out what value our projects can deliver
• Useful leadership and facilitation tools from Steve “Doc” Smith and Chris Avery
• Flirting tips from Ole Jepsen and Jenni Dow to connect better at work
• Lots of games for innovation, push/pull, kanban
• Meeting other participants in the sessions, over breakfast, lunch and dinner and going out for drinks
• Story telling as a coaching, consulting and retrospective tool
• Playing two parallel bottleneck games and seeing happy participants who’ve learned useful techniques while having fun
• The facilities staff were very helpful and thorough helping us to rearrange the room for the bottleneck game. A nicely self-organising team in action.
• The event organisers provided us with rapid feedback: the feedback forms were scanned and emailed to us only a few hours after each session.

What Went Wrong

• We accepted too many players for the Business Value Game, which made it very difficult to come to consensus in each group and made for a noisy and messy session
• The hurried banquet and too long closing keynote
• Too many sessions, especially those about analysis, that consisted of only the presenter talking without any participant interaction or activity. I thought analysis was about listening, involving people and discovering what they value?
• Not being able to meet everyone I’d like to talk with
• Missed the PMI Agile meeting at the Thoughtworks office

Puzzles

• When are we going to stop those blanket dismissals like “project managers are useless, they should all become scrum masters”, “PMI is non-agile”,  “we don’t need analysts, they’ll only lead to lots of useless documentation and paralysis”, “lean is bad because it’s production”, “powerpoint presentations are bad”, “Scrum is evil”, “Kanban is stupid”. Let’s grow up a bit and realise that we’re all fighting against bad project management, bad analysis, bad presentations and unprofessional software development.
• Are Portia and I typecast as “games makers and players”? We also submitted presentations, but the reviewers seemed to prefer “fun games” above “boring presentations”. Presentations don’t have to be boring. I had hoped Jared Spool would prove that, but he spoiled it by taking too much time. Come and see us present the “Toyota Way” presentation at Scandinavian Agile and XP Days Benelux
• What is Agile and where is it going? At the conference we see lots of aspects of Agile in a very fragmented view. What is it that we all have in common? What makes us different from professional engineers?

Learnt

• Less is more. The Bottleneck Game went very well because we limited the scope. There’s so much we could tell about the Theory of Constraints and its consequences. The Business Value Game flopped because we didn’t limit the number of participants and because there are too many elements in the game
• The importance of (business) analysis becomes clearer, as the old techniques help us to discover and define value. Without it, there can be no value-driven work. I’ve been applying agile analysis for years, but it’s only recently that I’ve become consciously competent again and can teach it to others.
• Shorter sessions are useful to get presenters to focus on one idea and present that clearly. And it allows me to apply “the law of two feet” more easily. I’m going to try to make some more focused games and simulations, so that I can explain one concept fully and let participants experience it, in a short session.

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.

Push, Pull, What is the difference by Olla Elnestam

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?

The Kanban Game by Tsutomo Yasui

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.

Beyond User Stories: Identifying Missing Links in Your Product Backlog by Ellen Gottesdiener

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:

• Push, Pull, What is the difference
• The Kanban Game

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.

Telling Your Stories: Why Stories are important for your team by Johanna Hunt and Rachel Davies

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.

‘Flirting’ With Your Customers by Jenni Dow and Ole Jepsen

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.

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.

Leveraging Collaborative Tools with Distributed Customer Teams by Luke Hohmann

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.

Facilitation Patterns and Antipatterns by Steve “Doc” List

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.

“How to Develop Your Leadership Power Daily: An Agile Approach to Growth” by Chris Avery

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

• The Bottleneck Game: Discover ToC, Agile, Lean and Real Options through play (Grand Ballroom A) from 9:00 to 10:30. In the game, we run a simple simulation and then apply the “Five Focusing Steps” to improve the process. Along the way, you can use Agile, Lean and Real Options techniques to improve results.
• The Business Value Game: How to build and use a Business Value Model (Plaza Ballroom B) from 16:00 to 17:30. In the game we run a simulation to experiment with different release strategies. Along the way, you and your team will build up a Business Value Model to get the most value with the least amount of effort.

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.

Agile Grows up: The Agile Business Analyst by Steve Adolph

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

An introduction to Agile Through the Theory of Constraints by JB Rainsberger

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.

Mapping the Agile Enablement Battlefield by George Schlitz and Giora Morein

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

Portia and I run two games today:

• The Bottleneck Game: Discover ToC, Agile, Lean and Real Options through play (Grand Ballroom A) from 9:00 to 10:30. In the game, we run a simple simulation and then apply the “Five Focusing Steps” to improve the process. Along the way, you can use Agile, Lean and Real Options techniques to improve results.
• The Business Value Game: How to build and use a Business Value Model (Plaza Ballroom B) from 16:00 to 17:30. In the game we run a simulation to experiment with different release strategies. Along the way, you and your team will build up a Business Value Model to get the most value with the least amount of effort.

Therefore, a limited selection of sessions I can go to:

• 11:00-12:30 “Telling Your Stories: Why Stories are important for your team” (Columbus GH) by Johanna Hunt and Rachel Davies because I like storytelling and mining stories.
• 14:00-15:30 “The Prisoner’s Dilemma: Applying Game Theory to Agile Contracting” (Grand Ballroom 1) by Simon Bennet because I regularly write Agile proposals and contracts and want to learn and share more.
• 14:00-15:30 ‘“Flirting” With Your Customers” (Columbus IJ) by Jenni Dow and Ole Jepsen because it’s about building a constructive relationship with the customer.

Thursday

Morning

• 09:00-10:30 “Only Dead Agilists Don’t Ask Questions” (Regency D) by Ole Jepsen because it’s an interactive session dealing with difficult Agile questions.
• 11:00-12:30 “May the Forces Be With You, Exploring the Forces Driving and Restraining Agile” (Regency C) by Rod Claar and Douglas Shimp because it’s another interactive session dealing with difficult change issues.
• 11:45-12:30 “Experiments with Agile Contracts in the Real World” (Grand Ballroom A) by Lars Thourup and Bent Jensen because  I regularly write Agile proposals and contracts and want to learn and share more.
• 11:00-12:30 “Beyond features: How to listen to your customers and learn what they really need” (Crystal C) by Lane Halley and Luke Hohmann because it’s an interactive session about discovering the real needs of the customer.
• 09:00-10:30 “Feature Injection A Gentle Introduction” (Columbus IJ) by Kent McDonald and Chris Matts because it’s about the analysis process that identifies value.
• 11:00-12:30 “Role of the Agile Leader in Reconfiguring the Business” (Crystal B) by Israel Gat because it’s about applying the Agile values throughout the organisation.

Afternoon

• 16:00-17:30 “Set-Based Design: Anti-Agile or Agile’s Future?” (Grand Ballroom A) by Bill Wake and Jean Tabaka because it’s about an application of Real Options to software and its interactions with Agile.
• 14:00-17:30 “Build me the Money, Honey!” (Crystal C) by Marina Chiovetti and Julian Boot because it’s about applying agile to making sure we build the right product and generate (and measure) business value.
• 14:00-15:30 “Coach Aikido: Lessons and support for abused coaches in hostile environments.” (Regency B) by Lisa Moore and Christian Gruber because it’s an interactive session about coaching.
• 14:00-17:30 “How to identify and fix problems using Value Stream analysis and A3 thinking” (Crystal B) by Gabrielle Benefield and Tom Poppendieck because I’ve used both techniques and want to learn how to do it better. It’s a three hour session, though.
• 14:00-17:30 “The Distributed Agile Game” (Plaza Ballroom A) by Sumeet Moghe and Jonathan McCracken because I want to see how this game exposes the problems and solutions with distributed work. It’s a three hour session, though.
• 14:00-17:30 “The Kanban Game” (Plaza Ballroom B) by Tsutomo Yasui because I want to see how this game exposes the problems and solutions of Kanban. It’s a three hour session, though.

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.

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:

• 11:00-12:30 “Agile Grows up: The Agile Business Analyst” (Columbus IJ) by Steve Adolph because I believe that an Agile Business Analyst can help find more value.
• 11:00-12:30 “Developing Agile Leaders and Teams: A Developmental & Transformational Path” (Columbus GH) by Gilles Brouillette because we need to form tomorrow’s leaders if we want our agile improvements to endure when we leave the customer.

Afternoon:

• 14:00-14:45 “New Approaches to Risk Management” (Grand Ballroom) by David Anderson because risk management is how we reliably increase our chances of success.
• 14:00-15:30 “Advances in Release Planning” (Crystal A) by Jim Highsmith because most customer want, need and deserve to know “when will it be done and what’s this going to cost me?”
• 14:00-17:30 “Creating Agile Simulations and Games for Coaches and Consultants” (Columbus GH) because I get paid to make games and play them. It is a long session, though.
• 14:00-15:30 “An introduction to Agile Through the Theory of Constraints” (Grand Ballroom B) by JB Rainsberger because ToC is a powerful tool to understand and improve processes, as we’ll show in our Bottleneck game on Wednesday morning.
• 16:00-17:30 “Mapping the Agile Enablement Battlefield” by George Schlitz and Giora Morein because we need to understand the dangers that agile teams face.
• 16:00-17:30 “Team Start-up: one of the first Agile Adoption activities” by Lyssa Adkins because the first few days with a new team can make a world of difference in the end.
• 16:00-16:45 “Giving and receiving effective feedback” by Liz Keogh because I listen to feedback but don’t always hear it.

Tuesday

Morning

• 11:00-12:30 “Don’t Sell Buzzwords to Business Leaders, Learn How to Describe Real Value” (Toronto) by Richard Sheridan and Clement Goebel because I want to get better at describing the value of projects and change.
• 11:00-12:00 “The Beer Game with Agile Teams – MIT Game Theory in Agile Project Management“(Regency A) ‘by Tom Looy because of the mix of systems thinking, lean and agilee.
• 11:00-12:00 “Risk and Risk  Management – Theory and Practice” (San Francisco) by Chris Matts and Todd Little because I want to learn more about the practice of risk management from two different fields.
• 11:45-12:30 “Top Ten Tips for Agile Coaches” (Regency B)  by Rachel Davies and Liz Sedley because I want to share coaching stories with the authors of the Agile Coaching book.

Afternoon

• 14:00-17:30 “Barely Sufficient Portfolio Management” (Crystal C) by Todd Little and Kent McDonald because this seems complementary to our own “The Business Value Game: How to build and use a Business Value Model” game and approach on Wednesday afternoon.
• 14:00-15:30 “Facilitation Patterns and Antipatterns” (Regency A) by Steve “Doc” List because I fear I know more antipatterns than patterns.
• 16:00-17:30 “Diagrams for understanding and improving Agile practice” (Atlanta) by Bonnie Aumann and Arlo Belshee because of the systems thinking approach to understanding and explaining agile practices
• 16:00-17:30 “How to Develop Your Leadership Power Daily: An Agile Approach to Growth” (Regency A) by Chris Avery because I regularly use Chris’s Responsibility Model and this session proposes some new problem solving methods

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?

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!