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! 

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

Humans suck at statistics - how agile velocity leads managers astray

Humans are highly optimized for quick decision making. The so-called System 1 that Kahneman refers to in his book "Thinking fast, thinking slow". One specific area of weakness for the average human is understanding statistics. A very simple exercise to review this is the coin-toss simulation.

Humans are highly optimized for quick decision making.

Get two people to run this experiment (or one computer and one person if you are low on humans :). One person throws a coin in the air and notes down the results. For each "heads" the person adds one to the total; for each "tails" the person subtracts one from the total. Then she graphs the total as it evolves with each throw.

The second person simulates the coin-toss by writing down "heads" or "tails" and adding/subtracting to the totals. Leave the room while the two players run their exercise and then come back after they have completed 100 throws.

Look at the graph that each person produced, can you detect which one was created by the real coin, which was "imagined"? Test your knowledge by looking at the graph below (don't peak at the solution at the end of the post). Which of these lines was generated by a human, and which by a pseudo-random process (computer simulation)?

One common characteristic in this exercise is that the real random walk, which was produced by actually throwing a coin in the air, is often more repetitive than the one simulated by the player. For example, the coin may generate a sequence of several consecutive heads or tails throws. No human (except you, after reading this) would do that because it would not "feel" random. We, humans, are bad at creating randomness and understanding the consequences of randomness. This is because we are trained to see meaning and a theory behind everything.

Take the velocity of the team. Did it go up in the latest sprint? Surely they are getting better! Or, it's the new person that joined the team, they are already having an effect! In the worst case, if the velocity goes down in one sprint, we are running around like crazy trying to solve a "problem" that prevented the team from delivering more.

The fact is that a team's velocity is affected by many variables, and its variation is not predictable. However, and this is the most important, velocity will reliably vary over time. Or, in other words, it is predictable that the velocity will vary up and down with time.

The velocity of a team will vary over time, but around a set of values that are the actual "throughput capability" of that team or project. For us as managers it is more important to understand what that throughput capability is, rather than to guess frantically at what might have caused a "dip" or a "peak" in the project's delivery rate.

The velocity of a team will vary over time, but around a set of values that are the actual "throughput capability" of that team or project.

When you look at a graph of a team's velocity don't ask "what made the velocity dip/peak?", ask rather: "based on this data, what is the capability of the team?". This second question will help you understand what your team is capable of delivering over a long period of time and will help you manage the scope and release date for your project.

The important question for your project is not, "how can we improve velocity?" The important question is: "is the velocity of the team reliable?"

Picture credit: John Hammink, follow him on twitter

Solution to the question above: The black line is the one generated by a pseudo-random simulation in a computer. The human generated line is more "regular", because humans expect that random processes "average out". Indeed that's the theory. But not the the reality. Humans are notoriously bad at distinguishing real randomness from what we believe is random, but isn't.

As you know I've been writing about #NoEstimates regularly on this blog. But I also send more information about #NoEstimates and how I use it in practice to my list. If you want to know more about how I use #NoEstimates, sign up to my #NoEstimates list. 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

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

Kanban vs Scrum, the ultimate fight? Don't think so, here's why:...

Wow, what a week! A BIG post on Kanban by Scrum evangelist @jcoplien litterally put the blogosphere (and twittersphere on fire!).

It is good to have these family fights in the Agile family once in a while. As a life-philosopher once said: "These things gotta happen every five years or so, ten years. Helps to get rid of the bad blood".

But what are the differences between Kanban and Scrum, really? What are they?

Here's my take on the differences:

Kanban innovation

Kanban is, from it's origin a more systematic approach to measuring, visualizing and following up work in a "system" (one team, many teams, a company you name it). Thanks to the work by the Poppendiecks, David Andersson and Don Reinertsen (and others I'm sure) a pretty interesting and innovative economic framework as been put into the software process development lingo. Cost of Delay, Queues, optimize the whole, etc.
This economic framework is, in my view, the major innovation that Kanban proponents bring to the table. This was to be expected as many of the early adopters of Kanban were using Scrum before and felt the need to quantify and analyze some aspects of software development that Scrum did not tackle.

