Tips For Working Without Timeboxes

My previous piece on timeboxes led to a fair amount of dialogue on Twitter.  Some of it was positive and some of it was critical.  However, a particular tweet (that led to some back and forth) stood out to me.

In the absence of “real deadlines”, do we need to timeboxes to rein in our development teams?

As promised in the previous post, I’d like to share some approaches that teams I have been on have used to reduce their dependency on timeboxes.  I do want to be very clear that I have also used these techniques in conjunction with timeboxes.

Ruthlessly Delivering Small Increments Of  Value

Regardless of whether you use stories or not (all our work does not have to be represented as stories), I will encourage you to decompose your work into small bites of customer value.   The INVEST method (associated with user stories) is a good guide to use. Each ‘increment of value” should take a few days to complete. 

There is a common misconception that I often encounter which suggests that the bites of value a team works on should be exactly what will be “released” to the customer.  I believe this to be a grave mistake.  Let me illustrate with a common example.

Imagine a team is developing an API that supports GET, PUT and POST as methods.  Let’s also imagine that the team decided the API will not be made available to customers until all three methods are implemented.  Should this be treated as one bite of value or three bites of value?  Most technology folk I know will argue that it should be one bite of value because it will not be released until all the methods are supported.  I probably would have argued for this earlier in my career as well.  Well now I beg to differ.

It is clear (at least to me) that there are least three units of value available with this API and while it is true that all three methods need to be implemented before the API is made available, each method can independently be developed and validated for proper function. If each method was treated as its own “story”, we’d find that each story meets INVEST criteria.

But what difference does it make?  After all, nothing will be released until all three methods have been implemented.  That is fair point.  And yet I’m compelled to ask the following questions:

  • Why would we delay (internal) feedback on the first method just because the second and third methods haven’t been implemented?
  • Why would we couple the the release of value with deployment?
  • What if it so happens that we learn that we can release the API progressively?
  • Why would be knowingly limit the options of how we approach the work?

As I learned many years ago, “bite small, chew fast”.  There are many tips on how to split/slice stories.  Google is our friend.

Limit Work-In-Progress

Timeboxing, done right, helps us to be extremely selective about what we want to accomplish in a given timeframe.  We take the time to understand the capacity available to us and then select the most appropriate work that we think we can get done in that time period.

The good news is that we shouldn’t require a time constraint to explicitly limit our work in progress.  It’s a proven fact that the more work we have going on concurrently, the less we actually get done.  Unfortunately many organizations don’t pay attention to how much they have going on and instead attempt to ensure that they are operating near 100% utilization which invariably slows things down and ensure.  Teams are primarily rewarded for how busy they look.  I see many Product Owners struggle with limiting work in progress.

A word to the wise about limiting work in progress. If we don’t limit the size of the unit of value as well, we’ll still be working on items for an extended period of time with little to show for it.

Quantifying Desired Product Qualities

I am a fan of the work of Tom Gilb, EVO and Planguage.  If you’re not familiar with any of these, you should probably look them up (and also watch this talk by Tom).  I believe that there are ideas from Tom’s work that can be of help to those of us in the business of developing software products..

For example, when we say that our API should be fast, what do we mean by fast?  Or when we say that the website should handle a lot of users, what do we mean by a lot?  These are qualities that our solution is supposed to have that are often simply described in qualitative terms.  Qualitative attributes leave up to the imagination of whoever is responsible for ensuring that product has the desired quality.  In the absence of explicit quality attributes, teams succumb to pitfall of gold plating.

Specifying in quantitative terms what “goodness” will look like is critical if we want to stay focused and avoid going down rabbit holes.  One could argue that this is the Specific (S) and Measurable (M) from SMART Goals applied to our work items.

In summary, while I’m still a fan of using time boxes, there are ways of working that can reduce the dependency of a team on explicit timeboxes.  Regardless of whether you use timeboxes or not, you will still benefit from adopting these techniques as you do your work.

Advertisements

About Ebenezer

culture hack. contrarian. change artiste. speaker. writer. silo-connector. entrepreneur. totally human. ff at your own risk. :-)
This entry was posted in Software Development and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s