Agile 2009 report: Monday

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