Scrum innovation

Scrum brought to the fore-front of process discussions issues that had never made it to our attention before: Self-organization, people/team dynamics, problem solving within a short cycle with feedback loops in place (Sprint), etc.
The major innovation of Scrum in my view was the introduction of the Socio-technical system of software development as Liker describes it in the Toyota way. Other similar software development processes took some of the ideas that Scrum also took, but shied away from the self-organization at the team level and blocker-removal focus of roles such as the scrum master. Those methods did not last long because the teams felt like puppets instead of adults with the possibility (and responsibility) to produce the best product they could.

Wrap-up

Both Kanban and Scrum brought significant innovations to the software development world. Those are just two types of innovations. There is more coming from the community and instead of focusing only on these two methods (which all of you should experiment with!) we should also look at what else is missing in the software development ecosystem.
My next interest area is "Complex Systems" (Complexity + Systems Thinking) and Management as a profession. I'll be exploring those subjects more and more in the future as a way to complement my use of Kanban *AND* Scrum. I suggest you do the same and find what else is missing in your environment and look for what else is around that could help you complement what you are already using. Here's a suggestion: start with @jurgenappelo's book on Management!

Happy reading, happy learning!

Kanban in a networked process -- Visualise the network!

It seems that the idea of a work-network instead of work-flow is catching on and I'd like to throw a bit more fuel in that fire!

Knowledge work is not linear! This we have learned from the experiences with failed Waterfall projects. There are things we do over and over again, and there are things we do only once in a project. None of those can easily be predicted. Scrum and Kanban are examples of our quest to distill what we do to the bare essential. Only then can we understand and manage our work.

Scrum does this by strictly limiting the work in progress through the concept of time boxes. The idea is: do something that fits a (reasonably) short timebox, and nothing else. Get that done and released before you go on to the next thing.

Kanban does this by strictly obeying Work In Progress (WIP) limits and establishing a Pull system (instead of push as much content as you can into an iteration). Both have pros and cons which I will not discuss here. http://www.blogger.com/img/blank.gif

But most interestingly, both tackle the flow of our work in a linear fashion. Both Scrum and Kanban assume that some work can "flow" orderly to completion. However that is not the case! In knowledge work we have many loops and re-loops in the process that are hard to visualize and follow. Without visualizing those loops we cannot effectively manage our work!

Jurgen Appelo and Allan Shalloway had (what looks like was) an interesting discussion on the non-linearity of work and consequently on the non-linearity of Kanban boards. Check out Jurgen's and Allan's posts on the subject.

Since I've been experimenting with Personal Kanban for 3 months now I'd like to share some of my own experiences.

The picture below depicts my process boards as they evolved (click for larger images). The initial one was simple and linear, and it did not disclose enough information for me.


The second one was much better in highlighting some of the bottlenecks in my process (waiting for my action, waiting for others action, waiting for meeting), but was still too linear to reflect the work in a way that was useful to visualize.


The final Kanban board is actually what I use now and is a slight modification of the second one. As you can see it depicts the networked nature of my work and therefore also helps me set my WIP limits appropriately (for example why not have many things waiting for meetings?).


A conclusion of mine from the above boards is that it is not possible to set WIP limits without understanding the work (for example what "wait" states do you have in your process). On the other hand, trying to follow the WIP limits you have set will help you visualize those "wait" states as a consequence of the search for sustainable WIP limits

How about you? What are your experiences in using Kanban boards or other visualization techniques to uncover the networked nature of our work? Leave a comment below with a link to your post!

Photo credit: sjcockell @ flickr

We continue to miss the point. It is not Kanban vs. Scrum, it is "people over process"!

The Scrum vs. Kanban debates rage on in the blogosphere but I can't help but feel that our Agile community is missing the point.

