ScanAgile 2015 submissions are open!

Just a quick note today to let you know that the Call for Sessions for ScanAgile, the Agile Finland annual conference is open for submissions.

You can read the whole call for sessions here. You will find the submission form in that page as well.

For me the most interesting tracks are:

• Off-Piste: interesting lessons learned about being agile and agile related topics, from other industries 
• Black Piste: Topics for experienced agile practitioners

These are just some of the tracks. In Scan Agile there will also be tracks for those starting up or that have already started but are in the early phases of their Agile transformation journey. 

The Agile Finland Community is very active and has a long history of agile adoption and promotion. They have some of the most advanced practitioners in the world, so I am really looking forward to see who the Scan Agile team chooses for the 2015 lineup of the conference! 

Hope to see many of you there! 

5 No Estimates Decision-Making Strategies

One of the questions that I and other #NoEstimates proponents hear quite often is: How can we make decisions on what projects we should do next, without considering the estimated time it takes to deliver a set of functionality?

Although this is a valid question, I know there are many alternatives to the assumptions implicit in this question. These alternatives - which I cover in this post - have the side benefit of helping us focus on the most important work to achieve our business goals.

Below I list 5 different decision-making strategies (aka decision making models) that can be applied to our software projects without requiring a long winded, and error prone, estimation process up front.

What do you mean by decision-making strategy?

A decision-making strategy is a model, or an approach that helps you make allocation decisions (where to put more effort, or spend more time and/or money). However I would add one more characteristic: a decision-making strategy that helps you chose which software project to start must help you achieve business goals that you define for your business. More specifically, a decision-making strategy is an approach to making decisions that follows your existing business strategy.

Some possible goals for business strategies might be:

• Growth: growing the number of customer or users, growing revenues, growing the number of markets served, etc.
• Market segment focus/entry: entering a new market or increasing your market share in an existing market segment.
• Profitability: improving or maintaining profitability.
• Diversification: creating new revenue streams, entering new markets, adding products to the portfolio, etc.

Other types of business goals are possible, and it is also possible to mix several goals in one business strategy.

Different decision-making strategies should be considered for different business goals. The 5 different decision-making strategies listed below include examples of business goals they could help you achieve. But before going further, we must consider one key aspect of decision making: Risk Management.

The two questions that I will consider when defining a decision-making strategy are:

• 1. How well does this decision proposal help us reach our business goals?
• 2. Does the risk profile resulting from this decision fit our acceptable risk profile?

Are you taking into account the risks inherent in the decisions made with those frameworks?

All decisions have inherent risks, and we must consider risks before elaborating on the different possible decision-making strategies. If you decide to invest in a new and shiny technology for your product, how will that affect your risk profile?

A different risk profile requires different decisions

Each decision we make has an impact on the following risk dimensions:

• Failing to meet the market needs (the risk of what).
• Increasing your technical risks (the risk of how).
• Contracting or committing to work which you are not able to staff or assign the necessary skills (the risk of who).
• Deviating from the business goals and strategy of your organization (the risk of why).

The categorization above is not the only possible. However it is very practical, and maps well to decisions regarding which projects to invest in.

There may good reasons to accept increasing your risk exposure in one or more of these categories. This is true if increasing that exposure does not go beyond your acceptable risk profile. For example, you may accept a larger exposure to technical risks (the risk of how), if you believe that the project has a very low risk of missing market needs (the risk of what).

An example would be migrating an existing product to a new technology: you understand the market (the product has been meeting market needs), but you will take a risk with the technology with the aim to meet some other business need.

Aligning decisions with business goals: decision-making strategies

When making decisions regarding what project or work to undertake, we must consider the implications of that work in our business or strategic goals, therefore we must decide on the right decision-making strategy for our company at any time.

Decision-making Strategy 1: Do the most important strategic work first

If you are starting to implement a new strategy, you should allocate enough teams, and resources to the work that helps you validate and fine tune the selected strategy. This might take the form of prioritizing work that helps you enter a new segment, or find a more valuable niche in your current segment, etc. The focus in this decision-making approach is: validating the new strategy. Note that the goal is not "implement new strategy", but rather "validate new strategy". The difference is fundamental: when trying to validate a strategy you will want to create short-term experiments that are designed to validate your decision, instead of planning and executing a large project from start to end. The best way to run your strategy validation work is to the short-term experiments and re-prioritize your backlog of experiments based on the results of each experiment.

Decision-making Strategy 2: Do the highest technical risk work first

When you want to transition to a new architecture or adopt a new technology, you may want to start by doing the work that validates that technical decision. For example, if you are adopting a new technology to help you increase scalability of your platform, you can start by implementing the bottleneck functionality of your platform with the new technology. Then test if the gains in scalability are in line with your needs and/or expectations. Once you prove that the new technology fulfills your scalability needs, you should start to migrate all functionality to the new technology step by step in order of importance. This should be done using short-term implementation cycles that you can easily validate by releasing or testing the new implementation.

Decision-making Strategy 3: Do the easiest work first

Suppose you just expanded your team and want to make sure they get to know each other and learn to work together. This may be due to a strategic decision to start a new site in a new location. Selecting the easiest work first will give the new teams an opportunity to get to know each other, establish the processes they need to be effective, but still deliver concrete, valuable working software in a safe way.

Decision-making Strategy 4: Do the legal requirements first

In medical software there are regulations that must be met. Those regulations affect certain parts of the work/architecture. By delivering those parts first you can start the legal certification for your product before the product is fully implemented, and later - if needed - certify the changes you may still need to make to the original implementation. This allows you to improve significantly the time-to-market for your product. A medical organization that successfully adopted agile, used this project decision-making strategy with a considerable business advantage as they were able to start selling their product many months ahead of the scheduled release. They were able to go to market earlier because they successfully isolated and completed the work necessary to certify the key functionality of their product. Rather then trying to predict how long the whole project would take, they implemented the key legal requirements first, then started to collect feedback about the product from the market - gaining a significant advantage over their direct competitors.

Decision-making Strategy 5: Liability driven investment model

This approach is borrowed from a stock exchange investment strategy that aims to tackle a problem similar to what every bootstrapped business faces: what work should we do now, so that we can fund the business in the near future? In this approach we make decisions with the aim of generating the cash flows needed to fund future liabilities.

These are just 5 possible investment or decision-making strategies that can help you make project decisions, or even business decisions, without having to invest in estimation upfront.

None of these decision-making strategies guarantees success, but then again nothing does except hard work, perseverance and safe experiments!

In the upcoming workshops (Helsinki on Oct 23rd, Stockholm on Oct 30th) that me and Woody Zuill are hosting, we will discuss these and other decision-making strategies that you can take and start applying immediately. We will also discuss how these decision making models are applicable in day to day decisions as much as strategic decisions.

If you want to know more about what we will cover in our world-premiere #NoEstimates workshops don't hesitate to get in touch!

Your ideas about decision-making strategies that do not require estimation

You may have used other decision-making strategies that are not covered here. Please share your stories and experiences below so that we can start collecting ideas on how to make good decisions without the need to invest time and money into a wasteful process like estimation.

Lean Change Management: A Truly Agile Change Management approach

"I've been working in this company for a long time, we've tried everything. We've tried involving the teams, we've tried training senior management, but nothing sticks! We say we want to be agile, but..."

Many people in organizations that try to adopt agile will have said this at some point. Not every company fails to adopt agile, but many do.

Why does this happen, what prevents us from successfully adopting agile practices?

Learning from our mistakes

Actually, this section should be called learning from our experiments. Why? Because every change in an organization is an experiment. It may work, it may not work - but for sure it will help you learn more about the organization you work for.

I learned this approach from reading Jason Little's Lean Change Management. Probably the most important book about Agile adoption to be published this year. I liked his approach to how change can be implemented in an organization.

He describes a framework for change that is cyclical (just like agile methods):

