First, some definitions:

• Abstract: something that concentrates in itself the essential qualities of anything more extensive or more general, or of several things; essence.
• Concrete: pertaining to or concerned with realities or actual instances rather than abstractions
• Precise: definite or exact in statement
• Vague: not clearly or explicitly stated or expressed

Everything you do in a commercial sense has an effect on one or more of these three variables. Here are some examples:

• Bring customers together and discover[1] what they need and desire => will increase Knowledge
• Build some Architectural Runway => will decrease Risk
• Improve a frequently used feature => will increase Customer Value ($$)

But there are some actions that can move more than one variable at the same time, consider:

• A/B testing two features and releasing the winner => will both increase Knowledge and Customer Value
• Address site stability/performance issues => will reduce Risk and increase Customer Value

Alistair Cockburn has been explicitly modeling Knowledge for years, and in fact his writings considerably influenced my thinking on these three variables. See Alistair’s Knowledge Acquisition Curve for more details. Very recently David Anderson has reframed Kanban as a Knowledge Discovery Process.

Risk Management is an extremely underused tool. Usually someone, somewhere, just decides arbitrarily what should or shouldn’t be done.

Customer Value is the important to everyone, but in Agile Scrum projects it’s especially the the Product Owner who is responsible for growing that curve.

Yes, you really can

Design your own visual collaboration game

See these Instant Play games for examples you can use right now. Of course Gist Labs can help you facilitate games, and design your own custom games.