Where is the "People and interactions over processes and tools" that is part of the core values?

I commented on Rachel Davies's post about what she calls W-Agile (waterfall disguised as Agile, I guess). In that post she identifies very correctly a typical anti-pattern of agile adoption (read the post, it is worth it).

However in the comments she continues one thread with which I disagree, and I think the evidence for my argument is easily found around us.

Rachel states:

Vasco, You say "I disagree with the statement that Kanban can do anything to help the W-agile teams." I find this an odd thing for you to say and wonder if this is a gut reaction or based on experience?

I have seen Kanban help make the end-to-end workflow visible as a first step to improve those invisible parts. I don't see doing that as incompatible with Scrum.

My assertion is that Kanban *alone* cannot help where other methods have failed unless *people* change their way of thinking by way of adopting the Kanban (or any other) ideas. Sure, people can change, and many of us have changed our mindset when adopting iterative software development, then XP, then Scrum and recently Kanban. That's a fine argument to make, i.e.: Kanban can bring things to people's eyes that other methods have failed to *and* change the way people behave. But that is a totally different than saying "Kanban brings success"!.

Please note that the key ingredient here is not Kanban (or Scrum, or XP), but the fact that people *change* their views, prejudices, etc.

From this quickly follows the following proposition / hypothesis:
A new method can make a team succeed if and only if the person (or people) helping the team adopt the method succeeds in changing the team's behavior.

Proving this hypothesis is rather simple: just look around you.

1. Have you seen teams succeed with some method and other reams fail with the same method? I have. Many. Generalizing this observation proves that *a* method alone cannot make a team succeed (no matter the method).
   
   
2. Have you see teams succeed while adopting method X with the help of person A while previously having failed to adopt the same method when helped by person B? I have. I have been person B and A myself! -> this proves that a person(mentor/coach) can have more impact than the method itself.
   

Given that a mentor/coach can have a larger influence on the team's adoption of a method than the method itself, and that the same method can lead to success or failure (Jurgen's argument as well) then it follows that method alone cannot be a pre-condition for success or for failure.

At the end of the day it is about getting the right help (or changing the help if it is not working) to adopt a method that fulfills your business goals (whatever that method may be).

Agility is about providing business value, not about methods.

Photo credit: David Kingham @ flickr

The Kanban vs Scrum argument stinks! But, can we learn anything from it?

There were some interesting conversations on twitter last evening, so interesting that they are worth some comment.

There was an interesting back-and-forth between @jurgenappelo and @agilemanager about whether it is possible to do Scrum in a "pull" mode or not as well as other issues. But this was just the tip of the iceberg of the Kanban vs Scrum discussion. Here's one comment that caught my eye:



Here @agilemanager is trying to prove that Scrum cannot be done "right" because of inherent problems, specifically that velocity is so unstable that it cannot be used for planning. That argument, however, is easily proven wrong.
Here is a graph of a team implementing scrum, using velocity to plan for success and with a rather stable velocity. (Technically the velocity is "under control" as defined in statistical process control).



This tells us that it is possible (unlike @agilemanager states) that using Scrum planning based on velocity is possible. And in fact that's the main long term planning metric that I've used in the past with success.
The fact that we have a (statistically) controlled velocity allows us also to do other things like identify common causes and special causes that will require different action/intervention with the team in order to improve their overall result.

Then @jgoodsen pitched in with this comment:



Here @jgoodsen is disagreeing with @jurgenappelo's statement that as Kanban gets wider adoption it too will be mis-applied and lead to failure. This type of extreme position taking is an example of why the discussion between Scrum-mendalists and Kanban-istas is quite useless for the rest of us that are interested in learning more.

The point is: Kanban, just like Scrum, initially is being practiced by early adopters. People that tend to read and study things more and earlier. These are also typically people that are given a license to experiment, to try out new things.
In the end the effect is that, typically, early adopters are better at adopting new methods because they have done that more often (they are early adopters after all). Kanban is just another method/framework/whatever, it will succeed and fail as much as Scrum does. @jurgenappelo is right, any method fails when applied by a population large enough.