• Generate or gain insights: in this step we - who are involved in the change - do small experiments (like for example asking questions) to generate insights into how the organization works, and what possible things we could use to help people embrace the next steps of change.
• Define options: in this step we list what are the options we have. What experiments could we run that would help us towards our Vision for the change.
• Select and run experiments: each option will, after being selected, be transformed into an experiment. Each experiment will have a step of actions, people to involve, expected outcomes, etc.
• Review, learn and...: After the experiments are concluded (and sometimes right after starting those experiments) we gain even more insights that we can feed right back into what Jason call the Lean Change Management Cycle.

The Mojito method of change

The overall cycle for Lean Change Management is then complemented in the book with concrete practices that Jason used and explains how to use in the book. Jason uses the story of The Commission to describe how to apply the different practices he used. For example, in Chapter 8 he goes into details of how he used the Change Canvas to create alignment in a major change for a large (and slow moving) organization.

Jason also reviews several change frameworks (Kotter's 8 steps, McKinsey's 7S, OCAI, ADKAR, etc.) and how he took the best out of each framework to help him walk through the Lean Change Management cycle.

The most important book about Agile adoption right now

After having worked on this book for almost a year together with Jason, I can say that I am very proud to be part of what I think is a critical knowledge area for any Agile Coach out there. Jason's book describes a very practical approach to changing any organization - which is what Agile adoption is all about.

For this reason I'd say that any Agile Coach out there should read the book and learn the practices and methods that Jason describes. The practices and ideas he describes will be key tools for anyone wanting to change their organization and adopt Agile in the process.

Here's where you can find more details about what the book includes.

The No Estimates principle: The importance of knowing when you are wrong

You started the project. You spent hours, no: days! estimating the project. The project starts and your confidence in its success is high.

Everything goes well at the start, but at some point you find the project is late. What happened? How can you be wrong about estimates?

This story very common in software projects. So common, that I bet you have lived through it many times in your life. I know I have!

Let’s get over it. We’re always wrong about estimation. Sometimes more, sometimes less and very, very rarely we are wrong in a way that makes us happy: we overestimated something and can deliver the project ahead of (the inflated?) schedule.

We’re always wrong about estimation.

Being wrong about estimates is the status quo. Get over it. Now let’s take advantage of being wrong! You can save the project by being wrong. Here’s why...

The art of being wrong about software estimates

Knowing you are wrong about your estimates is not difficult after the fact, when you compare estimates to actuals. The difficult part is to make a prediction in a way that can tested regularly, and very early on - when you still have time to change the project.

Software project estimates as they are usually done, delay the feedback for the “on time” performance to a point in time when there’s very little we can do about it. Goldratt grasped this problem and made a radical suggestion: cut all estimates in half, and use the rest of the time as a project buffer. Pretty crazy hein? Well, it worked because it forced projects to face their failures much earlier than they would otherwise. Failing to meet a deadline early on in the life-cycle of the project gave them a very powerful tool in project management: time to react!

The #NoEstimates approach to being wrong...and learning from it

In this video I explain shortly how I make predictions about a possible release date for the project based on available data. Once I make a release date prediction, I validate it as soon as possible, and typically every week. This approach allows me to learn early enough when I’m wrong and then adjust the project as needed.

We’re always wrong, the important thing is to find out how wrong, as early as possible

After each delivery (whether it is a feature or a timebox like a sprint), I update my prediction for the release date of the project based on the lead time or throughput rate so far. After updating the release date projection, I can see whether it has changed enough to require a reaction by the project team. I can make this update to the project schedule without gathering the whole team (or "the chosen ones") into a room for an ungodly long estimation meeting.

If the date has not changed outside the originally interval, or if the delivery rate is stable (see the video), then I don’t need to react.

When the release date projection changes to a time outside the original interval, or the throughput rate has become unstable (did you see the video?), then you need to react. At first to investigate the situation, and later to adjust the parameters in your project if needed.

Conclusion

The #NoEstimates approach I advocate will allow you to know when the project has changed enough to warrant a reaction. I make a prediction, and (at least) every week I review that prediction and take action.

Estimates, done the traditional way, also give you this information, but too late. This happens because of the big-batch thinking the reliance on estimations enables (larger work items are ok if you estimate), and because of the delayed dependency integration it enables (estimated projects typically allow for teams that are dependent to work separately because of the agreed plan).

The #NoEstimates approach I advocate has one goal: reduce feedback cycle. These short feedback cycles will allow you to recognise early enough how wrong you were about your predictions, and then you can make the necessary adjustments!

Picture credit: John Hammink, follow him on twitter

The Release Paradox: releasing less often makes your teams slower and decreases quality

Herman is a typical agile coach. He works with teams to help them learn how to deliver high-quality software quickly.

Many teams want to focus on design, architecture, or (sometimes) even on business value. But they are usually not in a hurry to release quickly.

Recently Herman conveyed a story to me that illustrates how releasing quickly can help teams deliver high-quality software much faster than if they would focus on quality in the first place. This is the case of a team that was working on a long overdue project. They had used a traditional and linear process in the past and had been able to release software only very recently, after more than 12 months of work on the latest release.

Not surprisingly, they were having trouble releasing regularly. The software was not stable; once it was live it had many problems that needed to be fixed quickly, and worst of all: all of this was having a direct impact on the company’s business.

The teams were extremely busy fixing the problems they had added to the product in the last year and could not focus on solving the root causes of those problems.

They were in full-fledged firefighting mode. They worked hard every day to fix yet another problem and release yet another hot fix.

This lasted for a few weeks, but once the fire-fighting mode was over, Herman worked with the teams to improve their release frequency. During their work with Herman, those teams went from one year without any release to a regular release every two weeks.

At first the releases were not always possible, but with time they improve their processes, removed the obstacles preventing them from releasing every two weeks and started releasing regularly.

What happened next was surprising for the teams. The list of problems after each release did not grow - as they expected - but instead shrank.

When some problems came in from the customers after a 2-week release, they were also much faster to fix the problem and quicker to release a fix if that was required. When the fix was not critical, they waited for the following release which was, after all, only 2 weeks away.

By focusing on releasing every two weeks, Herman’s teams were able to focus on small, incremental changes to their product. That, in turn, enabled them to fine-tune their development and release processes.

Here are some of the key changes the teams implemented

1. They started with a 4 week release cycle, and fine-tuned their daily builds and release testing process to enable a release every 2 weeks.
2. They invested time and energy to improve their test automation strategy and automated the critical tests to enable them to run “enough” tests to be confident that the quality was at release level.
3. They had some teams on maintenance duty in the first few iterations to make sure that any problem found after release could quickly be fixed, and released to customers if necessary.
4. They changed their source code management strategy to enable some teams to work on longer term changes while others worked on the next release.
5. They involved all teams necessary to complete a release in their iterations. This affected especially: production/operations team, localization team, documentation team, marketing team, and other teams when needed.

This list of changes was the result of the drive to complete each release and learning from the failures in the previous release. Some changes were harder to implement, and especially the testing strategy to allow for 2-week release cycles had to be changed and adjusted several times.

One of the key problems the teams had to solve, was the lack of coordination with departments that directly contributed to the release but were not previously involved in their day-to-day work.

This process lasted several months, and would not have been possible without a clear Vision set forth by the teams in cooperation with Herman, who helped them discover the right way to reach that Vision within their context.

Herman’s work as a coach was that of a catalyst for management and the teams in that organization. He was able to create in their minds a clear picture of what was possible. Once that was clear, the teams and the management took ownership of the process and achieved a step-change in their ability to fulfill market demands and customer needs.

Customers have no reason to change provider as they have an ever-improving experience when using this company’s services.

Today, this organization releases a new version of their product every two weeks. Unaware of it, their customers receive regular improvements to the product they use, and have no reason to change provider as they have an ever-improving experience when using this company’s services.

Picture credit: John Hammink, follow him on twitter

How to create a knowledge worker Gemba

I am a big fan of the work by Jim Benson and Tonianne Barry ever since I read their book: Personal Kanban.

