Category Archives: agile

Predictability Doesn’t Involve Predictions

When I say the word “predictability,” I think people assume that I expect them to be able to predict what they’re going to be doing 3-6 months from now.  They think I’m asking them to make predictions based on estimates.


In reality, I’m asking them to behave predictably so we can have some empirical evidence to combine with estimates as a way of making forecasts.  There are a couple things that are required for teams to behave predictably.

  1. There needs to be a backlog of work that is broken down into small chunks.
  2. The team needs to complete the small chunks of work in a disciplined manner, limiting the work in process and producing working, tested code on a regular, frequent cadence.

Breaking work down into small chunks is a skill that is developed with practice.  It’s not easy to begin with and many people get frustrated to the point that they say it can’t be done.  My experience has shown that there is no work that can’t be decomposed without some effort.  Sometimes that effort even involves doing a little piece of the work, especially if it’s a type of work we haven’t done before, but once the means to the end is roughly understood, the work can be decomposed.

If the work is relatively large (the definition of “relatively” varies by domain and level of experience), we don’t need to decompose all the work to the finest level.  We need to break all the work down into intermediate chunks and then we need to continuously decompose the intermediate chunks so we maintain a rolling backlog of finely-decomposed work.

Even the method of estimating I prefer doesn’t call for predictions.  I prefer relative sizing over time-based estimates.  The only “prediction” I’m asking for is how much larger or smaller one piece of work is over another piece of work.  I don’t want you to predict how long it’s going to take to do each piece of work.

I’m really trying to give teams a large degree of control over how they will accomplish an objective, but I’m asking them to be transparent about the backlog of work items required.  I’m also asking them to give me an idea of the size of the items so I can make continuous forecast adjustments of my own based on the pace at which they are progressing through the backlog.


Interesting Aside

It’s interesting to watch the evolution of work decomposition and estimating in a stable team.  When a team works together over a period of time, they unconsciously develop an idea of the preferred size of a work item.  This is the size that a work item needs to be before team members feel comfortable that they have a clear understanding of it.  As teams develop this norm, the size of all their work items in the near-term backlog converges on this size.

Phrases that Raise My Eyebrows

There are certain phrases that I hear in the course of product development conversations that cause me to raise my eyebrows.  Frankly, some of them are like fingernails on a chalkboard (for those of you old enough to remember chalk boards) to me.  Some of these phrases are so ingrained in our corporate lingo that most people don’t realize they’re using them.  They are uttered by everyone from software engineers to product managers.

Here are a couple I’ve heard recently.  I’ll update this post or write more posts as more of them hit my ears.

  • “I could work on task xyz.”  The objective is never to work on something.  The objective is to get something done.  If you start something, have an idea for how you’re going to get it to done, not just work on it.
  • “I’ll be ready to push that to QA tomorrow.”  There are two things that bug me about this one:
    1. In our software development teams, nothing gets pushed to QA.  It gets to a state that it is ready to be tested.  Getting it from that state to done is a team responsibility, not a QA responsibility.  Ideally, a QA analyst or test engineer will be available to test it, but if not, the team needs to figure out how they’re going to get it to done.
    2. We want our development process to operate as a “pull” system.  When a work product is done being transformed from one state to another, it enters a buffer queue (e.g. the Resolved state in most teams’ scrum boards).  It doesn’t get pushed to QA.  The work product only gets pulled from the buffer queue when the team has capacity to perform the next transformation on it (e.g. testing).
  • “We need to move this forward.”  This is stated by someone who wants to demonstrate progress on something to a stakeholder.  It seems rather innocent, but like the first item in the list, our objective should never be to start something or do some work on something, it should be to finish the most important thing we have.  The problem with moving things forward is that it is usually at the expense of getting something else done.  Too many things are worked on at once; they all move forward, but the most important of them never actually gets done.  This means we don’t actually deliver any value.

Scaling Agility – Collaborative Scheduling

I spent today at the first day of a two-day course at DevJam titled Scaling Agility.  The main focus of today was working within teams and we started to get into working across teams in the last hour.

One of the exercises I could see using made scheduling tactile.  The prerequisites are a set of prioritized and sized backlog items (e.g. stories).  You also need to know the capacity of a time box.

Each backlog item is listed on a card that corresponds to its size.  These cards are then placed into time boxes.  The cards can’t overlap and no more cards can be placed in the box than there is capacity.

Another key aspect of this exercise is that it needs to be done collaboratively with a group of people who can represent the feasibility, value, and usability of each backlog item.

You can see an example we worked on in class below.  There is one large item, one medium item, and two small items in the first time box (left side of the left piece of paper).

Collaborative scheduling example.
Collaborative scheduling example.