Time box: Get-Stuff-Done Tool for Risk Reduction, Focus, and Decision Making

This is part two of a three part series Time box: A Holistic View on Sprints and Iterations

Work expands so as to fill the time available for its completion. ~ Parkinson’s Law, Cyril Northcote Parkinson

On Risk Reduction

imageTeams talk some good game when they sell Agile to their organizational leaders: real software in a few weeks, higher quality, and, if they’re really good, risk reduction.  “See, if we build these features early,” they say, “and people don’t like it, we’ve saved you 13 months of wasted effort and costs.  How can you not love this stuff?”  Sign me up Johnny!

It’s true, if you build done software in 30 days or less, you do get the opportunity to inspect the output determining whether to stay the course or correct.  You can even begin taking on more creative, innovative, industry shaking adventures knowing they are limited to a few weeks or months.

Looking to become strategic and not just tactical with technology… this is your ticket.

But it’s not all roses. You must expect that some adventures will not end with a pot of real gold. Instead, our gold is measured in learning; new information which can be taken back and used to concoct the next ground shaking advance.  If you allow the fear of failure to drive your decisions you will grind to a halt.  Instead, create a system based on learning and encourage the free communication of that information as a value neutral asset.

On Focus

Tell me you didn’t see this coming.

Every team feels the pressure of a time box.  It’s natural and it can be used wisely.  It can also be abused.  Terribly, terribly abused.  I have good news though!  Corporate evolution is on the side of the wise.

Those who follow the Pomodoro Technique create short, focused 30 minute durations to accomplish activities.  25 minutes exist for actually working the task at hand and 5 are meant to provide the necessary, human break needed to maintain focus over extended periods.

Our Sprints must consciously reflect this same human capacity for focus in a creative environment like software development.  As outlined in our previous part of this series we can easily turn a space for focus and creativity into a pressure box of panic, frustration, and corner cutting.

Sausage stuffing is the two steps back to your previous step forward.

On Decision Making

imageTo support a team in delivering functioning, ship-quality software in 30 days or less, organizations must provide them with timely, informed decisions to questions and alternatives.  Authoritative and informed decisions which take into account the political and user environment are necessary within minutes and hours, not days or weeks.

Would you ever consider the impact of removing 10% of an existing project’s schedule?  In delaying a decision for steering committee or general approval by 1 day, a two week iteration is similarly delayed.  In the absence of responsive decision making and an open social environment for voicing questions and concerns, teams will make decisions and assumptions on their own.

In many of these cases, we may have the best people on the team to make those decisions!  Time boxes demand that our teams be composed of or have direct access to those skills necessary to make decisions quickly.  This includes domain experts such as lawyers, accountants, marketing, design, etc.  With “done” software in 30 days we cannot hide the impact of delayed decisions.

Time box: Safety zone for Creativity, Cleanliness, and Sausage Stuffing

Without freedom, one’s creativity cannot bloom. ~ Dalai Lama

On Creativity

In his 2005 A Survey of Organizational Creativity, Wayne Morris of New Zealand found that 2 of the top 3 Factors that facilitate or enhance organizational creativity are Time and Space/resources to pursue ideas.  imageGoogle stands as a preeminent topic brought up by software teams with it’s 20% time for engineers to follow passions.

Creativity, a necessary ingredient to innovation, demands space.  Space to experiment, learn, fail, and refine.  Space in time, environment, and pressure.


On Cleanliness

The mythic Rewrite.  It also comes in the form of a Refactoring Sprint.

Software Developers would hand over their first born in exchange for a Rewrite.  Customers hear: So we have to complete two more sprints before I can deliver new value that I can sell to pay these clowns’ salaries?

Keeping our code and our designs clean and in good state requires time and effort.  This isn’t in question.  Not even to your customers.  It most definitely needs to happen more often than once a year or however often it’s happening today.  Let’s face it, that big ball of mud didn’t happen last sprint.  It’s been simmering for some time now.

We must be delivering clean, refactored software in the midst of delivering new value.  We need to do this for many reasons, but here’s one you really need to accept or go learn the hard way: cash flow is a big deal.


On Sausage

I must credit Ken Schwaber for this analogy (and vision!).

There is a great unrest growing against the velocity metric.  In the minds and realities of many, velocity has been corrupt.  We are using this tool for calibration to fill a sprint to capacity and beyond.  To take a team to it’s limit.  To optimize!

We are stuffing the sausage.

I say ‘we’ and you’re reading ‘they’.  Admit it, I don’t blame you.  I do it to.  But we as team members are as much to blame.  When asked what we can accomplish we take that word ‘can’ to its limit in the hopes that we are pleasing others.  It’s pretty natural I’d say.

Unfortunately, in stuffing our sprints like sausages we squeeze (sorry) out the space for creativity and cleanliness that should otherwise be built into our ongoing process.  We must make space for the continuous improvement and balance our sense of urgency with our sense of exploration.


On Reality