In this article Jim describes an idea that I would like to highlight and expand. He says: we need a knowledge worker Gemba. He goes on to describe how to create that Gemba:

• Create a workcell for knowledge work: Where you can actually observe the team work and interact
• Make work explicit: Without being able to visualize the work in progress, you will not be able to understand the impact of certain dynamics between the team members. Also, you will miss the necessary information that will allow you to understand the obstacles to flow in the team - what prevents value from being delivered.

These are just some steps you can take right now to understand deeply how work gets done in your team, your organization or by yourself if you are an independent knowledge worker. This understanding, in turn will help you define concrete changes to the way work gets done in a way that can be measured and understood.

I've tried the same idea for my own work and described it here. How about you? What have you tried to implement to create visibility and understanding in your work?

How to choose the right project? Decision making frameworks for software organizations

Frameworks to choose the best projects in organizations are a dime a dozen.

We have our NPV (net present value), we have our customized Criteria Matrix, we have Strategic alignment, we have Risk/Value scoring, and the list goes on and on.

In every organization there will a preference for one of these or similar methods to choose where to invest people’s precious time and money.

Are all these frameworks good? No, but they aren’t bad either. They all have some potential positive impact, at least when it comes to reflection. They help executive teams reflect on where they want to take their organizations, and how each potential project will help (or hinder) those objectives.

So far, so good.

“Everybody’s got a plan, until they get punched in the face” ~Tyson

Surviving wrong decisions made with perfect data

However, reality is seldom as structured and predictable as the plans make it out to be. Despite the obvious value that the frameworks above have for decision making, they can’t be perfect because they lack one crucial aspect of reality: feedback.

Models lack on critical property of reality: feedback.

As soon as we start executing a particular project, we have chosen a path and have made allocation of people’s time and money. That, in turn, sets in motion a series of other decisions: we may hire some people, we may subcontract part of the project, etc.

All of these subsequent decisions will have even further impacts as the projects go on, and they may lead to even more decisions being made. Each of these decisions will also have an impact on the outcome of the chosen projects, as well as on other sub-decisions for each project. Perhaps the simplest example being the conflicts that arise from certain tasks for different projects having to be executed by the same people (shared skills or knowledge).

And at this point we have to ask: even assuming that we had perfect data when we chose the project based on one of the frameworks above, how do we make sure that we are still working on the most important and valuable projects for our organization?

Independently from the decisions made in the past, how do we ensure we are working on the most important work today?

The feedback bytes back

This illustrates one of the most common problems with decision making frameworks: their static nature. They are about making decisions "now", not "continuously". Decision making frameworks are great at the time when you need to make a decision, but once the wheels are in motion, you will need to adapt. You will need to understand and harness the feedback of your decisions and change what is needed to make sure you are still focusing on the most valuable work for your organization.

All decision frameworks have one critical shortcoming: they are static by design.

How do we improve decision making after the fact?

First, we must understand that any work that is “in flight” (aka in progress) in IT projects has a value of zero, i.e., in IT projects no work has value until it is in use by someone, somewhere. And at that point it has both value (the benefit) and cost (how much we spend maintaining that functionality).

This dynamic means that even if you have chosen the right project to start with, you have to make sure that you can stop any project, at any time. Otherwise you will have committed to invest more time and more money (by making irreversible “big bang” decisions) into projects that may prove to be much less valuable than you expected when you started them. This phenomenon of continuing to invest beyond the project benefit/cost trade-off point is known as Sunk Cost Fallacy and is a very common problem in software organizations: because reversing a decision made using a trustworthy process is very difficult, both practically (stop project = loose all value) and due to bureaucracy (how do we prove that the decision to stop is better than the decision to start the project?)

Can we treat the Sunk Cost Fallacy syndrome?

While using the decision frameworks listed above (or others), don’t forget that the most important decision you can make is to keep your options open in a way that allows you to stop work on projects that prove less valuable than expected, and to invest more in projects that prove more valuable than expected.

In my own practice this is one of the reasons why I focus on one of the #NoEstimates rules: Always know what is the most valuable thing to work on, and work only on that.

So my suggestion is: even when you score projects and make decisions on those scores, always keep in mind that you may be wrong. So, invest in small increments into the projects you believe are valuable, but be ready to reassess and stop investing if those projects prove less valuable than other projects that will become relevant later on.

The #NoEstimates approach I use allows me to do this at three levels:

• a) Portfolio level: by reviewing constant progress in each project and assess value delivered. As well as constantly preparing to stop each project by releasing regularly to a production-like environment. Portfolio flexibility.
• b) Project level: by separating each piece of value (User Story or Feature) into an independent work package that can be delivered independently from all other project work. Scope flexibility.
• c) User Story / Feature level: by keeping User Stories and Features as small as possible (1 day for User Stories, 1-2 weeks for Features), and releasing them independently at fixed time intervals. Work item flexibility

Do you want to know more about adaptive decision frameworks? Woody Zuill and myself will be hosting a workshop in Helsinki to present our #NoEstimates ideas and to discuss decision making frameworks for software projects that build on our #NoEstimates work.

You can sign up here. But before you do, email me and get a special discount code.

If you manage software organizations and projects, there will be other interesting workshops for you in the same days. For example, the #MobProgramming workshop where Woody Zuill shows you how he has been able to help his teams significantly improve their well-being and performance. #MobProgramming may well be a breakthrough in Agile management.

Picture credit: John Hammink, follow him on twitter

What is Capacity in software development? - The #NoEstimates journey

I hear this a lot in the #NoEstimates discussion: you must estimate to know what you can deliver for a certain price, time or effort.

Actually, you don’t. There’s a different way to look at your organization and your project. Organizations and projects have an inherent capacity, that capacity is a result of many different variables - not all can be predicted. Although you can add more people to a team, you don’t actually know what the impact of that addition will be until you have some data. Estimating the impact is not going to help you, if we are to believe the track record of the software industry.

So, for me the recipe to avoid estimates is very simple: Just do it, measure it and react. Inspect and adapt - not a very new idea, but still not applied enough.

Let’s make it practical. How many of these stories or features is my team or project going to deliver in the next month? Before you can answer that question, you must find out how many stories or features your team or project has delivered in the past.

Look at this example.

How many stories is this team going to deliver in the next 10 sprints? The answer to this question is the concept of capacity (aka Process Capability). Every team, project or organization has an inherent capacity. Your job is to learn what that capacity is and limit the work to capacity! (Credit to Mary Poppendieck (PDF, slide 15) for this quote).

Why is limiting work to capacity important? That’s a topic for another post, but suffice it to say that adding more work than the available capacity, causes many stressful moments and sleepless nights; while having less work than capacity might get you and a few more people fired.

My advice is this: learn what the capacity of your project or team is. Only then you will be able to deliver reliably, and with quality the software you are expected to deliver.

How to determine capacity?

Determining the capacity of capability of a team, organization or project is relatively simple. Here's how

• 1- Collect the data you have already:
  • If using timeboxes, collect the stories or features delivered(*) in each timebox
  • If using Kanban/flow, collect the stories or features delivered(*) in each week or period of 2 weeks depending on the length of the release/project
• 2- Plot a graph with the number of stories delivered for the past N iterations, to determine if your System of Development (slideshare) is stable
• 3- Determine the process capability by calculating the upper (average + 1*sigma) and the lower limits(average - 1*sigma) of variability

At this point you know what your team, organization or process is likely to deliver in the future. However, the capacity can change over time. This means you should regularly review the data you have and determine (see slideshare above) if you should update the capacity limits as in step 3 above.

(*): by "delivered" I mean something similar to what Scrum calls "Done". Something that is ready to go into production, even if the actual production release is done later. In my language delivered means: it has been tested and accepted in a production-like environment.

Note for the statisticians in the audience: Yes, I know that I am assuming a normal distribution of delivered items per unit of time. And yes, I know that the Weibull distribution is a more likely candidate. That's ok, this is an approximation that has value, i.e. gives us enough information to make decisions.

