Now about this thing called estimation

Is estimation generally a worthwhile endeavor?  I really used think so.  I actually promoted multiple levels of estimation in an effort narrow the “cone of uncertainty”.  I’m not sure I’m proud of that.  However, for about a year now, I’ve begun to question the legitimate reasons for doing significant estimation (at any level).  I feel that the need for the activity is far and few in between (for example having to deliver something by a hard date or the business will collapse) and the activity of estimation should be minimal, opportunistic and spread throughout the development process.  It also seems to me that estimates should not drive business priorities because estimates are generally very unreliable, but for some reason it generally seems to be the most important factor at times.   Estimation (in my opinion) is an attempt to treat symptoms presented by software delivery challenges. Here are just a few reasons why I think estimation is largely a waste and is ineffective in many instances.

  1. Estimates focus on the amount of effort that will be expended to complete a work item.  It is usually a single number and it is usually wrong.  Ranges are better, but unfortunately can cause even more confusion (the wider they are).
  2. Except you are developing the same type of product in the exact type of way with the same people, your historical data estimates from previous projects is probably of very little use.  Even if you compare projects by “complexity”, you’d need to ensure that all conditions for the executing of the previous project will be the same for new project. Not.
  3. Even if you are developing the same type of product in the exact same manner with the exact same people, we are assuming that software development is deterministic, and unfortunately its not.  Things happen, sorry.
  4. If it just so happens, you’re the best estimator and use all the techniques we are aware and hence get an estimate range that is actual right, you still have the schedule (calendar) to figure.  For example, if you estimate an initiative will take 40 – 80 hours is that 1 – 2 weeks on the calender or 1 -2 months?  How do you account for holidays, sick time, emergency client issues, meetings etc etc?
  5. Let’s just suppose that you get both the estimate and the schedule right, now you have to explain to multiple stakeholders why a 80 hour initiative will take a month (and not two weeks).  You sure you really want to do that?

So how then do you plan for a release?  How do you commit to a plan?  I think these are the wrong questions driven by the wrong set of of goals.  If you are arbitrarily planning to stuff features into a time window based on a plan, you will most likely fail because your plan won’t execute as you want it.  I guarantee it. Ask yourself this: Has any of your software development delivery releases ever gone to plan i.e. the original plan?  I’ve been around software and software delivery (in some capacity) for  close to two decades and I have never seen a software development plan be completed as originally intended.  Things are either removed from the plan or resources are asked to give an “arm and a leg” in order to make the original plan.  So if we know that our plans are most going to change, why do we spend so much effort estimating and planning and then seeing the plans fail time and time again?  Albert Einstein defines insanity as “doing the same thing over and over again and expecting different results’.   Since our results are generally the same, why do we continue practicing them?  Our goals need to change.  Instead of focusing on “how much can be delivered”, we need to focus on “what has to be delivered for the organization to be successful”.  Based on this, I will offer up a set of steps for delivering the most value in a given release.

1. Determine what has to be delivered

The most important thing is identifying what features provide the business with competitive advantage.  Whether its keeping existing customers happy, automating time consuming manual processes or gaining additional market share, determining what needs to be in product by the time it is released for these goals to be met is key and of the utmost importance. At the beginning of a release cycle, work with your customers and its representatives (such as your product manager) to prioritize the list of requirements (or features or whatever you use at the highest level) designated for the release.

2. Divide and conquer

Split the development team in 1..N groups with all constituencies required for development present in each group and assign the highest ranking requirements to each group.  Limit work-in-progress (another upcoming blog posting).

3. Identify simplest solution that works

Instead of having the teams “estimate” effort, have them focus on working with the customer to determining the simplest solution that addresses the gap. Over-engineering is a malaise in the software development.  We love the grandiose and hence by default (and possibly unknowingly), tend to oscillate towards delivering the most expensive solution possible instead of providing the simplest solution that works.

4. Develop and deliver iteratively

Once the minimal solution has been identified, develop it iteratively with each iteration being meaningful i.e. each iteration delivers actual functionality that can be used by the end user.  Deliver solution once completed.  An interesting observation of this step is that based on how the teams are progressing concurrently, it will become apparent as to whether the entire backlog of business requirements can be completed by the end of the release.  You won’t need estimates to tell you this, trust me.

5. Start all over

Once an initiative is completed, start at step 1 again.

While I wouldn’t claim that this sequence is perfect for all situations and does not require tweaking to handle different scenarios, I believe it does provide a framework under which development organizations can execute in a lot of situations. It commits to delivering the most important items while leaving room for business priorities to be adjusted in an ever changing environment. Priorities are adjusted based on feedback from the development team and customers.  Hours are not spent estimating and planning for 12 months of development.  Ridiculous commitments that lead to unbearable working conditions are not made. Everyone ends up being happier for it and business goals are met.


How do you measure productivity

How do you measure your teams productivity?