Industries are not changed on Innovation Day or in Executive Offsite Meetings.  They are changed through discipline and a framework for learning applied to frequent delivery.

So choose a period of time which provides you an appropriate opportunity to inspect and react.  Build creative, clean, done features in that time.  Now use that experience to forecast which new parts of that product you can complete should you repeat that cycle in the future.

File:Claude Monet, Impression, soleil levant, 1872.jpg



Continue reading this Time box series here

Time box: A Holistic View on Sprints and Iterations

imageOver the last few years we’ve seen a growing discontent around the idea of Iterations or Sprints.  It excites me that the software community is actively engaged in questioning the long held canon of Agile practices.  Through these explorations we as an industry will find a greater depth of understanding.  Over time this can only have a positive impact on our community.

In reading many of the Iteration abandonment stories and views on why iterations are outdated I believe there is a rather one sided understanding of Iterations.  I believe this is a remnant of the software development industry’s state of being from which we came; the way referred to in the opening line of the Agile Manifesto.

We are uncovering better ways of developing

            ~ opening line of the Agile Manifesto

I have a confession to make: I think iterations are really, really useful.  I also think they are often bastardized.  I’d like to help fix that problem and, in so doing, bring some of you back to the iteration so you can be more creative and strategic and less, well, cogs in a wheel.

In a three part series of posts I will redefine the meek, abused iteration for you as a:

If you really, really want to love going to work, experiment with cool new technologies and techniques even in the most conservative organization, and want the best argument for ‘going Agile’ then stick with me.  By the time we’re done you will have a better understand of what a time box really is, where the time box applies, where it corrupts and, how to make a balanced decision for the duration of your next time box.

Definition of Done Discovery

One of the important aspects of Scrum and the more fundamental concept incremental delivery is building Done software each iteration.  There are a lot of holes in that statement, but that makes sense; Scrum is full of holes… on purpose.  If you want answers rather than a framework built for learning, Agile ain’t for you.

imageHaving a clear, well understood and explicit Definition of Done that everyone, including your product owner and surrounding teams accept is very important to growing quality and capabilities consciously.  Underlying any Definition of Done is the expectation that the useful (for another day) software is ready for consumption by those who asked for it.

As a new team, discovering your initial definition of done can be surprisingly challenging.  Certainly we can come up with things that we want to do and I say go for it!  Only inspection at regular intervals can tell us for sure where we are and what the impact has been.  But there are some things we can do to help make this decision more effectively.  And it doesn’t take long.  30 minutes… maybe.

Circles and Soup

Innovations Games has a fantastic activity with many applications called Circles and Soup (sometimes called The Soup).  I’ve used this to help a pissed off team focus their energy, but it’s also very helpful in creating an initial Definition of Done that is truly attainable.

You should read the full instructions, but suffice it to say the team will categorize those activities both historically done (i.e. architecture review) and potential (i.e. TDD) that must or should be accomplished to deliver into: Things They Control, Things They Influence, or The Soup (things they have no control or influence over).  This is immediately actionable information, but also a roadmap to move items into the teams control.  Share this with your organization and advocates.

A Definition of Done, something that they agree will always be completed before calling a feature or story or product backlog item done, which includes activities outside of the team’s control is risky or foolish.  You should control your own destiny as best as possible.  How can a team ever feel at all confident in their own forecasts otherwise.


In the Professional Scrum Developer course we talk about and spend a few minutes brainstorming attributes that define quality.  We call these ‘ilities’.  Things like maintainability, supportability, reliability, performance-ability.  Ok I made that last one up, but you get the idea.  It’s a big list too. 

Very few people will argue that missing an -ility negatively influences the quality of an application. Which –ilities are most important, though, depends on many factors.  Type of application, type of user, industry, etc.

What I like to do as a facilitator for this activity:

  1. Ask the team to break up in pairs or individuals for 5 minutes.  Write every attribute that affects your impression of any application you’ve ever used on a sticky. 
  2. Then come together, remove duplicates and put them on the wall for another 5 minutes (usually less).  This creates discussion about what people intended or experiences.  Often another -ility or two will be discovered.
  3. Use dot voting or some other form of ranking to figure out which –ilities are most important to this application.
Putting it together

You should now have a good idea of what the team has true ownership of and what is most important to build a great application for the intended customer.

With the results on either side of a whiteboard or giant sticky, choose a few activities which correlate the important –ilities and the activities in the team’s control to determine an actionable, checkbox-able list of things you feel will assure each feature and sprint produces Done software.

Each iteration you have the opportunity to review these artifacts or recreate them to evolve your Definition of Done from good to great.

Cone of Uncertainty Graphic with Events in Time

I’ve always received great feedback when describing the cone of uncertainty to groups on a whiteboard using events in time rather than simply an abstract timeline.  Today I put a graphic together that I can easily share or refer to.  Thought I’d post it for others as well.  Feel free to use it and let me know what you think. 

Disclaimer: All events are provided as examples which can and may occur as you work toward solving a problem.  I’m not advising you to include these explicitly in your process.