You can receive exclusive content (not available on the blog) on the topic of #NoEstimates, just subscribe to the #NoEstimates mailing list below. As a bonus you will get my #NoEstimates whitepaper, where I review the background and reasons for using #NoEstimates

Subscribe to our mailing list

* indicates required

Email Address *

First Name

Last Name

Picture credit: John Hammink, follow him on twitter

How Chaos Theory will influence management and management styles in the future

Managers all over the world are faced with a critical challenge to their role. They ideas about management and their management style is being challenged. And this is even more important because many managers have reached a position of in their career where they thought they could "take it easy". Nothing could be further from the truth.

Today the role of managers in all industries is shifting. And in no industry more than the knowledge industry.

In this video I explore why this is happening and where we may be able to look for solutions. I also present a concrete set of consequences that will affect you as a manager from the trends we are witnessing in the knowledge industry.

Do you want to know more?

Ready to explore what you as a manager can learn from The Science of Chaos?

You came to the right place! :) Mystes in Finland organizes a workshop about Chaos Science applied to the challenges of managing small and large knowledge work organizations. You can visit their site to know more about the workshop and to sign up. Places are limited. In that workshop I will touch on the following topics:

• Current theoretical base for managing projects
• What is wrong with managing software projects today and why?
• What can we learn from Chaos Theory and how to apply it in real life projects?
• A model for a successful project using what we have learned from Chaos Theory

Do you have specific questions that intrigue you? Send them to us and we promise to address them during the workshop!

Management science's impossible quest: in search of predictability

Many years ago some people came up with a brilliant idea: "what if, we could turn abundant lead (Pb on the table of elements) into scarce gold?". A brilliant idea to be sure, but as we know now, impossible. What made Alchemy grow and thrive as a science, was that people at that time did not know that it was impossible. They did not have enough knowledge of chemistry to know that you cannot turn an element's atom into another element's atom. That did not stop them however! And thanks to those crazy idealists today we have Chemistry. How about that for a twist of fate?

Alchemy's history can be traced back for millennia, and that name stands as the prototypical failed science (except for poets and … idealists). Failed because it based its existence on a belief that was impossible to make reality in our world.

I find many parallels between Alchemy and Management science today. Alchemy wanted to find the magic Philosopher's Stone that could turn led into gold, Management scientists are in a similar quest: in search of the method that can make management succeed as a science. Management science's goal today is to find the magic ingredient that can give us predictability.

Basic Science

Many management-fads are based on the hypothesis that you can control the world around you, mold it in a way that can give you predictability. This (mythical) predictability is a core assumption that enables the management's idea of success: I will do X so that I can achieve Y and therefore succeed.

This predictability is, however, a form of causality. Many, perhaps including you, will not think of it that way, but predictability is only present in systems where you can determine causality. A predictable world is one where we can reliably predict what happens when we do X, i.e. a world where we can establish causality.

Newton's laws gave us predictability in the physical macroscopic world of objects, because they told us what would happen if, for example, you rolled a sphere in an inclined plane, or shot a bullet from a canon, or shot an arrow with a bow. Relativity theory gave us predictability (to a certain extent) in the microscopic world of atoms, or sub-atomic particles also because it established useful and applicable causality rules

Medicine gives us (mostly) predictability in the world of diseases and biologic systems like the human body because it has a system of studying and documenting causality: if you take Aspirin after a great Saturday night party, you will feel milder effects of the oncoming hangover.

You can see why management theorists (and practitioners) would want to achieve the same goal: predictability.

Predictability is management science's Philosopher's stone.

The Philosopher's stone

Planning is one of those attempts at achieving predictability. We plan, because we believe that planning will give us the predictability we seek. Without the goal of predictability we would not plan, there would be no point.

But planning itself rests on the assumption that we can predict (here it comes again) causality in the world where the plan is to be executed. If we did not believe that we could predict B to happen after doing A, then planning would not be possible. It would be illogical.

We plan to be able to predict, but plans only work if we can predict in the first place!

The problem with what is stated above is that it is a circular dependency: we plan to be able to predict, but the act of planing rests on the assumption that the world is predictable. You see where this is going, right?

The sad fact is that there are many other management techniques that both rest on, and try to achieve predictability. For example: pay for performance, management by objectives, or the yearly strategic plan.

Going around in circles

All these management techniques have one thing in common. They are static. They exist at a precise point in time: Strategy is defined in the Spring or Autumn and is supposed to be executed for the next 12, 18, 24 or more months. Objectives or goals upon which our evaluation is based are set several months in advance of the point of evaluation.

All these techniques require perfect, 20/20 foresight. How likely is that?

The basic problem with most perspectives on management today is that they are static analyses of a future environment. And all decisions are made because we believe we can predict the future.

We make these predictions to help our businesses be more predictable, but our predictions depend on our business being predictable. This circular dependency is why most management approaches are doomed to failure. Like Alchemy.

Looking forward

We need a new Management Science, one that does not require the existence of a predictable world. When it defines goals, it does so in a way that is dynamic, i.e. the goals change with the observation of reality. This dynamic adaptation process is what we, in the Agile community, call a feedback loop.

A future-proof management approach must start by basing it's core assumptions on the existence of feedback loops that must be studied and tested as we make decisions. And these feedback loops must be the driving factors for action in management. Not the plans!

How would such a management approach look like?

The first assumption of such a management approach must be that the world is not predictable beyond a very short time. This may be a simple statement, but the consequences of this simple statement are fundamental.

• First, management techniques must not be based on the existence of a perfect, predictable future. Management techniques must be based on the acknowledgement that we cannot predict what is the best (or worst) possible outcome of our actions. What good is it to plan to sell 100 widgets when the market is - unexpectedly - demanding us to produce 1000 widgets? or 10 widgets?
• Second, management techniques must be designed to include feedback loops that inform action. Not just as information collection loops, but as fundamental action-defining loops. For example: every single decision is temporary. Every decision must state it's assumptions and when one assumption is proven wrong, the decision must be reverted or at a minimum re-evaluated. When we execute our plans, we must be alert to surprises; without detailing our assumptions we can never be surprised. Surprises are triggers for action - no surprises, no learning, no adaptation.
• Third, an individual's performance cannot be predicted up front. This tells us that we can only evaluate an individual's performance after we have the facts of what happened. Maybe a sales person failed to meet their sales target, but that could be because they helped R&D get the first pilot customers for an entirely new business!

What would your world look like if you believed and followed the three principles above? How would it differ from your current perspective on management?

Image credit: John Hammink, follow him on twitter.

Fractals, the solution to all of your scaling problems. Including Scaling Agile

It is no secret that I love planning. I'm not coming out of the closet now, that's been true forever! And at some point in my life I was even "cool" with that.

Additionally, I want you to know (although you will not yet understand why) that I still love planning. That's me :) Now pay attention, I'm about to shoot myself in the foot.

Loading the gun

When I was in college there was a topic that I loved, the topic was Information Theory. There's so much stuff in that area of research that I can't even begin to touch the tip of the proverbial iceberg, so I'll just say - for now - that information theory is an area of research that investigates information and how it is codified. For example: how do I compress a text file? Turns out, text can be very efficiently compressed. Perhaps the blog post you are reading can be codified in a few hundred bytes. The cool thing is why that happens: redundancy. Redundancy is an unappreciated quality of all systems.

So unappreciated in fact, that we all praise it's mirror twin: efficiency. A compressed text file is very efficient (i.e. it codifies a lot of information in a very small amount of disk space - I could probably compress this post into 140 bytes and tweet it out - that would be efficient).

If we can create so efficient representation of information why would we stick the old-skool inefficient representation (for example: language)? I'm glad you ask! The reason is that language with all its redundancy is easy to understand even if you cut parts out or mangle the letters. Try reading the following paragraph (click for a larger version):

Did you understand what that said? Of course you did! Redundancy saves the day! Yay!

