Team Reward Systems in Agile

This post has moved HERE.

Thanks,

Dave

Effort Estimation is Child’s Play

Our schools are teaching Agile techniques to 2^nd graders.

My 2^nd grader asked my wife for help with his math homework. As soon as she heard the word "math," she said "go ask your father." He brought it over to me. They are learning about weights and measures and how to use scales. He showed me his homework and said "dad, I don't get it. What is this?" I looked at it and smiled. "Well," I said, "that's what dad teaches grown-ups to do every day at work. You're learning about effort estimation."

Here is his actual homework sheet:

Each example gives you choices of absolute measurements (pounds), BUT you don't have the tool to weigh each object. Instead, you're relying on past experience and knowledge to estimate the weight. Have you ever held a baby? Probably, and even if not, you know they are a lot closer to 8 pounds than 20 or 70 pounds. And while you've certainly never weighed an elephant, you know from your visits to zoos and circuses that they are huge, and your experience with objects that weigh 100 pounds or 500 pounds tell you that an elephant is certainly much more than that, so given the choices, 11,000 pounds is easily the right answer.

This is essentially what we do with effort estimation in Agile product development. We are asking team members to measure how much work is required to complete the product feature, not how long the work will take. And the measurements are not on an absolute scale, they are on a relative scale, meaning "how much work is this item, relative to the amount of work the simplest item you can think of is?" When we start using effort estimation (BTW, a.k.a "story points" or "effort points") we have teams baseline on a common simple activity in their domain, and use that as the base measure. After they agree on what that is, all other features are measured relative to that baseline.

Many, if not most, Agile teams use a numerical scale called the Fibonacci scale to measure effort. The Fibonacci scale is named after Leonardo of Pisa, who was known as "Fibonacci" (son of Bonaccio). He introduced the concept to the West in the early 11^th Century. These are the typical Fibonacci numbers used for effort estimation:

1, 2, 3, 5, 8, 13, 21, 40, 100

Without getting into a doctoral dissertation in mathematics, let's just say it gives you a scale with steps that increase in magnitude as you go up, so when you have to decide between two of the larger numbers, it's not so fine grained. Seeing it graphically really helps. Here is a "Fibonacci spiral" which you get by making boxes with areas the same as the Fibonacci numbers, and drawing circle arcs corner to corner, and connecting them:

And where else have you seen that shape in nature?

The increase in step values forces you to choose the closer "bucket" rather than argue over minutiae. And that's why it works so well in effort estimation…it forces you to "pick one!" and not get bogged down in the details, which is the point of effort estimation…the right amount of detail at the right time. We use it early on in the process, before you can know all the detail you would need to know to get down to estimates in hours.

Pick Your Measure

Here's one of the great things about effort estimation in Agile…you don't have to use Fibonacci. It's hard enough, when we're used to a professional lifetime of giving estimates in hours or days, to mentally switch to measuring effort. If your team is having a hard time with Fibonacci, and divorcing a numeric measure from absolute time measurements, don't use it. It's only important that your chosen measure has relative sizing that the whole team can relate to; it doesn't have to be numeric.

Teams have used T-shirt sizing for effort estimation (Small, Medium, Large, eXtra Large). I'm coaching a team right now that uses sea life: guppy, salmon, dolphin, shark, whale, Kraken. ("Release the Kraken, Jim!"…props to you). I even heard of a team that measured stories in "Frito bags." Why? They baselined a 1-Frito bag story on the amount of work it would take this one developer (who ate Fritos all day, every day) to complete while eating one bag of Fritos. You really can use any scaling method like that.

But in the end, remember to focus on simplicity. Effort estimation doesn't have to be difficult, They are teaching the concept to 2^nd graders.

As always, I welcome your comments.

Planting the Flag – The Power of Vision

If I asked a random member of your organization to state the goals of the organization for this year, could he or she do it? Could they name even one goal? What if I asked "how does what you're doing today advance a strategic goal of the company?" If their answer is "I don't know" or, even worse, "I don't care," we have a problem. Not a problem that will keep you from being good, but one that can prevent your organization from being truly great. What is lacking is a Vision.

Architecture of a Vision

