Author Archives: John Heintz

Abstract != Vague

Posted on by
Reply
(I’ve re-published this here. Originally published on my old personal blog).
I’ve got a bone to pick, so I’ll do it here. This is a problem of mine that I have with both developers(architects) and with analysts(customers).
Context: This rant applies to models/designs/architectures of a problem or solution domain. It doesn’t apply to the actual coding of a solution (much).

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
Here’s the picture:
What does this mean?
Analysts tend towards Abstract-Vague. “Let’s not get bogged down with details right now.”
Developers tend towards Concrete-Precise. ”I need all of the table properties fields.”
Fortunately, almost no one tends to Vague-Concrete. Phew.
Un-fortunately, few move towards the most valuable region: Abstract-Precision. That’s the most valuable because it offers the least noise (Concrete details) and the most information (Precision).
Here’s an example. Squares are types, circles are interactions.
Notice that “Money” isn’t concretely defined here. It could be a BigDecimal, double, or Smalltalk Number. Also, that Post Condition is much more precise than a lot requirements documents usually specify.
Ah, I feel better.
Here’s my rule of thumb for achieving more precision:

Add elements to your model only in order to exactly say what your audience thinks is really important.

In the example above the balance, amount, and cash properties are only present because a Withdraw requires them to precisely describe what needs to be done.

Business: Knowledge, Risk, and Customer Value

Posted on by
Reply

What do knowledge, risk management, and customer value have in common? Only your business value, and here’s what it looks like:

 

Business Knowledge, Risk, and Customer Value

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

This chart provides a way to prioritize an organization’s backlog of work by asking the following questions:

  1. What are the current values for Knowledge, Risk, and Customer Value?
  2. Which way are they heading? 
  3. What ought they be?
  4. What next steps will bring me closer to what ought be?

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.

[1] Consider playing “serious games”, see Innovation Games

 

 

Agile Airplane Game

Posted on by
Reply

This is the multi-team airplane game that we use to introduce Agile through games.

This game especially highlights how teams work together (or don’t as the case may be :)
Some of the interesting results I’ve seen is that this exercise acts like a mirror showing teams how they respond under pressure. The way the teams coordinate in this exercise seems to reflect their actual working style.

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)

Tools, the T in CRT

Posted on by
Reply

This article expands on Tools in a Concrete Reflective Tool. We can start learning tools, but there must be a path to the principles that underly them.

(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.

Reflective, the R in CRT

Posted on by
Reply

This article expands on Reflective in a Concrete Reflective Tool. Tools that help us learn from their use give us tremendous opportunity for growth.

(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.

Concrete, the C in CRT

Posted on by
Reply

This article expands on the Concrete in a Concrete Reflective Tool. Applying concrete tools is a good way to avoid alienating over half of your audience.

(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.

John Heintz co-presenting at Agile Roots 2010

Posted on by
Reply

John Heintz will be co-presenting with Israel Gat on Toxic Code.

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.

 

 

 

Concrete Reflective Tools, the beginning

Posted on by
3

This is my first post describing Concrete Reflective Tools. I’m convinced they are a gateway drug to continuous improvement and cultural change.

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.