Now about software and organizations

In organizations and companies, we also have redundancy - plenty of it! And just as well, because without it most companies and organizations would stop working altogether. Redundancy gives us resilience! Just like in the language example above: even with parts of the words cut out of the phrase you were able to understand it! And this is just how organizations work: through, and thanks to, redundancy. This is the reason why some "downsizing" efforts end up killing whole companies, and the often touted "efficiencies" or "synergies" leaders try to gain from mergers and acquisitions end up destroying economic value more often than they create.

The trick with redundancy is to repeat

By now you probably agree that redundancy is good - and it is. But how do you apply it to your organization and processes?

Before we go there, we have to tackle a very neat concept of mathematics. Fractals. Fractals have a property that is mind-boggling. Fractals are concepts that once explored end up generating infinite (yes, infinite!) information. In fact, a fractal line has infinite length even while fitting in a finite space! I won't bore you with the math details, but check this page on Wikipedia about the length of the British coast line - it has a neat demonstration of how a finite space can hold a line of infinite length.

This means that fractals are generative when it comes to information: they generate infinite amounts of information. And this happens to be a very useful property to have in mind when we explore how organizations work.

Making the case for infinity (and beyond)

In this post I argued that removing rules from your company's process book is actually better for your business and for your teams. The next step is to remove as many rules as you can, so that you end up with a small and simple set of generative rules - just like a fractal. Fractals are very simple equations that have in themselves an infinite number of solutions. And that's exactly what our processes should be: a small set of rules that, once in use, accommodate an infinite amount of possible behaviors - this is what I mean by "complex behavior" in the post on disciplined organizations.

Conclusion

Turns out fractals are perfect (yes, perfect - as in perfectly efficient) compression algorithms: a simple equation can be solved in an infinite number of ways, which when plotted in 2D or even 3D generate an infinite line in a finite space.

This property is extremely useful when applied to processes in your company because you cannot predict how people should behave in the future, but you can create an environment that - just like a fractal - allows every actor / person in the company to act in an infinite (and therefore practically unpredictable) number of ways and adapt to whatever the ever changing reality throws at them.

If you believe that your business environment is constantly changing, and that your organization is akin to a living organism you have to embrace the concept of fractal organizations.

Fractals work for you when they allow your blood vessels to reach every cell of your body (within a few cells distance), and when they allow your brain to store vast quantities of information even if it is small enough to fit in your head. Fractal organizations are organizations that can adapt in an infinite number of ways in response to an unpredictable environment.

If change is the only constant, how do I adapt to that?

Epilogue

Before we can understand how to apply the concept of fractal organizations and benefit from that, a very serious question must be answered: If people can behave in infinitely different ways, how do we prevent organizations from turning into chaos? That's a question we will explore soon - stay tuned! :)

Do you want to know more?

Title image credit: John Hammink, follow him on twitter.

Hire generalists to help your specialists shine!

Imagine you are developing a highly-specialized embedded software product. Like a radio tower for the GSM/UMTS network, or a high-frequency trading back-end for a large New York trading firm. Why would you want to have generalists in that team? After all, these are niche-niche-niche products. Maybe a few thousand people work on these projects in the world. No need, right? Wrong! Here's why.

Forget common-sense

The comment above is designed to sound counter-intuitive. The reason for that is that most of this post is counter-intuitive. I'll argue that one of the basic premises behind software project management are purely and simply wrong. This one specifically, is ultra-wrong: specialists in a software project (even a niche one) should be the majority of the team. The "favor specialists" heuristic says things like: "don't hire a Ruby programmer to a Java project", "hire only people who've done financial systems to that high-frequency trading platform", etc. You get the picture.

What is the reason for this "favor specialists" heuristic? Why did it arise? The most obvious reason is that we want to hire people that "know what they are doing", and in our functional definition of software projects that means: "people who have done that one thing before". And who could argue with that? Right?

What if we looked at projects like systems, complex systems that incorporate technical and social aspects that are very hard to control or manage? In this case we would be compelled to question the "favor specialists" heuristics, because we would look at a project as much more than a technical endeavor. We would look at projects as being social and technical endeavors.

Social is complex

Social systems have many more dynamics in place than "what is the best technical solution? How do we select from competing technical solutions? What skills should we hire for?"
Social systems change rapidly (whether you like it or not), and they require a different set of assumptions about what is the best project team composition and organization. For example - the point of this post - it requires us to question the ratio of generalists to specialists.
In the last post I talked about Emergence. I explained that system behavior is affected by many unpredictable dynamics and that simple rules favor adaptable behavior in projects. I also said that a long list of complicated rules will remove adaptability from the project team. The heuristic I described in that post is: "complex rules emerge stupid behavior."

Emergence is favored by and favors generalists

I believe all projects are social complex systems. Yes, even two people projects (those, probably even more than larger projects. Think of the rule set on a 2 people project!). These social complex systems perform better when there are only a few and simple rules. They benefit from constant change (see here how to do that so that it does not kill you). Social complex systems are environments where generalists excel! Here's why:

• generalists are more likely to think laterally (similar problems in other domains), and therefore come up with innovative solutions that provide business advantages;
• generalists are more likely to establish communication links to other teams and organizations (because they are connected to more interest groups - which is what makes them generalists), and therefore improve the overall communication in the project team;
• and there are many more, let me know which you have found in your experience by leaving a comment.

Improve performance by adding generalists to your project

I propose that we start designing our projects based on a different heuristic: "favor generalists". This means that we will try to seed all teams with generalists, people who know their trade but are not invested in only one particular technical solution or process.

For Developers this means that all developers should be encouraged to learn several programming languages, work in different problems during their employment, and that we don't hire people just because they've solved the same problem in the past.

For Testers this means that we hire people that can do manual and automated testing (maybe more on than the other, but both), that know different technologies, that understand social aspects (users) and technical aspects of software development (e.g. math).

For Product Managers this means that we hire people that have worked in other industries, other types of products or even in non-software only products.

If you believe, like I do, that software projects are social complex systems, then you must not favor specialists. Hire and groom specialists but seed all teams with generalists, sit back and enjoy the higher performance.

Picture credit: John Hammink, follow him on twitter.

The simple recipe for disciplined organizations

One question puzzles non-Agilists more than any other question. It is the question that uncovers why Agile does not fit their view of the world. A question that makes non-Agilists feel insecure and reject Agile completely or mostly. This question is: how can less structure, and less planning deliver software more reliably, and with higher quality, and faster, and with better usability, and with better customer satisfaction?

Do you know the answer to this question? Many Agilists don't. Here's one attempt at answering that question.

Agile is different

Those of us that have been practicing Agile for a while have learned to "break the rules" - or reach the Ha or Ri levels in the Shu-Ha-Ri model. We've practiced, and practiced, and practiced. We've learned what works (some times) and what does not work (most of the time), and we have been able to hone our practice to a point where Agile just feels "natural". But what is "normal"? How would you, a Ha or Ri level practitioner of Agile define Agile?

This reminds me of a story I heard from Angel Medinilla, a dear friend and fellow Agile journeyman:

In a dojo somewhere in a southern country, the Aikido apprentice reaches out to the sensei to understand the secret of Aikido.

Aikido apprentice: Sensei, what is the secret of Aikido?
Sensei: The secret is to breath, to balance, to connect with your opponent and whole body movement.

The apprentice was frustrated, he was expecting something enlightened and concrete for him to use.
Then, after 40 years of practice the apprentice finally says to his sensei:

Apprentice: Sensei, finally I understand the secret of Aikido
Sensei: Good. So, what is it?
Apprentice: It was simple and in front of my eyes all along. The secret is to breath, to balance, to connect with your opponent and whole body movement.

The sensei in that story knew that the apprentice would eventually come to realize that Aikido was indeed "just" to breath, to balance, connecting with the opponent and whole body movement. So, how about Agile, what is Agile all about? And how does it deliver more discipline, with less rules?