The takeaway from this discussion for us should be that methods, ultimately, are irrelevant. It is the learning achieved by experimenting that matters.

We should be sharing our learning, not our method allegiance!

We need Proof!: Talk at Agile Saturday in Tallin

Last week I had the honor to present the keynote at Agile Estonia's first public event. Agile Saturday was full of people from that community and it was great to learn how that community is being developed.

The organizers also filmed the event, so here is the link to my talk video and slides.

Enjoy!

Agile Saturday #1 Keynote by Vasco Duarte from Anton Arhipov on Vimeo.

We need proof! - Talk at Agile Estonia's Agile Saturday

View more presentations from Vasco Duarte.

On how PMBOK Change management creates variability and reduces predicatbility

In the last post I tried to point out how the analytical approach of any standard (and specifically PMBOK's) will create problems for those actually having to implement those standards.
Change management in PMBOK is a particularly large problem in this respect. Scope Control (PMBOK's process for change management in scope) comes at 19 different activities. This will leave the most experienced project manager grasping for air when it comes to implementing these activities (they are not implemented in a vaccum obviously, but that does not make it easier...)

Contrast that with the approach that Scrum uses: Re-plan every sprint based on the improved knowledge you have of the product and the market.

Now, that's simple! Simple, but not easy.

For Scrum's change management to work properly the people in charge need to understand the stakeholders needs, the market needs and the current state of development. None of these is easy to achieve, but -- and this is the point -- they are easy to explain.

In Scrum, every Sprint will have a small number of ceremonies:

• The Sprint planning: where the previous sprint's result as well as the changes in environment (stakeholders, market, etc.) are input for the planning process
  
• The Daily meeting: where the progress is reviewed and plans quickly adjusted to meet the Sprint goals
  
• The Sprint review + demonstration: where the status of development is analyzed as well as the reasons for possible problems
  
• The Retrospective: where we analyze what went well/wrong and take actions based on that to improve for the next Sprint, i.e. change our process.
  

That's it. That's how Scrum addresses change in scope: by being prepared for it at the very core of the process. Every sprint change is reviewed and handled. Plans are adjusted.

Interestingly this has an important (yet often forgotten side-effect). Because the stakeholders know that their needs will be taken into account in the next Sprint at the latest, they don't feel the need to disturb the teams during the Sprint. This allows the team to focus on the ongoing work and meet their Sprint goals while at the same time not avoiding change, rather embracing it!

Implementing a process based on PMBOK will not take this aspect into account. It is my experience that in practice, a PMBOK based approach will lead to a separate change management process (often through Change Management Boards), which will regularly but at unpredictable intervals submit changes to the teams. Teams, then need to react "immediately" to those changes: reviewing, commenting and sometimes even accepting them. Anyone familiar with Queuing Theory recognizes this problem immediately: adding more work to a team will make them late and reduce predictability because of the added variability inherent in the "change" related tasks.

This is why PMBOK fails when it separates processes like change management into their own "process" within a larger process which is a software development process.

I should however emphasize: there is value in PMBOK. Read it if you can, but you should not follow PMBOK when defining your processes. Rather you should look at Scrum, Kanban or other processes for inspiration on how to run your software development processes. This is because PMBOK is useful, but not enough!

Photo credit: Will Lion @ Flickr

Can Scrum and Kanban be used for non-software development work?

Can Scrum or Kanban be used to manage any other work than software development? Do the same concepts apply?

The past week-end there's been some chatter on twitter about using Kanban or Scrum for managing work outside the software development realm.

People seem (pleasently) surprised that it can be done. But can it really? The answer is YES! But why do methods that were clearly developed with software development in mind expand to manage other type of work?

Well, we have to look at the roots of these methods to understand that. Both Kanban and Scrum based their core practices around a list of "stuff" to do. Features/stories in software development fills these lists or backlogs, but in an advertising agency, for example, the "stuff" will be something like drawing proposals for clients, brainstorming meetings, research work, etc.

Through these lists, Kanban and Scrum establish an order of work (what to do now?) and allow what is normally a disconnected mass of work to be organized in a way that a team can use, not only to execute, but also to follow-up their work (e.g. through a burndown/burnup chart)

Indeed, at the root both Kanban and Scrum are just formalized work management methods that were created to overcome the chaos that is still so normal in software development organizations. The hidden truth however, is that the same chaos is present elsewhere and those companies can benefit as much from Scrum/Kanban as the software industry is benefiting now.

The corollary of this is that Scrum/Kanban can be used to do anything, from building a space ship to planting potatoes, and I have even used it for personal non-software development work as well as helped others establish some of the ideas behind Scrum as their own "working method".

There's a catch, though!

Getting back to the backlogs, both these methodologies need a steady stream of work to be analyzed, prioritized and ultimately picked up to be worked on. Because the constraint (i.e. the part in the system that is always busy) in the process is normally the project team, it is imperative that special attention be given to the backlog, where work is listed and described. It is often a good practice to regularly spend time analyzing the work in the backlog to make sure that it fits the Vision for the product/project and that it is sufficiently well defined so that the team will not lose their time trying to figure out what the work-item really means.

For this we normally have a manager (called product owner in Scrum) whose time is spent analyzing the project/product and deciphering the customer needs into a format that the team can understand.

This work is crucial, and the real reason why teams need "managers" (product owner in Scrum).

Manage your work for better performance

The key message here is this: Your work performance will only be as good as you are at managing the backlogs.

Because Scrum/Kanban are work management methods, it follows that the team's performance will depend heavily on how the backlogs are managed by the team and their manager. Therefore, the hidden pearl in Scrum and Kanban is that you should focus a lot (but not all) of energy in defining and improving how your manage your work. And this is valid for any type of work. Be it software or creative projects in an advertising agency.

Response to critical article on Kanban

I was reading Chris McMahon's post "Against Kanban" and could not help but think that a response was in order. The post below is a response, in detail to the (flawed) arguments that Chris makes against Kanban.

"were revolutionary, because they were software development processes actually created from scratch by people who were very very good at creating software."

In here, however you forget that Mike Beedle and Ken Schwaber explicitly mention the chemical industry as a source of learning when putting together the explanation for the success of Scrum.
You further forget that Jeff Sutherland (and others) have often referred to Takeuchi's and Nonaka's paper (The New New product development game) that is straight from, you guessed it: manufacturing!

"if your team measures velocity and uses velocity to plan iterations, and if your team always does pair programming, test-driven development, and continuous integration, then you will either release excellent software every iteration; or you will quickly expose and face the reasons why not."

In this phrase you seem to imply that one cannot use the same XP practices with Kanban. Here again you are wrong. All of the practices that make Scrum "work" can be used to make Kanban "work".

"Before we started releasing every iteration, my team had been using a kanban-like process."

This argument is disingenuous. You should have said that you did not have timeboxed iterations. Kanban is much more than not having timeboxed iterations and you fail your readers when you associate a previously used process (not working by your own admission) with something you quite clearly do not fully grasp. A bit like what you blame on your so called "kanban expert".

"Furthermore, it was an enormous headache for the marketing people. Without timeboxes or estimates, it was difficult to know when a particular feature would be available, which made it almost impossible to do effective marketing for the product."

If you had any experience with Kanban or indeed if you knew more about Lean you would know that this phrase does not make any sense in the Lean context. In a (properly working) Lean process you always know when you are going to ship something, that's why Lean is being adopted in the first place. The fact taht you state lack of predictability as a problem inherent to Kanban just means that you don't understand it -- which is fair, but in that case you should not write condemning articles, you should first prove your Hypothesis (BTW: the Hypothsis-Test-Theory cycle, aka PDCA, is at the heart of Lean. Just google for "a3 report problem solving")

"The fundamental difference between software development and manufacturing or engineering is that in software development we do not manipulate physical objects."

This is an obvious truth, but you don't explain the consequences of this phrase. The (other) fact is that manufacturing, like other industries, are very process oriented and processes from all industries have similar theoretical frameworks! Therefore what you learn from processes in the chemical industry (to use Beedle and Schwaber's example) can be used in the software industry!

"I'm sympathetic to those who see estimation and iteration planning as waste, but I think the risk inherent in not having a mechanism to expose our inadequacies is too much risk to take, even for the best of teams."

In this phrase you make an implicit sylogism by which not having estimation and iteration planning leads to not being able to see what is wrong. This is clearly due to your lack of understanding of how a "flow" process can work. In a flow-like process (e.g. Kanba) you don't just retrospect at the end of the iteration (there's none), you retrospect much more frequently, even sometimes a day. This is indeed a much more powerful way to expose "inadequacies" as any tester knows.

