Consulting and Training in Fluid, Scrum, XP, and all things Agile
I am sometimes asked “What metrics can we put in place to know that our people are doing a good job?”
They never like my answer. I just want three metrics to start:
1. Are our end users happy?
2. Are our customers (the people paying the bill) happy?
3. Does our team have joy?
They look at me like I am insane.
“That is not nearly enough.” They reply emphatically, “We measure 100s of things. You can’t manage it if your can’t measure it!”
“I agree.” I reply.
“Stop managing and start leading.”
With additional attention comes additional clarity.
Complexity is the core question, as discussed recently. But what are the choices? Turns out there are three basic answers. One I already discussed, but the other two are better understood in a different way.
How complex is your system?
Is it a simple system? Handle things with simple answers. Individual experts, working largely independently, with bucket lists and goal targeting.
Is it a stable system? Handle things with stability reinforcing answers. Plan your projects. Manage to the plan. Work by schedule. Define processes and tasks.
But what if it’s a changing system? Then handle things with answers that leverage change. You can’t manage the group, you need to rely on natural social systems (tribes). You can’t guide with plans, you must use feedback. You can’t schedule, you have to prioritize. You can’t define processes and tasks, you have to build ceremonies.
Simple, Stable, or Changing? That’s your question. Use the right system for the right problem.
Recently I was asked about EVM, specifically CPI and SPI, for Agile projects. The question stopped me in my tracks because …. it makes no sense. Why would I collect metrics that estimate my progress when I can prove actual progress by delivering working software every iteration (sprint)? I’ll outline my thoughts in this post to show why EVM makes no sense for Agile.
First, EVM was developed by the US Government in the 1960’s to solve a particular problem. They had many large, multi-year Waterfall projects with outside vendors and no visibility into progress. Because there was no way to measure how much of the product was complete (Waterfall meant they got everything at the end), if they stayed with Waterfall, the only thing they could measure was the progress of the project. EVM is based on a fundamental assumption that we can plan everything up front, and therefore if the project progresses as expected, then we will get the product we paid for.
Let me be very clear. EVM treats the project as the deliverable and measures progress of the project. EVM in no way measures completion of the product, which is what we are actually delivering to the customer.
The fundamental assumption on which EVM is based is (in many cases) not a valid assumption. In many cases we cannot plan all the work up front. Also, we all know of projects that progressed exactly as planned, but the delivered product was a failure. The project succeeded, the product did not.
But let’s be fair. As long as the choice for software development is Waterfall, there really is no other way to measure progress.
Agile gives us a fundamentally different approach. We can still measure plan versus actual, but we measure a different plan against a different actual. We measure the user stories selected for the iteration (sprint) against the actual software we completed. Does the delivered software do what the user stories said it must do? We measure the actual benefit received by real users using the real software against the cost of developing the software. Do the actual benefits match what we expected? Is the cost reasonable compared to the benefit? Should we continue investing in this product?
Agile answers the question the customer really cares about:
Did I receive the right product at the right time for the right cost?
Our customers do not care about how well the project went. They don’t see projects. They see products. They see what the product does, they see what the product costs. They want the product when they need it, not 6 months from now.
I’ll close this by illustrating with a scenario. I have 2 projects with 10 people each, with an average labor charge of $100 an hour. Each project is expected to cost $1,000,000 and complete in 6 months.
Project 1 is Waterfall. The project plans calls for the requirements phase to be completed after 2 months for a cost of $330,000.
Project 2 is Agile (of some flavor). They are doing 2 week iterations (sprints). Each iteration (sprint) should cost $80,000 if everyone is billing full time to the project. The first two iterations (sprints), the team expects to complete work that has an estimated benefit of $400,000 a year by saving 80 hours a week of labor time on a task performed by 40 people in the company (2 hours per person).
Project 1 completes the requirements phase in 7 weeks for a cost of $280,000. Everyone is happy. We are ahead of schedule and spend, so the project continues.
Project 2 completes the two sprints. The software matches what the user stories described. The team spent $90,000 (they had to call in a specialist to fix a weird problem). The software is given to 10 of the people who will be using it. The users save on average 1 hour per week using the new software. The cost was $90,000, the benefit is only $200,000, but still a good ratio and the users are happy. The new software is released to all 40 users. Based on lessons learned, the team reviews the cost and benefits of the next user stories to see if there is value in continuing.
If I look at EVM for Project 2, we completed what we planned, but we have overspent. The users are already using the software and receiving enough benefit that it was worth the cost. We have this information 1 month into a 6 month project. We can choose whether or not to continue spending money.
EVM for Project 1 looks better. We are on schedule and budget. But we have no idea if we are doing the right thing or if the benefit will be worth the cost. We will not know this for another 4 months. We have no basis for deciding if the cost is worth the benefit or if we should continue spending money.
We’ve run through a couple models of analysis on the nature of Agile/fluid systems. Specifically, we’ve looked at that Method Grid, and then recently, we were trying to address which question needed asked. I think we’ve made a breakthrough in our analysis.
Question: Why is it that Hero and Director are more natural states than Messiah and Wedding Planner?
It seems as if there’s some natural synchronicity between Independent work and Individual responsibility, and also a natural synchronicity between planning and management.
Perhaps calling them out as separate axes is not the right thing to do…maybe there’s a deeper, underlying question, which is being answered in the same way on different axes that leads to this synchronicity. And once we looked, we did indeed find that to be true.
The new claim: There is one question at the heart of Agile. The Agile manifesto gropes blindly for the question, but seems clearly to be looking for it. The fluid principles are each a manifestation of the Agile question, in a different domain. What is the question?
Q: How do you handle complexity?
And at that same deep level, there are three basic paradigmatic responses.
Paradigm 1: Simplicity.
A: We don’t. Our problem isn’t that complex.
Why do startups run in a profoundly different fashion than large companies? Because their problems aren’t big enough yet. They’re applying simple solutions (frequently from a brilliant insight) to simple problems. In applying simple solutions to simple problems, they don’t address complexity at all. And that’s wonderful. For the domains that it works in.
Paradigm 2: Control. (aka Mechanical, Resisting, Rigid, Structured, Design, Managed)
A: In the face of complexity, we attempt to control it.
Once problems become difficult enough, the Simplicity paradigm is insufficient to handle the problem. We design a complexity management system. More than a couple dozen people in an organization, and the group dynamics need management. More than a couple dozen modules in your code, and you need to start doing design. More than a couple dozen weeks in your project, and you need to lay out a plan. More than a couple priorities, and you need a schedule. More than a couple risks, and you need a process. Everyone knows this system, as every large business we’ve seen has followed this mode.
Paradigm 3: Fluid (aka Biological, Accepting, Organic, Nudge)
A: In the face of complexity, we travel with it.
At some point after problems become difficult enough that the Simplicity paradigm is insufficient to handle the problem, so too is the Control paradigm unable to handle the complexity of the system. Nature is complex enough we cannot direct it. Rather, we need to work with nature, rather than against it. In the southwest USA, build from brick and adobe to handle the heat. In California, build flexible, wooden structures to handle the earthquakes. In Galveston, build on stilts, to handle the Surges. Nature will not be commanded…but in flowing with nature, we can get some of what we want.
In the face of hundreds of people in an organization, we need to abolish the formal organizational structure that fights nature, and instead allow natural social systems to emerge. Tribes sit at the 150-person level. Hunting parties are near 10. Pairs work together naturally as well. Natural social systems don’t sit well with authority.
In the face of thousands of components in a system, and fluid requirements, we need to abandon the notion that a design will capture what we need. Rather, we need test-driven design and an aggressively maintainable system in order to build good enough architectures to survive the natural change cycle.
In the face of hundreds of competing priorities, we need to abolish the formal method of scheduling, and focus instead. Biological systems like human beings and human organizations have limited bandwidth. Scheduling 6 things at once doesn’t get 6 things done faster. Rather, it usually means that at least 5 things get done slower than they would have, and usually aggressive prioritization/queuing/focus gets 9 things done faster than 6 things in a scheduled fashion.
In the face of innumerable risks, process cannot save us. We need a better answer. A natural, flowing with human patterns instead of against them answer. The answer that gets us there is ceremony.
In the face of more than a couple encounters with changing reality, planning systems crumble under the weight of replanning. Instead, we need fluid, biological responses to changing conditions. We need the ur-mechanism for responding to reality. Feedback systems are the only answer.
There is only one question:
How complex is your problem?
If you have easy problems, a simple paradigm can solve them.
For mildly difficult problems, the control paradigm is standard because it handles them.
But for the actually hard problems, fluid systems are the only answer.
It’s interesting also to consider how many problems fall into the moderately difficult category…and how much overlap there is between the problem-solving capacity of control vs. fluid systems? How many problems can control solve (well) that fluid can’t?
As our understanding of Fluid approaches improves, we’ve come to see more and more that it isn’t just the answers to traditional questions that are wrong, but rather it’s almost always the wrong question being asked as well. And when you ask the wrong question, the right answer is nearly impossible. It’s as if we’re discussing wealth with a mathophobe and they ask us the question, “If I want to get rich, what should I do with my life savings? Should I go to Vegas, should I play the lottery, or should I invest in high volatility derivatives?”
The answer is no. Wrong question. You get rich by investing other people’s money. And you don’t do it in the lottery, vegas, or bankruptcy-immune derivatives. Now…I’m not exactly rich, so I don’t have enough to say here…but I can tell you with confidence that with the question being so wrong…the answer can’t be right.
And so it goes with decisions in the business world. Almost every question you’re asked will be the wrong question. Which of course makes the answers insane.
What questions do we need to fix?
How can we get the right answer to our questions? Should we rely on experts, or should we rely on careful planning?
No. Wrong question. The right question is:
How do we find out where we’re wrong faster?
Feedback systems.
————-
How do we assign responsibility to individuals to get work done? Responsibility to the individual, or responsibility to the manager?
No. Wrong question. The right question is:
How do we assign responsibilty to groups?
You build a tribe.
————
How do we determine what is important? Should we work in an interrupt driven (scheduled) system, or should we build bucket lists?
No. Wrong question. The right question is:
How do we determine what to do first/next?
Work from a queue.
——————
What existing business feature should we trust to bring us good results? Should we trust the individuals and relationships? Or should we trust our metrics?
No. Wrong question. The right question is:
What system should we build that we can trust?
Ceremony.
———————
The old questions are the wrong questions. The old answers are nuts.
The new questions, with answers:
How do we handle error? Feedback
What gets responsibility? Tribe.
What do we work on? Queues.
What can we trust? Ceremony.
Finally, some good questions.
On the final day of Agile 2013, I led a crowd sourced mini-workshop/discussion on Agile pain points. In this post I’ll summarize, with a goal to get into more details over the coming months.
I posted large easel pad sheets on the wall and wrote names of company departments on each sheet. Then I invited the audience to take sticky pads and write their particular pain points and post them under the department causing the pain. After a few minutes, I handed out strips of 8 dots to each participant and invited them to vote on the things that were their biggest pin points. They could use all 8 dots on one, one dot on each of 8, or any variation in between.
A helper reviewed the sheets looking for high numbers of dots. Then we discussed those highest pain points until we ran out of time.
I am still transcribing my recording of that session for notes. But below is the list of departments, pain points, and number of votes for each. 14 people participated in the writing of pain points and voting. Note that things with zero votes are still pain points; they just are not as painful as items with more votes.
What are your pain points? Do you have others?
Geri
The theory of using Ritalin in schools goes like this:
Therefore:
The problem is that the conclusion is false. Recently, scientists figured out that Ritalin is not actually effective at improving grades.
Why is this? Ritalin supports the standard schooling model very well. If students can’t sit still and listen, what should we do? Ritalin is a very simple answer: Give them a drug that allows them to sit still and listen.
What can explain then, the failure of Ritalin to improve the grades of the students? There are several explanations available, but few of them look especially good for the standard learning model, and none of them look good for the use of Ritalin.
If we have a syllogism with 4 premises and a conclusion, and the conclusion turns out to be false, then so too must one of the premises be false.
For the purposes of this discussion, I think that we don’t need to worry much about premise one’s truth. It is also pretty well established that ADHD prevents kids from sitting still and listening, and that Ritalin allows ADHD kids to sit still and listen. That leaves only one premise to address*, which is almost certainly wrong:
But, someone might object, this is a foundation of our entire school system, and most of our training in the corporate world. Indeed it is. And that’s a pretty big problem.
Let us suggest instead a different model of learning.
There are three domains which we interact with in our learning process:
Or, because I’m suggesting that the listening/reading thing isn’t good enough, let’s get a picture:
The original tree is the territory.** What someone sees looking at the world. That is translated via some process into some sort of mental map of a tree for the original observer. Then, the original observer communicates something about what he’s understood to a listener “Tree”. Then, if all the stars are aligned, the listener builds his or her own mental map of what was communicated.
The problem is that this system is designed to communicate mostly old stuff. It kinda sucks for communicating novelty. And the learning process is about the communication of information and methods that are new to the listener. Somewhere between the business of translating from the map into words and the business of translating from words back into a map, there is usually a failure.
While this in itself would be sufficient to explain the failure of Ritalin, we can take it further.
An awful lot of the time, this is not a picture of what’s happened. It’s more like this:
There’s usually an intermediary between the discoverer and the listener. Oftentimes the intermediary doesn’t even do the real translation from map to words. Rather, they encode the words. And that’s where we get real problems.
Human beings have the capability to encode words. They also have the ability to build maps. But basically people can’t build good maps from words. And you can’t do anything with your words except repeat them until you have a map. Unfortunately, 20 years in teaching, and nearly that many more in school says that the business of going from words to map is effectively non-existent.
Ticking upwards to close: What can we do about it? As educators, we can focus heavily on what a student can do rather than what words they can say. As Agilists, we can keep our meetings small and participatory. Anyone not talking is out if it’s more than 10 minutes. And as learners, we can focus on our ability to really understand by doing, rather than keeping a set of words in our heads.
* It could also be true that Ritalin prevents learning another fashion, independent of sitting still and listening.
** Yes, the whole diagram constitutes something sitting somewhere between words and map. It’s clearly not words, but it’s an attempt to communicate my map to you.
It is really exciting what science is discovering about our brains and what it means for how we get along with each other in the world. For example, consider introversion and extroversion.
We all used to think that extroversion meant you got your energy from being around people and introversion meant you got your energy from being alone. That turns out to be a simplistic way to describe it.
Here are new descriptions of introversion and extroversion based on current scientific research captured succinctly in this article from Benzinger titled “The Physiology of Type: Introversion and Extroversion”:
Our arousal level identifies the amount and speed of our brain’s activity. …
Extraversion
Having a naturally low level of arousal which causes the individual to seek higher than normal levels of stimulation in order to “feel alive.”Typical ways in which the extravert seeks stimulation include: trying to influence or control his or her environment; confronting others; engaging in competition; attending crowded parties or events “where the action is.”
Introversion
Having a naturally high level of arousal which causes the individual to seek lower than normal levels of stimulation in order to not feel overwhelmed.Over a period of years, this need to not be overwhelmed by external stimulation develops into an internally focused thinking style which may seem withdrawn, meditative, quiet, or even reclusive to more extraverted person. Typical ways in which the introvert seeks to control the level of stimulation include: spending time reading, reflecting, or otherwise alone; avoiding or being accommodating to others; competing mostly with oneself or self image; going to small parties or out of the way places.
An obvious way for a person to get more external stimulation is to be around a lot of people. That is where we get the idea that an extrovert needs to be around other people and an introvert wants to be alone. But other ways of increasing external stimulation include multi-tasking, playing music while doing other things, or engaging others in debate or argument.
So if extroverts want to increase external stimulation, then they should like multi-tasking, playing music at work, and being argumentative. And if introverts want to decrease external stimulation, then they should hate multi-tasking, playing music at work, and being argumentative. These statements both turn out to be true.
Now what about shyness. Shyness (or the lack of it) just refers to a person’s comfortableness with other people, particularly with strangers. A person who is shy is very uncomfortable around strangers; in the extreme case, a shy person literally cannot talk with strangers. On the other end of the scale is the gregarious person who enjoys chatting with complete strangers; in the extreme case, the gregarious person looks for people to chat with everywhere.
So now think about shyness and type. There are four combinations:
Obviously shyness is compatible with introversion. One way to reduce external stimulation is to not be around people. And gregariousness is compatible with extroversion. One way to increase external stimulation is to be around a lot of other people. Those folks have it easy.
The challenges are for the gregarious introvert and the shy extrovert. And yes they exist. I personally know people in both those categories.
The gregarious introvert after spending time chatting with people all day at the office will need time alone in a quiet place to recover balance. A gregarious introvert may turn to alcohol (a depressant) to reduce the level of stimulation to manageable levels. Maybe you know someone who just needs that glass of wine or martini after a day at the office. Maybe the custom in your house is for the wife to take the kids off to make them dinner, while the husband sits quietly in his chair in the dark with a drink for an hour before he can face the family. This is the gregarious introvert balancing the stimulation levels so he can feel functional.
The shy extrovert after working from home alone all day feels dead and needs stimulation to get their energy levels up to a point where they feel functional. A shy extrovert may do a lot of multitasking to reduce the boredom of lack of external stimulation, or play action packed computer games. Maybe you know someone who works from home who really comes alive when the kids get off school and they go play. Maybe the custom in your house is to take the kids out to the park to play before everyone settles down to dinner and homework. A shy extrovert may put on loud music and the TV and start dancing around the house to get energy levels up. Or propose going out to dinner. Or tease the dog, cat, or children into boisterous play. This is the shy extrovert balancing the stimulation levels so he can feel functional.
Since Agile focuses a lot on teamwork, it is useful to know what drives different people to behave the way they do. These compensating behaviors become more pronounced in periods of high stress, so if you are pushing your team to a deadline, and some people withdraw and others start picking arguments, you can be sure they are adjusting to their own needs for reduced or increased stimulation in that high stress environment. Give the people who are withdrawing a quite place to get away for a while. Send the argumentative people to a game room with lots of games, music, and TV to play in for a while. Use what we know about the brain to make it easier for people to do their best work for you.
It is time to talk about the Product Owner, a role that most people developing solutions do not understand. Let us start by pointing out the the Product Owner as a role has NOTHING TO DO with developing solutions. It is a role independent of methodology or process. If a company sells products or services, then it has Product Owners, no matter what they may be called.
So what is a Product Owner? A Product Owner is a person in a company responsible for making sure that a product or service offered by the company is as profitable as it can be (or that it is time to end-of-life the product or service if it is no longer worth maintaining). As a start, a Product Owner knows intimately what the product or service is about, what the market is for the product or service, whether the market growing or contracting, why the customers care about the product or service, what else the customers are looking for, who has competing products or services, and who has complementary products or services. The Product Owner has a continuous task of market research and analysis.
You could say that the Product Owner is the ultimate subject matter expert on the product or service – not in the sense of how to use it, but in the sense of what it is for, what problems it solves, and the market it is in.
Examples of products and services that would have a Product Owner include:
Depending on the size of the company, the Product Owner may be even more specialized, such as the Product Owner for Term Life Insurance for people over 45.
Like a homeowner with a list of projects to do around the house, a Product Owner will have an ever changing list of things he or she wants that will improve the product or service. The list may be in the Product Owner’s head or, even better, in a spreadsheet or database. A good Product Owner will review this wish list periodically to see if it needs to change based on changes in the marketplace. This is the same kind of thing a homeowner does; you may have a list of projects based on the idea of living in the house for the next 20 years, when suddenly your spouse gets a job offer too good to refuse in another state, and you change the list of projects to match the goal of selling the house.
No Product Owner I have ever heard of has unlimited funds to do whatever he or she wants with their product or service. Periodically, let’s say every 6 months, a Product Owner selects the things that are most important about the product, and writes a proposal for developing a solution for those things. In order to convince the upper level decision makers that his/her ideas are the best, the Product Owner puts an expected value on the things he/she wants to develop, along with an expected cost for developing the solution.
For just a few ideas, a Product Owner may want money to:
This proposal of what to do along with an expected Return on Investment (ROI) is typically reviewed by a corporate portfolio committee. This portfolio committee’s job is to find the things of highest value for the company overall and fund those endeavors. This is a challenging task, since many things have to be considered. Some of the selection criteria may include the things that will make the most money, the things that will save the most money, or the things that modernize failing infrastructure. This committee often has separate pots of money for different things that are important to the company, such as ongoing maintenance, research and development, new products, upgrades, and regulatory. This way they are comparing for example two ongoing maintenance proposals to each other, and not trying to compare ongoing maintenance with research and development proposals.
Some companies have a different funding process, where the product is funded for some period, often a year. The amount of funding for the product is based on past earnings, projected earnings, value to the company compared to other products, and corporate direction. In this situation, the Product Owner has the authority to decide what to spend the money on throughout that period.
Hooray! The Product Owner has money to do the work. Now what? Well now he/she needs a better idea of what it will take to develop a solution, so that the right people can be brought on board to do the work.
The Product Owner now divides the work into work packages. A work package is a relatively small, independent bit of work. The Product Owner will often work with other people to write up the work packages, people who are familiar with what it will take to develop a solution. Done well, one work package can be assigned to one group of people to implement, while another work package is assigned to a different group of people to implement. This allows for the complete solution to be developed in parallel, thus getting the solution to market faster.
At this point, the Product Owner has some decisions to make. First, are all the work packages equal, or does it matter which is completed first. The Product Owner may say that as long as everything is delivered in 6 months the order does not matter. Or the Product Owner may recognize that it would be a large advantage in the marketplace for some of the work packages to be delivered earlier. Or perhaps some work packages describe areas of risk that the Product Owner would like to have developed first, so that he/she can send out the early solution to targeted customers to get feedback before the final product is released. What I have just described is Release Planning, where the Product Owner is making business decisions on what will be released and when.
Another decision the Product Owner has to make is does he/she want to write all the detailed requirements up front and hand them off, or does he/she want a person to represent the requirements to the team developing the solution. This is the fundamental difference between Waterfall and Agile development processes; a document containing requirements or a person representing the requirements. If the Product Owner chooses to have a person work directly with the solution delivery team, this may be to address areas of uncertainly that the Product Owner expects will change. Most Product Owners do not have the time to sit with the solution delivery team day by day, so he/she will delegate someone else to do that work. The delegate is responsible for keeping in close communication with the Product Owner.
The Product Owner needs to be very clear on his/her expectations regarding status reports and demonstrations of progress. The Product Owner also has to be very clear who gets to make what decisions throughout the solution development.
You may notice I have worked very hard to avoid mentioning software. Software is one kind of solution, but may not be the whole, or any part of the solution. If the Product Owner is developing a strategic alliance with a company with complimentary products, there may not be any software developed, and yet this endeavor is expected to bring value to the company. Or the solution may involved hardware and firmware. Or the solution may be to hire a vendor to come and install an upgrade to their product.
Product Owners are very important for the health and profitability of the company. We make a mistake if we only think of them as people who supply the requirements for our projects.
I think it is not possible to implement a sustainable Agile practice thinking only in terms of teams of 5-10 people, especially a sustainable Agile practice in large companies. I have nothing against small teams – quite the contrary! But there are distinct advantages to including our teams in a larger organism that supports and sustains the Agile teams.
We need to think in terms of Tribes.
I have been familiar with the ideas around Tribe for a very long time, and have been part of creating Tribe on many occasions. Dedicating people to a Tribe and allowing them to move around to different teams within the Tribe provides distinct advantages without the thrashing and loss of velocity that occurs when we move people between teams that are not part of a Tribe.
What is a Tribe? A Tribe is a group of around 100 people who are dedicated and co-located, and who have a commonality of interests. A Tribe develops its own language, culture, and rituals distinct from other Tribes. A Tribe contains people of many ages and experience levels, with the most knowledgeable people acting as “elders” who guide and mentor those with less experience. People in the Tribe work together, play together, and eat together.
Why about 100 people? It is large enough to get a varied pool of talent and skills, and small enough that everyone can get to know everyone else. These are very important elements to creating a stable Tribe.
Doing paired development is the best way I know of to help a Tribe form. Not just paired programming, but pair all the tasks of the Tribe. As people move around pairing with a variety of other people within the Tribe, we get terrific knowledge sharing, and people get to know each other and how to work together. It is this broad knowledge sharing and knowing how to work together that lets us have fluid teams without the disruption we usually see when people are moved on and off a team.
Advantages to a Tribe are many:
Many companies do form Tribes, though they probably do not call it that. They dedicate a group of analysts, testers, developers, technical writers, etc. to one product line, and within that product group, individual teams work on specific work packages. It works quite well, and fits nicely with the Agile focus on Products rather than Projects.
We can do more to promote the idea of Tribe as a purposeful construct, deliberately forming a Tribe by co-locating people with many different skills and experience levels, dedicating them to the Tribe, pairing all tasks to share professional knowledge and get to know how to work together, and encouraging the most knowledgeable people to mentor those less skilled.