Chaos is very disciplined

While I tried to make sense of Agile, I explored many possible models. One of them was Chaos Theory. As I explored the Theory of Chaos I found a very interesting video about one of the favorite topics in the Agile community: emergence. Emergence is the process by which a system (any system) organizes itself based on real rules and exhibits what we would call complex behavior. For example, in this post I explained how a colony of Ants can exhibit complex behavior by following just a few rules. That complex, adaptive behavior emerges from the rules, and the action of the individuals. The rules are real (there is a benefit in following them), and the resulting behavior is complex and adaptable but also, very very disciplined (because there is a benefit to that discipline, you follow it or you die of hunger).

Going back in time

The counter-intuitive aspect of emergence is that it goes against all accepted "truths" about organizational design. You see, emergence can not be explained by reducing our model of the system to simply modeling of the agents' independent behaviors. Emergence is a result of all the parts interacting in the system. If you remove one of the rules from the ant colony you would get something different (possibly even the break down of the whole colony).

Simple rules lead to complex behavior. Complex rules lead to stupid behavior.
--adapted from original quote by Dee Hock

Reductionism is the most common process for organization design used by humans today. We tend to start by modeling small independent parts, and when we are satisfied with each, we put them together. But there's a problem with that approach. When you try to design an organization, or a process, by first identifying all the necessary steps individually, and then you sequence them orderly you make the system stupid. Or, in other words, you create rules that remove the possibility for complex, adaptive behavior to emerge.

This process or analyzing, ordering, prescribing organizational and process design is labeled analytic, and it is based on the theory that if you break something apart (like the organization), and analyze those parts independently you will understand it sufficiently enough to know how the whole system works. The problem is that an organization, like any system, has dynamics that can only be seen when all the parts are assembled and never when they are analyzed separately.

By contrast, if we define clear and simple rules (think the rules of chess) and nothing else, we are allowing the system to - through emergence - exhibit complex, adaptive behavior. The big question comes next: where do you draw the line between simple rules that allow for complex behavior to emerge, and the analytic process? When do we cross from one to the other?

Drawing a line in the sand

This is not an easy question to answer, and it is highly context dependent. However, I have found that the moment you think of rules that apply to single agents in a system you are approaching that line (and possibly crossing it). For example: when you have specific rules for every type of agent in the system you are designing through a process of Analytic Reduction. Like when you have specific rules for Project Managers to follow; you have specific rules for Developers follow; you have specific rules for Testers to follow; etc. ad infinitum.

A heuristic that I have found useful is to remove rules whenever possible. Scrum, for example, does this by assigning no special role to any team member, but instead giving the team a set of simple rules and boundaries (timeboxed iterations, interaction with PO, Definition of Done, etc.)

This realization led me to understand the critical role that generalists play in facilitating complex adaptive behavior (but that will have to wait for a later post).

Conclusion

Complex adaptive behavior emerges in systems where the rules are simple, and the agents have a high degree of freedom to make decisions. By trying to analyze systems with an reductionist process we are removing the possibility for agents (us, the people) to make intelligent decisions based on their context, and therefore we are reducing the possibility for complex adaptive behavior to emerge. The analytical mindset kills emergence. But more importantly, when it comes to performance Emergence kicks Reductionism in the groin.

If you tell people where to go, but not how to get there, you'll be amazed at the results. - George S. Patton

Next time you are designing a process or an organization take this into account and remove as many rules as you can. That will help you achieve more! Define the goals and let the people surprise you with their results!

Photo credit: John Hammink, follow him on twitter

How injecting randomness into your project can help it succeed

Success and failure differ, very often, by very little. Take nature as an example. A small change in our DNA (a few mutated genes) can have catastrophic consequences. On the other hand, without these mutations humans would never have come into existence.

Humans and other species in the planet evolved because of chance (although not totally chaotic) changes in their DNA. As small change after small change happened, the surviving individuals were able to spread the viable, and ultimately the most adequate changes to the next generation - and the process repeats still in our own bodies today. If Nature has taught us something about improvement and evolution is that you must have a little bit of luck involved!

The DNA of a project

In software projects - my domain - I see some similarities to this natural model that are worth exploring. Projects also have a DNA which includes the structure and the communication connections between individuals. Communication being one of the most quoted causes for failure in software projects, and therefore one of its critical success factors.

The More I Practice the Luckier I Get

Once a project gets started, a particular structure is put in place (governance, management, teams, etc.). Very often that structure remains in place, and static until the end of the project. But is this a smart choice?

Another aspect of the project that rarely changes is the network of connections between the individuals. This network is what carries information from individual to individual and eventually "selects" the information that is acted upon by the project team. If a piece of information reaches an individual in the project, and that individual does not consider it relevant, that information will not spread further. In contrast, when a piece of information is perceived as important by an individual, that information will be actively spread by that individual.

The Illusion of Control

The structure that is set for a project strongly influences the communication links that can emerge between individuals. Who talks to whom? What meetings exist where people interact regularly? etc. But the reverse is also true. The existing communication network within an organization is a strong influence on what governance structure is put in place, how teams are formed, etc. These co-dependent processes create a positive (or negative) spiral of events for the project, but because neither (structure, or communication network) is often changed, that spiral is unstoppable. If it is positive, it will help the project succeed. If this co-dependent processes create, instead a negative spiral, that will relentlessly remove the chances of success for that project.

This co-dependent relation between two key processes (structure and communication network) is why we can increase the chances of success in our projects by simply causing random perturbations in the project. Randomness helps us explore different patterns for structure and communication networks.

As we carefully design and inject small - safe-to-fail - changes into the project, we can observe how it reacts and adjusts. Later, we can retrospectively amplify or remove/dampen the changes based on the outcome we see. If something works, keep it and ask how can you make it grow. If something creates a net negative outcome, dampen or remove it completely.

The cycle goes like this:

• Define and implement small, safe-to-fail changes in the structure or communication network for the project
• These changes lead to emergent behavior as the individuals and teams adapt to the changes
• A new project configuration emerges which drives new project results
• Finally, we evaluate the results of these changes and decide which components we will try to amplify or dampen

What Do You Mean Random?

There are many ways in which we can, randomly, explore better configurations for our projects. Below I list only a few to illustrate the concept:

• At the start of a project, let the teams chose their own composition. This establishes new connections between individuals in the project as some will choose to work with new team members. However, these new connections will not eliminate the previous connections between individuals. The net effect should be that your project now has a more connected communication network (more individuals with strong connections to each other). In practice this works just like when we form new neural connections in our brain: more connections leads to different thinking and acting patterns
• Organize common project events where people interact with each other outside the day-to-day routine. Planning events can be organized following a structured approach, but including also some unstructured time (à lá unconference, using e.g. Open Space) where people can interact based on their interests. This will also help form new connections between individuals in the project and spread information that would otherwise be locked down and not accessible
• Have regular project "coffee breaks" that happen at the same time and same place. In these events people can connect with other individuals and ask questions from the project management team or the most connected individuals in the project. This unstructured communication increases the chance that some piece of information will "jump the hierarchical borders" and reach people in decision-making positions, or people with influence that can later act on that information.

Conclusion

These practices are designed to inject randomness (unplanned situations or connections) into the project. The goal is not to create Chaos (a scary word for many project teams), but to generate new pathways for the information to flow within the project team, as well as novel project structures that are more adapted to the current challenges the teams face.

Using these (or other) practices will increase your project's chances for success. They don't eliminate the need for the project to be managed, or to have structure. They do increase the chance of success for the project by exploring new organizations and structures through a process of small (safe-to-fail) changes that can lead to unplanned, but ultimately superior performance.

These were just a few examples. How would you inject randomness into your project? Have you done that in the past? Please share your experiences in the comments for the benefit of others.

Photo credit: John Hammink, follow him on twitter

Amazing content created by Agile practitioners can change lives