This game especially highlights how teams work together (or don’t as the case may be

Also, it is great fun when I rip the first plane (for not passing acceptance criteria). The collective gasp is always entertaining. I’ve also had people actually ask “You mean they have to fly?!”. Students usually focus too deeply on the mechanics of what’s in front of them that these other big picture concerns completely escape them… until the first acceptance test that is.

The downloads are below for intro slides, airplanes I use, and a pdf of the instructor notes. The next section contains the instructor notes, so that readers can understand how the game works.

Agile Airplane Game – Instructor Notes

Step 0: Materials Prep

• Print 1 copy of each airplane
• Prepare financials chart ($ on vertical, sprints on horizontal)
• Prepare note cards for any “helpers” to take responsibility for parts of facilitation

Step 1: Set the stage

Explain that air shows have become popular spectator events. The demand for planes has increased significantly. Everyone here is part of the “Agile Aviation Company”.

Step 2: Starting details

• Air shows across the country have placed orders for planes, we need to fulfill them.
• Economics: The company has a burn rate of $12 per team, and starts with $40 per team in the bank. Updates are made at the end of each Sprint.
• Pass out supplies (paper, scissors, tape, colored markers)
• Pass out (1 beginner, 1 intermediate) plans to each team – “your initial setup”
• Color code plans and planes (based on available colors) – a stripe is fine

Step 3: First Order, Begin Sprinting

• Every complete delivery of (15 Beginner, 10 Intermediate) planes will be paid $20.
• Give team 1 minute to plan Sprint
• Run Sprint for 4 minutes

Step 4: End of Sprint 1

• Demo to Customer (Instructors)
• Only tell teams about acceptance criteria if/when they ask
• Reject planes (by spectacularly ripping them) that don’t meet acceptance criteria
• Group batches of “done done” planes into orders
• Update financial chart for Sprint 1 based on any completed orders and burn rate

Step 5: Run Sprint 2

• Give teams 1 minute to reflect and plan
• run Sprint 2 for 4 minutes

Step 6: Run Sprint 3

Step 7: Safety Issue, Run Sprint 4

• Pull one Basic plan out (safety issues found in design) – pull the one with most in stock

Step 8: High Value/High Risk, Run Sprint 5

• Pass out (1 advanced) plan to each team
• Offer new order type: $10 for 4 Advanced Planes

Notes for instructors/helpers:

Customer Acceptance:

All folds line up with 3mm tolerance. (Don’t be too stringent).

Each plane if properly color coded.

Each plane is folded properly (no inverted folds, …)

Must fly across 6 foot (2 meter) platform (tables or chairs)

Test Infrastructure:

Setup a stable surface (tables or chairs) about 2m (6ft) wide for the planes to fly over.

Finance:

At the end of each Sprint, after plane acceptance, update the financial chart:

• modify total by: ($ from Completed orders) – $12 X (# of teams)

Downloads

Introduction Slides: AgileAirplaneGame.pdf

Instructor Notes: AgileAirplaneGame-InstructorNotes.pdf

Paper Airplanes I Use: PaperAirplanes.zip

(paper airplanes are from http://www.funpaperairplanes.com/Plane%20Downloads.html)

The responsibility of facilitating the retrospective goes to the Program Chair of Agile Austin, that would be John Heintz. This year John decided not to repeat last years retrospective: although it was very worthwhile, it consisted mostly John doing all the talking and writing (then running out of time .

John asked Austin’s own Jeff Brantley, and trained Innovation Games facilitator, to help and run the retrospective as an Innovation Games activity. Both Innovation Games and inviting Jeff turned out to be a great ideas, and nearly everyone got engaged.

The planning for these games was mostly simple, the Speed Boat and Prune the Product Tree games were clearly the best choices to play. The single challenge was time: the whole activity needed to fit into 90 minutes – making it impossible to first play Speed Boat, then Prune the Product Tree. While Luke Hohmann (the creator! of Innovation Games) was in town as a Distinguished Agile Austin Speaker, Luke suggested that teams could simply play different games. This would give the community some results from both games.

Jeff and John, inspired, decided to go even further: half-way through, teams would switch and finish the others’ game.

In practice this idea worked pretty well. The total group was split into two teams with Jeff facilitating the Speed Boat game and John facilitating the Product Tree. After both teams had slowed down the facilitators swapped the teams (but the games and facilitators stayed in place.) Each team was introduced to the new game and briefed on the stickies placed so far. This had a clear benefit that each team got to absorb what the other was working towards. The amount of new activity was minimal, but some new stickies were added and existing ones newly organized.

Given significant time constraints this technique seemed useful, but it wouldn’t be first choice.

(This is part of the Introduction to CRT article, this expands on the nature and value of tools.)

Tools

Tools get a bad rap, but frankly some of them deserve it. The Agile Manifesto put them in their place:

Individuals and interactions over processes and tools

We need tools though. Really! Tools allow us to spend our time on better things. An electric starter for a car, a spreadsheet, and an IPhone are all tools I’d rather have. We need tools that augment our individuals and interactions. Shu Ha Ri and the Dreyfus Model both describe progressions from practices to mastery.

There is this debate: to teach the ideas(principles) first, or teach the practices(tools) first. I’ve decided that I like to start with the practices, but the ideas must be made available for people to pull in when ready. Some people, those abstract/intuitive ones, will jump to the ideas right away, that’s fine.

Tools must be backed by principles. Kanban is a tool that is backed by Lean’s principals of Flow and Pull. Given the principles behind a tool an individual can learn how to better use the tool, when to use the tool, and even when not to!

Our use of tools that don’t have principles to back them up, or our ignorance of the principles that do exist, prevent us from learning and applying judgement to the use of a tool. Or worse, we make errors of correlation and mandate certain uses of a tool causing serious harm because we’re ignorant of the changing context.

An example of a tool applied without principles is a bug tracking system. What’s a bug or a feature? Should categories be horizontal or vertical? How granular should the bugs be? How many is too many? How often to cull the list?

Most teams never get past arbitrary guessing at these questions. The answers get hard written into process or simply ignored.

(This is part of the Introduction to CRT article, this expands on the nature and value of Reflective tools.)

Reflective

The definition of reflective I use is:

“Of, relating to, produced by, or resulting from reflection.”

Think of driving a car down the highway without being able to reflect on the current road and traffic conditions; that feedback is crucial to being able to successfully navigate. There are many names for this: Inspect and Adapt, Plan-Do-Check-Act, Feedback Cycles, Closed-Loop Control Systems.

In “Managing to Learn: Using the A3 Management Process”, by John Shook, there are two references to wanting the people in your organization to be “reflective problems solvers”. This strikes me as such an important concept that I wanted to mention here that this book prepared me to see “concrete reflective tools” at all during the Kanban conference.

Of course we want reflective, it’s obvious, right? Just having “reflective” alone though can be useless. I think there is a world of difference between an abstract reflective and concrete reflective system. The former requires the expert, the intuitive guide, that can draw conclusions “from the air”. The latter can bring everyone into the fold. Should the WIP limit be 4, or 5? We can reflect on the backlog that occurred last time we expanded the WIP limit and everyone on the team can participate in that conversation. No “black belt” needed.

(This is part of the Introduction to CRT article, this expands on the nature and value of Concrete tools.)

Concrete

The definition of concrete I use is:

representing or applied to an actual substance or thing, as opposed to an abstract quality

The idea is to focus on actual things, empirical examples, quantitative measures and visual or tactile things.

Kanban is a Lean (Toyota Production System) tool being applied to software development. At the Lean Kanban conference in Miami last year I heard three separate people leading Kanban teams say “people who never contributed before started sharing ideas up at the board”. This is huge. Getting people engaged _is_ the big win with any process change.

Kanban has a visual board, like most Agile teams, but includes many more concrete “levers” that Agile visual boards don’t have. How many columns? 4, 5, or 12? How may classes of services? 1, 2, 4? How many Features should be concurrently waiting for Acceptance? 2, 4, 20?

These are extremely concrete questions and answers. Everyone can participate and articulate an opinion about 2, 4, or 20.

Why is concrete so important? Concrete processing is applicable to more of the population. From Myers-Briggs we think we can generally divide people into, among other things, those that are “Sensing” and those that are “iNtuitive”. Studies have shown the following ratio is applicable to the population at large:

S-vs-N: 73.2% is S, 26.8% is N

This means that presenting abstract ideas or conclusions will be less absorbed by most of the population. In the technology fields this ratio is apparently closer.

A related idea is visualization, an important way to make things concrete. See the Periodic Table of Visualization Methods for reference.

I’m very excited, both to be presenting with Israel Gat (The Agile Executive) and to be going to Agile Roots this year!

We’ll be presenting on Toxic Code. This is a topic that I spent a lot of time on last year, working with a client to re-architect a system from the inside out while it was running in production.

Here’s the abstract of the session:

Technical debt had originally been conceived as an expediency measure – “a little debt speeds development so long as it is paid back promptly with a rewrite.” However, like financial debt, unrestrained borrowing can lead to a broad spectrum of difficulties, from collapsed roadmaps to inability to respond to customer problems in a timely manner, and anything in between.

Recent advances in source code analysis enable us to quantify technical debt and express it in $$ terms. By so doing, the software development process can be governed with unprecedented effectiveness. It is possible to constrain the “development on margin” mal-practice and avoid the toxic code phenomenon: technical-debt-to-value ratio of 100%. Moreover, even toxic code can ultimately be “marked-to-market” by reducing/eliminating technical debt.

The combination of Agile refactoring practices with technical debt analytics brings rigor to the software development process through:

• Providing quantifiable data about the overall state of the code and its value
• Driving the refactoring carried out through the Agile process from a risk mitigation perspective
• Balancing the technical debt work stream vis-a-vis other work streams

In the course of managing software development in this manner, your team will improve its design, coding, testing and project management skills. Ultimately, these improvements are the best antidote against accrual of technical debt in the future.

Since I attended the Lean Kanban Conference in 2009 I’ve been focussed on understanding and finding more tools that fit the following criteria. This is my first time recording the thought on more than a note card (or cards… I keep scribbling down more variations.)

In this post I want to describe the basis for what these tools are, and reference some of the reasons they are so powerful. I’ll use Kanban as my running example, and plan to describe further tools in future posts.

Concrete Reflective Tools  

I believe that “Concrete Reflective Tools” are the most useful and powerful change agents – they are easy to adopt, encourage learning from doing, and provide a path to deeper principles. I think they are a gateway drug that invite people into participating in the team learning process.

A Concrete tool is a not abstract (think naval gazing) and immediately can be at least rudimentarily applied by many people.  (Read more…)

A Reflective tool is one that provides feedback to guide further use of the tool. An automatic thermostat both measures and adjusts the temperature, providing a closed-loop feedback system. (Read more…)

The Tools we are interested in are backed by principles. Getting from a practice to the guiding principles behind it offers immense leverage. (Read more…)

Why do other tools fail? A good idea (like a principle) can be too abstract and never acted on, a tool without thought is inappropriately applied, and thoughtful tools without foundation grow stale without change.