It is now official, I'll be speaking at Agile Eastern Europe. Hope to see you there!

I'll be hosting a workshop and a talk. Both are about the business view of software development. One will be specifically about Agile:

• Business Agility. How to take advantage of an Agile R&D?
  
  Many companies have jumped on the Agile bandwagon. That's good, but what for? In this talk we explore the consequences and possible benefits of adopting Agile for your Business. It's not enough to benefit your R&D, we need to learn how Agile can help our whole company.
  

The other talk will be more generic, but about something that is critical for Agile teams: a workshop about creating a Vision that speaks to the team and can therefore guide the software development:

• Workshop "From an idea to a Vision you can implement"
  
  You've been there. You are tasked with implementing a product that someone else cooked up. What do do next? Follow the spec you say? Wrong!
  
  Developing a product without this Vision is not just waste, it is bad business for you and for your customer.
  
  Before we start implementing any product we must explore it's reason to exist, what customers it benefits and ultimately how it can help your customers (not you!) make money.
  
  In this workshop we will take an example and go through a simple process that helps us explore a product idea to the point that a spec is just a reference, but the product comes alive in the minds of the team members.
  

Walking a tightrope without a net maybe good entertainment, but it's hardly what project teams enjoy the most. 

When the deadline comes and your team is late, you know why that is. No matter how well you plan (and you must) there will always be a volcano or a flood or simpler things like changing requirements or power-outages that will delay the project.

Delays are inevitable, we plan to get rid of the obvious ones, we do creative risk management to get rid of the less obvious ones, but ultimately it is impossible to avoid problems! It is smarter to be ready to deal with problems when they do happen.

This is why I liked this post by Dave Snowden about two seemingly contradictory strategies to deal with environmental disasters (or project problems, which ever applies to you). In the post he states:

They did recognise that some failures were inevitable, so they focused on speedy detection and fast recovery. In other words they adopted a strategy of resilience rather than one of robustness.  

There's no reason why you should use only one of these strategies in your projects, in fact they are complementary. Investing in planning is about implementing a "robust" strategy. Investing in adaptation mechanisms (like iterations, re-planning, demo with retrospectives, etc.) is about implementing a "resilient" strategy.

It is insane to think that a single-minded focus on "resilience" is a good idea, but so is a single-minded focus on "robustness"! Why do so many projects prefer either over the other? 

Photo credit: wollbinho @ flickr

In a meeting today I was graphically reminded of how some of the basic concepts in software development still escape many of us. Case in point, the meaning of capacity.

In many people's minds capacity still means "how many man-hours we have have available for real work". This is plain wrong.

Let's decompose this assumption to see how wrong it is.

1.  First, in this assumption is implicit that we can estimate exactly how many man-hours we have available for "real work". The theory goes like this: I have 3 people, the sprint is 2 weeks/10 days, so the effort available, and therefore capacity, is 30 man-days. This is plain wrong!!! How? let's see:
   
   
   
   1.  Not all three people will be doing the same work. So, even if you have a theoretical maximum of 30 man-days available not all people can do the same work. If, for example, 1 person would be an analyst, another a programmer and finally the third a tester, then that would leave us with effectively 10 man-days of programming, analysis and testing effort available. Quite different from 30 man-days!
      
   2. Then there's the issue that not 100% of the time available for each people can actually be used for work. For example, there are meetings about next sprint's content, then there's interruptions, time to go to the toilet... You get the picture. In fact it is impossible to predict how many each person will use for "real" work.
      
   
   
2. Then there are those pesky things we call "dependencies". Sometimes someone in the team is idle because they depend on someone else (in or out of the team) and can't complete their feature. This leads to unpredictable delays, and therefore ineffective use of the effort available for a Sprint.
   
3.  Finally (although other reasons can be found) there's the implicit assumption that even if we could know perfectly the amount of effort available we can know how much some piece work actually takes from beginning to end, in exact terms! This is implicit in how we use the effort numbers by then scheduling features against that available effort. The fact is that we (humans) are very bad at estimating something we have not done before, which is the case in software most of the time.

The main message here is: effort available (e.g. man-hours) is not the same as capacity. Capacity is the metric that tells us how many features a team or a group of teams can deliver in a Sprint, not the available effort!
Implications of this definition of capacityThere are some important implications of the above statement. If we recognize that capacity is closer to the traditional definition of Throughput then we understand that what we need to estimate is not just size of a task, plus effort available. No, it's much more complex than that! We need to estimate the impact of dependencies, errors, meetings, etc. on the utilization of the effort available.

Let me illustrate how complex this problem is. If you want to empty a tank of 10 liters attached to a pipe, you will probably want to know how much water can flow through the pipe in 1 minute (or some similar length of time) and then calculate how long it takes to completely empty the tank. Example: if 1 liter flows through the pipe in 1 minute then it will take 10 minutes to empty a 10 liter tank. Easy, no?

Well, what if you now try to guess the time to empty the same tank but instead of being given the metric that 1 liter of water can flow in the piper for each minute, you are instead given:

• Diameter of the pipe
  
• Material that the pipe is built in
  
• Viscosity of the liquid in the tank
  
•  Probability of obstacles existing in the pipe that could impede the flow of the liquid
  
• Turbulence equations that allow you to calculate flow when in the presence of an obstacle
  

Get the point? In software we are in the second situation! We are expected to calculate capacity (which is actually throughput) given a huge list of variables! How silly is that?!
For a better planning and estimating frameworkThe fact is that the solution for the capacity (and therefore planning) problem in software is much, much easier!

Here's a blow by blow description:

• Collect a list of features for your product (not all, just the ones you really want to work on)
  
• With the whole team, assess the features to make sure that neither of them is "huge" (i.e. the team is clueless about what it is or how to implement it). If they are too large, split them in half (literally). Try to get all features to fit into a sprint (without spending a huge effort in this step). 
  
• Spend about 3 sprints working on that backlog (it pays off to have shorter sprint!)
  
• After 3 sprints look at your velocity (number of features completed in each sprint) and calculate an average
  
• Use the average velocity to tell the Product Owner how long it will take to develop the product they want based on the number of Features available in the backlog
  
• Update the average expected velocity after each sprint

Does it sound simple? It is. But most importantly, I have done many experiments based on this simple idea, and I'm yet to find a project where this would not apply. Small or big, it worked for all projects where I've been involved in the past.
The theory behindThere's a couple of principles behind this strategy. First, it's clear that if you don't change the team, the technology or any other relevant environmental variable the team will perform at a similar level (with occasional spikes or dips) all the time. Therefore you can use historical velocity information to calculate a long term velocity in the future! 
Second, you still have to estimate, but you do that at the level of one Sprint. The reason is that even if we have the average velocity, an average does not apply to a single sprint but rather to a set of sprints. Therefore you still need to plan your sprint, to identify possible bottlenecks, coordinate work with other people, etc.
The benefitsFinally the benefits. The most important benefit here is that you don't depend on estimations based on unknown assumptions to make your long term plans. You can rely on data. Sure, sometimes the data will be wrong, but compare with the alternative: when was the last time you saw a plan hold up? Data is your friend!
Another benefit is that you don't need to twist anyone's arm to produce the metrics needed (velocity and number of features in backlog), because those metrics are calculated automatically by the simple act of using Scrum.

All in all not a bad proposition and much simpler than working with unavoidably incorrect estimates that leave everybody screaming to be saved by the bell at the end of the planning meeting!

Photo credits:
uggboy @ flickr
johnmcga @ flickr

I get very often shocked by the comments that I hear from supposedly very smart people. Today was no exception. I heard the following comment:
There is content we don't want to timebox, therefore there's no need to link it to any timeline...
-- Quote from someone that has direct responsibility over scope in a project (my emphasis)

This quote betrays a complete misunderstanding of the dynamics of software development, and a complete (albeit unintentional) ignorance of the market forces we need to deal with.

Here's my point: by scope-boxing a particular Feature what we are doing is effectively giving up control of it's size. Once the team is given the Feature they will work on it until it is "perfect", that means we don't have a clue when it will be done and therefore the schedule for that feature is completely unpredictable! Yes, sure we will stop development on it at some point, but will it happen before it is too late?

The advantage of timeboxing the content for a Feature (Feature must fit in a Sprint) is that we have a clear deadline at which point we evaluate if the feature is ready to go to the market! Without this constraint the team is left "alone" to decide when the feature is ready. But the team is the wrong actor to decide when a feature is ready! The product owner should be doing that work based on market intelligence, user knowledge, etc.

By scope boxing (as opposed to timeboxing) our features we are effectively giving up control of our projects!

Why is it so hard to understand this point? Where is my reasoning missing clarity?

Can you help?

Photo credit: danielygo @ flickr

Many of the readers of this blog have probably faced this situation already in the past. When I was adopting Scrum in a local company, I was faced with the tyranny of setting targets. Targets and bonuses were part of that company's HR policies. "This is how we motivate people" as the saying goes.

Now picture this. When we started adopting Scrum we were, as expected, adopting also timeboxed software development (a key part of scrum). But the targets were that we should always be on time (+-10%).

So, get this: you get more money if you are on time (to motivate you to be on time, I guess) but your process is timeboxed! Easy money as they say...

The morale in this story is that targets are useless! If you want to improve the system (R&D for example) you need to manage the system, not set targets!

By adopting Scrum (effectively changing the system) we were able to be 100% on time! And that had nothing to do with the target setting, the system design (using Scrum) was the reason!

This is an insight that many managers don't have today: as manager you must design and manage the system. Setting arbitrary targets and not providing a method (system) is useless!

The video below of a conversation with John Seddon, is a very good explanation of how targets are useless and even counter productive. I especially loved his points:
1. there's no reliable method for setting a target
2. when you use targets or any other arbitrary measure you drive waste into your system
3. once you learn how to use measures derived from the work, and you involve the people who do the work you achieve a level of performance you would never have set as a target.