Have you heard of Scrum? An Agile methodology that swept the world by storm? Or Real Options? An approach that can change you manage risk and value in your projects? Or Impact Mapping? Probably the most revolutionary product management and requirements management approach created in the last 10 years?

You can change people's lives

I believe that many of the people attending agile conferences around the world have amazing content to share with the world. I have lately tried to help people get started expressing themselves by sharing what they have learned. And some have already done that. But how to help you?

I have been thinking about what are the obstacles that prevent us from taking the steps to start sharing what we have learned. Some of us are busy, maybe too many things started, maybe we dont feel comfortable with being "out there" and potentially being judged by people that we admire?

Honestly, I dont know. The reasons are different for everyone. What I do know is that I can help you by removing some of the obstacles that stand between you and your future audience. The people that will learn from you, from what you have learned,  from what you have achieved. 

My mind was blown today!

This became very obvious to me today when I was talking to Joe Justice of Wikispeed fame, I was so happy to meet him and to be able to tell, him that I had followed his work for a long time and admired his achievements.  But then he surprised me. He told me that he had learned something that he valued from my talk on #NoEstimates!  My mind was blown. Wow! I created something that somebody liked and that someone was an Agile idol of mine?

The thing is, many of you can do the same! By sharing your knowledge and helping people around you do the same you can change people's lives.

Happy Melly Express: A project to help you

The project that I am working on is

Happy Melly Express. The goal: to help you publish your work, and help your audience grow, touch real people in your community and (probably) change their lives.

Knowledge is a powerful life changer. Remember people believed (knew?) that he Earth was flat, or that waterfall was the right approach to develop software. That has forever changed thanks to people willing to share their stories,  their experience.  When will you do the same?

If you have an idea that can help get Happy Melly Express achieve its purpose share it with me. You can find me on twitter (@duarte_vasco) or via email (duarte_vasco at yahoo).

Story Points Considered Harmful - Or why the future of estimation is really in our past...

This article is the companion to a talk that myself and @josephpelrine gave at OOP 2012.


We have a lot to learn from our ancestors. One that I want to focus on for this post is Galileo.
Galileo was what we would call today a techie. He loved all things tech and was presented an interesting technology that he could not put down. Through that work he developed optic technology to build first a telescope and later a microscope.
Through the use of the telescope and other approaches he came to realize and defend the Heliocentric view of the universe: the Earth was not the center of the Universe, but rather moved around the Sun.
This discovery caused no controversy until Galileo wrote it down and apparently discredited the view held by the Church at that time. The Church believed and defended that the Universe was neatly organized around the Earth and everything moved around our lanet.
We now know that Galileo was right and that the Church was - as it often tends to be with uncritical beliefs - wrong. We now say obviously the Earth is round and moves around the Sun. Or do we...

The Flat Earth Society