So what do I mean by a Vision, and why does it matter? I'm not talking about a mission statement, I'm talking about a goal…but it's more than that. To be effective, a Vision should have the following characteristics:

SIMPLE

"Any fool can make things bigger, more complex... It takes a touch of genius-and a lot of courage-to move in the opposite direction."  - Albert Einstein

"Simplicity is the ultimate sophistication." - Leonardo da Vinci

A great Vision statement should be clear and simple. You shouldn't have to be an industry insider, or a senior executive, to decipher it. So we don't want a statement such as "Develop, deploy, and manage a diverse set of scalable and strategic knowledge management tools to serve our customers, improving the possibility of overall satisfaction among our diverse customer profiles." There's a lot wrong with that one, not the least of which is it's not simple. How many tools do we need to deploy to be successful? What does it mean to "improve the possibility of overall satisfaction"? Is it enough that it's possible that our "customer profiles" will be more satisfied, even if they're not actually more satisfied? As an employee, would you be able to tell when you had achieved the goal?

MEASURABLE

"The focus of subjectivity is a distorting mirror." - Hans-Georg Gadamer

Effective Vision statements describe a goal that can be measured. We can tell objectively whether or not it has been achieved. They should also have a deadline or target date. Open-ended, nebulous statements with, at best, subjective success criteria make it impossible to tell whether or not the organization has achieved the vision. Here's a good example of an immeasurable vision statement: "To experience the joy of advancing and applying technology for the benefit of the public." Simple, yes…but measurable? How would you measure the "joy" of a company? And the goal is to "experience the joy"…so if we experience it, and don't sell much product, have we achieved the goal?

INSPIRATIONAL

"Make no little plans. They have no magic to stir men's blood..." - Daniel Burnham

"If you have built castles in the air, your work need not be lost; that is where they should be. Now put the foundations under them." - Henry David Thoreau

Bold, inspirational Visions move people and organizations to push the envelope. Some of the very best ones set goals that may even seem somewhat impossible at the time they are presented. In 1987, Apple produced this video illustrating their vision of what computing in 2010 could be. It is a concept called the "Knowledge Navigator," a tablet-type device presenting amazing power for the user to interact with the device through speech recognition, research data from multiple sources through an integrated multimedia search engine, simultaneously accept and make voice and video calls, manage appointment calendars, etc.. To put this vision in perspective, 1987 brought us the following advances in computing: Windows 2.0, the introduction of Microsoft Works, and the creation of VGA. To say the Knowledge Navigator seemed "somewhat impossible" in 1987 is probably an understatement, but what do we have in 2010? We have high speed wireless internet, cloud computing, and the iPad.

The Connection in Agile

So how do we tap into the power of a Vision in Agile practices? Once we have a leader who establishes the simple, measurable, inspirational Vision, try creating a "Vision Backlog"…analogous to a Product Backlog, a Vision Backlog can be created and revisited quarterly or annual basis by senior management, and contain the same elements as a product backlog item: the clear statement of the goal, acceptance criteria so everyone knows how to tell when that goal is met, and effort sizing to measure how much effort each item will take to complete, relative to the others. A Vision Backlog could have even just two or three items in it. Then, we can tie product backlog items to vision backlog items, assuring the product features we build serve a strategic vision of the organization. Break those product backlog items down into tasks and hours for a sprint, and you have a chain of evidence from the task to product backlog item to vision backlog item of how much work, and time, it takes to realize that vision.

The Perfect Vision

I have given a few examples of Vision statements that are sub-par. So has there been a "perfect" vision statement? On this 50^th anniversary month of John F. Kennedy's inauguration, I would say he takes the award for the most perfect Vision statement in at least the last 100 years:

"I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." – John F. Kennedy, May 25^th, 1961

The statement is simple. Everyone in the world could understand what it meant.
The statement is measurable. It's very clear that if we landed one man on the moon, and returned him safely to Earth, before January 1, 1970, that the goal would be met.
The statement is inspirational. It's hard to imagine a more impossible, incredible goal than flying a human safely to another heavenly body for the first time in history.

Yet ordinary people followed that vision, that "castle" that JFK built in the air. They put the foundation under it, planted the flag on lunar soil, and achieved the goal.