The way you measure productivity directly impacts the improvement processes that are implemented.  Traditional management science focuses us on metrics such as worker utilization i.e. how hard are workers working and then subsequent improvement processes are geared toward keeping workers working as hard as is possible.  Companies reward people who put in tons of time and classify them as star employees. The fundamental problem with this approach (at least in knowledge work) is that it is dependent on individual productivity on the team being exactly the same. This is rarely (if ever) the case.  If I am on  team of 4 people, and we all put in a 40 hour week, because we don’t all generate the same output in 40 hours, it is most likely that some output is not being processed.  Now let’s assume that I’m the most productive individual on the team and I put in a 60 hour week but my teammates only put in 40 hours, my extra 20 hours becomes a larger problem because the deficit of work that needs to be processed is increased.  Everyone’s utilization (hence productivity) needs to increase significantly to balance out the system.  A teammate may need to work 80 hours just to catch up!  In an interesting way, my extra effort causes my teammates to become bottlenecks when it was supposed to increase our collective throughput. Sort of counterintuitive wouldn’t you say.  We see this a lot when developers deliver too much software for testing, such that the testers can’t keep up.  Operating at full capacity (or overloaded in the case of 60 and 80 hours) eventually causes the system to breakdown leading to unhappy people and systemic poor quality.

Maybe there is another starting point for measuring productivity.  Let’s see, how about if we measured how long it takes to deliver what we’ve promised in the form of cycle time?  By focusing on the product (and not the people) we (hopefully) begin to direct our efforts to shortening the cycle time by addressing those things that are impacting it in the first place.  We begin looking at the bottlenecks in our flow and try to address them.  Maybe we’re taking on too much work in the first place.  Maybe our estimates are completely unrealistic.  Maybe we are understaffed.  We identify better ways to actually get the most out of the team by (for example) developing in a set based manner or increasing feedback loops with our end users.  We end up with a more efficient and effective way of delivering value (and it just might be that people want to work harder out of their own volition).

This is part of what lean thinking is about.  It might be worth taking a look at.

How long are your iterations?

One of the predominant goals of the Agile movement is to have software development teams deliver software in regular yet meaningful increments.  Out of this the was born the idea of short time-boxes of development cycles with specific delivery goals at the end of them.  These time-boxes have been referred to as iterations, sprints etc etc depending on the methodology is in play.

One of the challenges I see with iterations is that management arbitrarily picks a length of time, say 3 weeks, as the length of the iteration and applies it unilaterally across all development initiatives that exist perpetuating the notion that all development initiatives need the exact same methods applied to them.  It could be very possible that one software change initiative works better with weekly iterations because new functionality can be delivered/demonstrated on a weekly basis while another initiative needs 6 week iterations for the exact same reasons.  Agile teams should strive to be self-organizing meaning minimal management interference. Teams (with coaching) need to understand their objectives and iterate in manner that makes them most efficient. Asking all the teams within a group to conform to a “standard” iteration cycle/schedule/calendar imposes constraints that actually gets in the way of getting things done (and getting them done quickly).

How so you might ask?  Well, a direct result of imposed iteration cycles on all development projects is that it causes teams to make up what I consider to be “soft goals” (or pseudo goals) such as “deliver design documents” in order to have something to show at the end of the iteration.  I’ve sat in meetings making up worse goals such as 10% of the use cases done by the end of the iteration  (what was I thinking?)  While there is nothing inherently wrong with delivering design documents at the end of an iteration,  in my opinion, it devalues the essence of time-boxed development which is delivering actual end user functionality.  What is of value to the end user is a working solution, hence the ability to show incremental progress towards the solution should be the driver for iteration sizes – this makes iterations the most meaningful.

Determining how quickly incremental functionality can be delivered should determine iteration lengths.  This proposed length of an iteration should further cause a retrospective on the proposed approach to development for that particular development initiative.  If the length seems too long, then the team should focus on methods that allow them to shorten development time while yet maintaining a high level of quality as creating short iteration cycles is addressing a symptom and not a problem.  Truth be told, there is a lot of “waste” in software development as many of the mandated processes/practices we consider value-adding do not provide actual value to the end user (at least not in the first delivery) e.g. end users don’t care about monstrous catalog of user stories, user cases, functional specifications that we keep and the value they provide to the development team is generally overstated but this is a topic worthy of its own post.

My recommendation is determine iterations schedules with the explicit goal of demonstrating customer functionality at the end of every iteration specific for each initiative.

Does Your Team Have An Agile Coach

A recent e-mail exchange with a former co-worker of mine reminded me of something I believe is critical to the success of agile teams and that is the presence of an “agile coach” on the team.  There needs to be at least one individual with the responsibility of coaching agile methods on the team.  This individual needs to be committed to increasing their knowledge of agile (and other) methods and promoting continuous improvement on the team otherwise the team will stagnate.

Does your team have an agile coach?  If it doesn’t, you need to give someone that responsibility.

Uche Okafor – RIP

For my generation, the golden era of Nigerian football (soccer here in North America) at the senior level was probably between 1990 – 1996 when the Super Eagles won the Nations Cup and lost in the Italy in the round of 16 at the World Cup, both in 1994.  Uche Okafor was member of the national team at that time so I am saddened to hear of his untimely death.

Rest in peace Uche.