Actually, there are still many people around (curious word, isn't it?) the planet that do not even believe that the Earth is round! Don't believe me? Then check The Flat Earth Society.

The fact that is that even today many people hold uncritical beliefs about how our world really works. Or our projects in the case of this post...

Estimation soup

We've all been exposed to various estimation techniques, in an Agile or traditional project. Here are some that quickly come to mind: Expert Estimation, Consensus Estimation, Function Point Analysis, etc. Then we have cost (as opposed to only time) estimation techniques: COCOMO, SDM, etc. And of course, the topic of this post: Story Point Estimation.
What do all of these techniques have in common? They all look towards the future!
Why is this characteristic important?

The Human condition

This characteristic is nt because looking at the future is always difficult! We humans are very good at anticipating immediate events in the physical world, but in the software world what we estimate is neither immediate, nor does it follow any physical laws that we intuitively understand!
Take the example of a goal-keeper in a football (aka soccer) match. She can easily predict how a simple kick will propel the ball towards the goal, and she can do that with quite a high accuracy (as proven by the typically low scores in today's football games). But even in soccer, if you face a player like Maradona, or Beckham, or Crisitiano Ronaldo it is very difficult to predict the trajectory of the ball. Some physicists have spent considerable amount of time analyzing the trajectory of Beckham's amazing free kicks to try to understand how the ball moves and why. Obviously a goal-keeper does not have the computers or the time to analyze the trajectory of Beckham's free kicks therefore Beckham ends up scoring quite a few goals that way. Even in football, where well-known physics laws always apply it is some times hard to predict the immediate future!
The undisputed fact is that we, humans are very bad at predicting the future.
But that is not all!

This is when things get Complex

Lately, and especially in the agile field we have been finding a new field of study: Complexity Sciences.
A field of study that tries to identify rules that help us navigate a world where even causality (cause and effect) are challenged.
An example may be what you may have heard of, the Butterfly effect: "where a small change at one place in a nonlinear system can result in large differences to a later state".
Complexity Sciences are helping us develop our own understanding of software development based on the theories developed in the last few years.
Scrum being a perfect example of a method that has used Complexity to inspire and justify its approach to many of the common problems we face in Software development.
Scrum has used "self-organization", and "emergence" as concepts in explaining why the Scrum approach works. Here's the problem: there's a catch.

Why did this just happen?

In a complex environment we don’t have discernible causality!
Sometimes this is due to delayed effects from our actions, most often it is so that we attribute causality to events in the past when in fact no cause-effect relationship exists (Retrospective Coherence). But, in the field of estimation this manifests itself in a different way.
In order for us to be able to estimate we need to assume that causality exists (if I ask Tom for the code review, then Helen will be happy with my pro-activeness and give me a bonus. Or will she?) The fact is: in a Complex environment, this basic assumption of the existence of discernible Causality is not valid! Without causality, the very basic assumption that justifies estimation falls flat!

Solving the the lack of internal coherence in Scrum

So, which is it? Do we have a complex environment in software development or not? If we do then we cannot - at the same time - argue for estimation (and build a whole religion on it)! In contrast, if we are not in a complex environment we cannot then claim that Scrum - with it’s focus on solving a problem in the complex domain - can work!
So then, the question for us is: Can this Story Point based estimation be so important to the point of being promoted and publicized in all Scrum literature?
Luckily we have a simple alternative that allows for the existence of a complex environment and solves the same problems that Story Points were designed (but failed to) solve.

The alternative prediction device

The alternative to Story Point estimation is simple: just count the number of Stories you have completed (as in "Done") in the previous iterations. They are the best indicator of future performance! Then use that information to project future progress. Basically, the best predictor of the future is your past performance!
Can it really be that simple? To test this approach I looked at data from different projects and tried to answer a few simple questions

The Experiment

• Q1: Is there sufficient difference between what Story Points and ’number of items’ measure to say that they don’t measure the same thing?
• Q2: Which one of the two metrics is more stable? And what does that mean?
• Q3: Are both metrics close enough so that measuring one (number of items) is equivalent to measuring the other (Story Points)?

I took data from 10 different teams in 10 different projects. I was not involved in any of the projects (I collected data from the teams directly or through requests for data in Agile-related mailing lists). Another point to highlight is that this data came from different size companies as well as different size teams and projects.
And here's what I found:

• Regarding Question 1: I noticed that there was a stable medium-to-high correlation between the Story Point estimation and the simple count of Stories completed (0,755; 0,83; 0,92; 0,51(!); 0,88; 0,86; 0,70; 0,75; 0,88). With such a high correlation it is likely that both metrics represent a signal of the same underlying information.
• Regarding Question 2: The normalized data (normalized for Sprint/Iteration length) has similar value of Standard Deviation(equally stable). Leading me to conclude that there is no significant difference in stability of either of the metrics. Although in absolute terms the Story Point estimations vary much more between iterations than the number of completed/Done Stories
• Regarding Question 3: Both metrics (Story Points completed vs Number of Stories completed) seem to measure the same thing. So...

At this point I was interested in analyzing the claims that justify the use of Story Points, as the data above does not seem to suggest any significant advantage of using Story Points as a metric. So I searched for the published justification for the use of Story Points and found a set of claims in Mike Cohn's book "User Stories Applied" (page 87, first edition):

• Claim 1: The use of Story points allows us to change our mind whenever we have new information about a story
• Claim 2: The use of Story points works for both epics and smaller stories
• Claim 3: The use of Story points doesn’t take a lot of time
• Claim 4: The use of Story points provides useful information about our progress and the work remaining
• Claim 5: The use of Story points is tolerant of imprecision in the estimates
• Claim 6: The use of Story points can be used to plan releases

This these claims hold?

Claim 1: The use of Story points allows us to change our mind whenever we have new information about a story

Although there's no explanation about what "change our mind" means in the book, one can infer that the goal is not to have to spend too much time trying to be right. The reason for this is, of course, that if a story changes the size slightly there's no impact on the Story Point estimate, but what if the story changes size drastically?
Well, at this time you would probably have another estimation session, or you would break down that story into some smaller granularity stories to have a better picture of it's actual size and impact on the project.
On the other hand, if we were to use a simple metric like the number of stories completed we would be able to immediately assess the impact of the new items in the progress for the project.
As illustrated in the graph, if we have a certain number of stories to complete (80 in our example) and suddenly some 40 are added to our backlog (breaking down an Epic for example) we can easily see the impact of that in our project progress.
In this case, as we can see from the graph, the impact of a story changing it's meaning or a large story being broken down into smaller stories has an impact on the project and we can see that immediate impact directly in the progress graph.
This leads me to conclude that regarding Claim 1, Story Points offer no advantage over just simply counting the number of items left to be Done.

Claim 2: The use of Story points works for both epics and smaller stories

Allowing for large estimates for items in the backlog (say a 100SP Epic) does help to account in some way for the uncertainty that large pieces of work represent.
However, the same uncertainty exists in any way we may use to measure progress. The fact is that we don’t really know if an Epic (say 100 SPs) is really equivalent to a similar size aggregate of User Stories (say 100 times 1 SP story). Conclusion: there is no significant added information by classifying a story in a 100 SP category which in turn means that calling something an "Epic" is about the same information as classifying it as a 100 Story Points Epic.

Claim 3: The use of Story points doesn’t take a lot of time

Having worked with Story Points for several years this is not my experience. Although some progress has been done by people like Ken Power (at Cisco) with the Silent Grouping technique, the fact that we need such technique should dispute any idea that estimating in SP’s "doesn’t take a lot of time". In fact, as anybody that has tried a non-trivial project knows it can take days of work to estimate the initial backlog for a reasonable size project.

Claim 5: The use of Story points is tolerant of imprecision in the estimates

Although you can argue that this claim holds - even if the book does not explain how - there's no data to justify the belief that Story Points do this better than merely counting the number of Stories Done. In fact, we can argue that counting the number of stories is even more tolerant of imprecisions (see below for more details on this)

Claim 6: Story points can be used to plan releases

Fair enough. On the other hand we can use any estimation technique to do this, so how would Story Points be better in this particular claim than any other estimation technique? Also, as we will see when analysis Claim 4, counting the number of Stories Done (and left to be Done) is a very effective way to plan a release (be patient, the example is coming up).

Claim 4: The use of Story points provides useful information about our progress and the work remaining

This claim holds true if, and only if you have estimated all of your stories in the Backlog and go through the same process for each new story added to the Backlog. Even the stories that will only be developed a few months or even a year later (for long projects) must be estimated! This approach is not very efficient (which in fact contradicts Claim 3).
Basing your progress assessment on the Number of Items completed in each Sprint is faster to calculate (number of items in the PBL / velocity in number of items Done per Sprint = number of Sprints left) and can be used to provide critical information about project progress. Here's a real-life example:

The real-life use of a simpler metric for project progress measurement

In a company I used to work at we had a new product coming to market. It was not a "first-mover" which meant that the barrier to entry was quite high (at least that was the belief from Product Management and Sales).
This meant that significant effort was made to come up with a coherent Product Backlog. The Backlog was reviewed by Sales and Pre-Sales (technical sales) people. All agreed, we really needed to deliver around 140 Stories (not points, Stories) to be able to compete.
As we were not the first in the market we had a tight market window. Failing to meet that window would invalidate the need to enter that market at all.
So, we started the project and in the first Sprint we complete 1 single Story (maybe it was a big story -- truth is I don't remember). Worst, in the same period another 20 stories were added to the Product Backlog. As expected, the Product Management and Sales discovered a few more stories that were really a "must" and could not be left out of the product.
The team was gaining speed and in the second Sprint they got 8 stories to "Done". They were happy. At the same time the Product Manager and the Sales agreed to a cut-down version of the Product Backlog and removed some 20 stories from the Backlog.
After the third sprint the team had achieved velocities of 1 (first Sprint), 8 (second) and 8 (third). The fourth sprint was about to start and the pressure was high on the team and on the Product Manager. During the Sprint planning meeting the team committed to 15 new stories. This was a good number, as a velocity of 15 would make the stakeholders believe that the project could actually deliver the needed product. They would need to keep a velocity of 15 stories per sprint for 11 months. Could they make it?

The climax

As the fourth sprint started I made a bet with the Product Manager. I asked him how many items he believed that the team could complete and he said 15 (just as the team had committed to). I disagreed and said 10. How many items would you have said the team could complete?
I ask this question from the audience every time I tell this story. I get many different answers. Every audience comes up with 42 as a possible answer (to be expected given the crowds I talk to), but most say 8, 10, some may say 15 (very few), some say 2 (very few). The consensus seems to be around 8-10.
At this point I ask the audience why they would say 8-10 instead of 15 as the Product Manager for that team said. Obviously the Product Manager knew the team and the context better, right?
At the end of the fourth sprint the team completed 10 items, which even if it was 20% more than what they had done in previous sprints was still very far from the velocity they needed to make the project a success. The management reflected on the situation and clearly decided that the best decision for the company was to cancel that product.

Story Points Myth: Busted!

That company did that extremely hard decision based on data, not speculation from Project Managers, not based on some bogus estimation using whatever technique. Real data. They looked at the data available to them and decided to cancel the project 10 months before its originally planned release. This project had a team of about 20 people. Canceling the project saved the company 200 man-month of investment in a product they had no hope of getting out of the door!
We avoided a death-march project and were able to focus on other more important products for the company's future. Products that now bring in significant amount of money!

OK, I get your point, but how does that technique work?

Most people will be skeptical at this point (if you've read this far you probably are too). So let me explain how this works out.
Don't estimate the size of a story further than this: when doing Backlog Grooming or Sprint Planning just ask: can this Story be completed in a Sprint by one person? If not, break the story down!
For large projects use a further level of abstraction: Stories fit into Sprints, therefore Epics fit into meta-Sprints (for example: meta-Sprint = 4 Sprints). Ask the same question of Epics that you do of Sprints (can one team implement this Epic in half a meta-Sprint, i.e. 2 Sprints?) and break them down if needed.

By continuously harmonizing the size of the Stories/Epics you are creating a distribution of the sizes around the median:


Assuming a normal distribution of the size of the stories means that you can assume that for the purposes of looking at the long term (remember: this only applies on the long term, i.e. more than 3 sprints into the future) estimation/progress of the project, you can assume that all stories are the same size, and can therefore measure progress by measuring the number of items completed per Sprint.

Final words

As with all techniques this one comes with a disclaimer: you may not see the same effects that I report in this post. That's fine. If that is the case please share the data you have with me and I'm happy to look at it.
My aim with this post is to demystify the estimation in Agile projects. The fact is: the data we have available (see above) does not allow us to accept any of the claims by Mike Cohn regarding the use of Story Points as a valid/useful estimation technique, therefore you are better off using a much simpler technique! Let me know if you find an even simpler one!

Oh, and by the way: stop wasting time trying to estimate a never ending Backlog. There's no evidence that that will help you predict the future any better than just counting the number of stories "Done"!

How do I apply #NoEstimates to improve estimation? Here's how...

Photo credit: write_adam @ flickr