"can you deliver running tested features on a consistent schedule? Iteration timeboxing exposes that metric in the most obvious way possible."

I agree that timeboxing exposes the features delivered/iteration metric. Heck, I've been using that metric myself to explain why you don't actually need to estimate (one of the basic problems in Kanban according to you). The point is that the metric you say is impossible to gather with Kanban is the very metric that makes Kanban transparent to the business owners (the cycle time, or how long does it take to deliver 1 feature). You seem to have missed this point also.

"What we find in both literature and anecdote about the application of processes taken from manufacturing and engineering, puzzlingly, is that for every team for which the process is successful and helpful, there are other teams who implement the same process only to meet with failure.

What I suspect is that ANY process or methodology (that is not actively destructive), applied to a skilled, disciplined, high-functioning, motivated team, will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail."

I agree with these two paragraphs, but the same is true (like you say) for ANY process, even those that did not originate from the manufacturing industry. At this point your post is contradicting itself...

"With an XP/Scrum sort of iterative process, we will know very soon exactly how and why we are failing. This seems to be not true of kanban or of any other software development process taken from the manufacturing arena."

Having read the other comments above you know how false this statement is. The point is that in Kanban restrospectives are part of everyday work (when it is working), therefore you actually find out "how and why we are failing" much faster than in a timeboxed iteration-based process!