Bravo, Mr. President. Bravo.

A Manifesto on Problem Solving

I have a natural tendency to be a helper, a problem solver. It drives my wife crazy when I try to solve her problems and she "only wants me to listen." I've long considered the question "what are my essential elements to effective problem solving?" What follows is my distilled "Manifesto on Problem Solving." I strove to keep it simple, straightforward, focused, and easy to remember.

1. DON'T SOLVE PROBLEMS THAT DON'T EXIST
   
2. SOLVE THE PROBLEM, NOT THE SYMPTOM
   
3. CONTINUALLY TRIAGE
   
4. SEEK THE SIMPLEST SOLUTION
   
5. MAINTAIN THE VISION
   
6. START EVERY SOLUTION WITH THE INDIVIDUAL: YOU
   
   

To explain in detail:

1. DON'T SOLVE PROBLEMS THAT DON'T EXIST
   It sounds obvious, but it can be easy to forget and can be a temptation for those of us that enjoy developing "cool" solutions. Before I delve into lengthy and possibly expensive solutioning (in time and money), I want to make sure the problem I'm trying to solve really IS a problem. Especially if you're in the business of developing solutions, this is critically important, even to the point of being an ethical imperative where spending your client's money is concerned.
   
2. SOLVE THE PROBLEM, NOT THE SYMPTOM
   Make sure you're finding the real problem, not just what initially is presented as the issue. This can take a bit of critical thinking and investigating, but can be done rapidly in conversation. I see a breakdown in this area often in organizations, especially when the root cause may be difficult to confront, e.g., an organizational culture issue rather than a process issue. One of my favorite models for this root cause analysis is the "Five Whys" of Sakichi Toyoda. Keep asking "why" each symptom happened until you reach the root cause.
   
3. CONTINUALLY TRIAGE
   Always ensure you're solving the most critical issue now. The triage concept originated with French Army field medics in World War 1, and has undergone many evolutions since then, but the original elements are the same and can be applied metaphorically to any problem situation. A more modern version for use in catastrophes categorizes patients (in order of triage importance) as:
   1) those most in need of immediate care,
   2) those whose required treatment can be delayed,
   3) those likely to live, regardless of treatment, and
   4) those likely to die, regardless of treatment.
   Translated to business problems, this can be done by quickly bucketing problems into: "Now", "Next", and "Someday." Continually triaging, and prioritizing within each bucket, is the key.
   
4. SEEK THE SIMPLEST SOLUTION
   My best friend is a sage in this area. I went to him one time in college because my elbow was hurting when I moved in a certain way. I said "it hurts when I do this." His response: "Well then don't do that." SIMPLE. Humans naturally add detail to anything. We find simplification far more difficult than elaboration. The simplest solution to a problem is often the easiest to implement, and will keep you focused on solving the problem rather than finessing the solution.
   
5. MAINTAIN THE VISION
   Never lose sight of the goal, the vision of what you, your system, or your organization is trying to accomplish. Post it somewhere visible. Begin solutioning every time with the question "does fixing this problem serve our goal(s)?" If not, put it in the "someday" bucket.
   
6. START EVERY SOLUTION WITH THE INDIVIDUAL: YOU
   When you follow this tenet, problems will be solutioned at the most basic level possible and have the best chance of remaining targeted and simple. Think about your home life: if you have a clogged drain, are you going to call the federal government for help? Of course not, that would be ridiculous. You're going to go to the store and buy drain cleaner, because you understand that's all you need. (Although if you did ask the government for help, you might see a costly commission convened to study the curve of drain piping and its effect on debris-filled water flow contributing to clogging. Maybe new regulations for plumbing would be enacted.) If you don't have the means to solve the problem, then and only then escalate it to your boss, or your municipality. Performing the same means check at each successive level will ensure that the only problems that bubble to the top of the hierarchy (like national defense to the federal government) will be those that truly must reach that level to be solved.
   

What tenets for effective problem solving do you ascribe to? Do you have something to add to the list? As always, I welcome your comments.

The Psychology of the Sign Off

This post has moved here.

Thanks,

Dave