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

Business Analysts and Agile Development

Glenn Gillen has a quickstart on how to get Agile Development done right.  It’s a pretty good read and something I’d recommend to those who are trying to get “agile” going in there development organizations.  However, there is one quote that I really can’t agree with.  In the section, “Customers don’t write the stories” he states:

And neither do business analysts, development managers, or project managers. I’d go so far to say that if you want to be “agile” and you’ve got a team of BAs then you should fire them all. Anybody getting between the developer(s) and the customer is stopping the developer from becoming the customer.

I couldn’t disagree more with such a generalized statement.  While I concede that there are situations where the “business analyst” as a position is overkill, there are many cases where it would be flat out silly to put the developer in front of the customer for a variety of reasons such as logistics.  There have been quite a few posts on the subject and performing a search on “business analyst agile” turns up quite a bit.  However, I’d refer everyone to a Scott Ambler essay as it provides perspective on this matter that is important.

What’s important to keep in focus is that “roles” are only as valuable as that they ensure that certain activities are undertaken.  These roles are really “hats” that should be worn during the software development lifecycle.  There are instances where one individual can wear all hats but as projects increase in size and scope, there comes a point where roles need to federated.  Business Analysts eventually become responsible for making sure that new requirements are aligned with the existing business and can become the mediator between the stakeholders (including the customer) and the development team.

Agile teams need to identify who on a team performs each activities and ensure that these activities are performed correctly.  In certain cases, this may call for distinct roles such as BAs and in other cases it may not.  Just don’t rule anything out before starting.