Maybe you should also take a look at this post: http://bit.ly/7NhAg in it the author claims (and I can't verify it) that they release software 50 times a day. If you get to that point, what's the reason to have iterations. By your own metric (features released/iteration) this team is already over achieving to the point of making the metric useless...

The world is not ready...

While reading a post and associated Twitter chatter between Karl Scotland and others I got to think that the world is not yet ready. For what? For flow. The idea that if you do one thing (to Done) first and then start working on another thing and get that to Done, you will be faster (maybe even much faster) than if you try to do too many things at the same time.

The same is also true for teams. If a team starts working on the top story of a backlog and does not stop until that story is Done, and only then picks up another story, then I propose that that team will be faster (over the long term) and produce less bugs (over the long term). The idea is simple yet counter-intuitive.

Those that oppose this idea say that if you are "stuck" in some part of a Story you should leave it waiting for input (maybe from another team) and start working on another task coming back to the original task once it has been "unstuck".

Said this way people tend to believe that it becomes therefore more efficient to work on several tasks so that you are never "stopped and waiting" or waiting for a story to be ready before picking up the next, but rather always "producing". Common sense you would say? Well, I propose that, in this case common sense is wrong.

If you work on one task and then interrupt that task at some point you will be faced with the waste of context switching when you finally come back to the original task -- not to mention that you just broke the prioritization because presumably the first task had higher priority.

The world may not be ready, but if you are I encourage you and your team to experiment with "Kanban" or "Scrumban" or (as I like to call it) "Lean".

Whatever you do, always use your brain. There's no substitute for that.