Posted by: jsonmez | July 10, 2011

Taking a Breather

In my last post I had talked about a possible drawback of Agile basically being that Agile projects tend to drive developers instead of steering them.

I basically summed the problem up as being one of software development on Agile projects being a really long set of continuous sprints on an already laid out path.

I have been thinking quite a bit about some possible solutions to this problem, and in this post I hope to provide some.

Racing the good race

One of the analogies of Agile projects is that of a race.  In Scrum we call the iteration a sprint. 

I think this analogy points clearly to the solution.

When I used to be on the track team in high school we would do sprints.  It was called interval training and it sucked.

Well, at first it didn’t.  At first you would do some of your runs, like a series of 100m dashes and feel great.  But, by the end of the session, if you ran it as hard as you could, your lungs would be burning and it wasn’t all that uncommon to puke up your guts.

People just aren’t meant to sprint over and over again without a break.  When we were pushed too hard on the track we would end up slowing down the entire time on the next training session in order to pace ourselves.

You have to find the right combination of sprints vs. rests.


Enter the cool down sprint

My most promising idea is: after a certain number of sprints the team slows down and basically takes a breather.

Not to say the team just sits around and doesn’t do anything.  Far from it.  Instead the team does what they think needs to be done and is important.

Kind of a self-reflection / sharpening the saw / building tools and making ourselves more efficient sprint.

I would guess it would be beneficial to do something like this every 5 or 6 sprints.

The idea here would be you just trust the team to work, but no one directs the team as to what that work is.

I think it is a good way to take some of the pressure off and reenergize the team to start the next set of intervals.

This next idea is stolen

I’m not sure exactly from where, but I heard of a team before that gave each member of the team some amount of “dollars” they could spend each iteration.

Product owners and managers were given “dollars” as well.  The idea was that you could spend your money on items that you wanted to put in the sprint.  The priorities were set based on where the dollars fell.

In order for something like this to work, you need to give far more dollars to product owner, support people and other people on the business side of the house, but by giving a certain amount of dollars to developers, you allow them to have some amount of say in what is worked on.

This kind of solution solves the problem by allowing developers to have more control over their destiny rather than feeling the path is laid out for them.  It gives them the ability to work on something they see valuable or even just fun without pressure or guilt because everyone understands the concept of spending their own money how they see fit.

Developer free time

This idea is stolen as well.  Actually it is stolen from Larry Silverman who is my current employer at

This idea is pretty simple; here is a quote from our dev wiki describing it:

You may be familiar with Google’s policy that each employee is granted 20% free time to pursue their own interests. Of the projects that result, some of the best become live Google products. Google has nearly infinite resources, and with thousands of developers trying so many things, every so often one of them is going to be a winner and create a major new revenue stream. Obviously, TrackAbout does not have infinite resources. But we admire the spirit of Google’s free time policy and would like to emulate it to the degree we can.

The following Developer Free Time policy is intended to promote creative thinking and innovation by providing developers an opportunity to explore new ideas and technologies. In the spirit of Continuous Improvement, you may choose to take this time to explore an idea or improve your own skill set. Of course, we hope that some of work might prove beneficial to TrackAbout.

Most importantly, the policy is intended to allow you, the developer, to stretch your proverbial legs and have some fun!

The Details

  • The program is voluntary, not mandatory. You don’t have to participate, but it’s encouraged.
  • Each developer is granted 2 days per quarter to pursue their interests/projects.
  • No approval is required for the project, but feel free to use Larry or other devs as a sounding board for ideas to pursue.
  • Developers can take the 2 days at any time during the quarter (when inspiration strikes!), provided it doesn’t place at risk a release under development.
  • Developers can team up on projects.
  • After completion, the developer (or team) will submit a brief write-up to the Dev Team summarizing the work they did and what was accomplished, explored or learned.
  • If the dev (or team) wants to present their work to the dev team or to the greater company, it’s encouraged but not required.

It’s about nurturing passion

After thinking about my last post for some time and what possible solutions to the problem I described, I realized it is all about nurturing passion.

Agile and Kanban like thinking tend to get us really focused on producing and producing.

Don’t get me wrong, I love to know that my team is operating efficiently and producing lots of value for the customer, but sometimes we need to really make efforts to balance that production with what really makes the developer engine run.

Sometimes we need to take a pit stop or do an oil change so we can keep that machine running smoothly and if we don’t, just like any machine, it will break down.

I realized that most people in our profession don’t get here because they love a paycheck, but because they really love writing code and exploring technology.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.


  1. I wrote about a similar thing a while back where the constant iterations and no break can become a bit relentless.

    In my blog post ( I outlined the concept of a firebreak where the business allowed developers time to “play” with technology that could be of use to the business.

  2. I really like the idea of a certain percentage of time that developers can use for whatever they see fit. The last team I worked on used one day a month, and it certainly payed back, both for the product and motivation. I especially liked the team building effect of all doing it on the same day. See for more details on what we did.

    Having said that, in my opinion this isn’t the first solution you should go for. In the best case, it’s a nice add-on, in the worst, it’s a band aid, masking the real process smells.

    To start with, a Sprint shouldn’t feel like a sprint. It should feel like a stage of a marathon. No, not even that, because you couldn’t run another marathon directly after the first. So I guess a stage of a hike would be more like it. And part of each stage should be checking and maintaining the equipment.

    Also, I don’t fully agree with the notion that Agile drives developers, in the sense that there is no freedom to do some of the steering. Yes, the PO (to use Scrum language) should have the final say on priorities. *And* the developers should be actively participating in the steering. They should be able to contribute ideas, for example during backlog grooming, and to get creative in how exactly stories are best implemented (the Negotiable in INVEST).

  3. These are some great ideas, John. They seem to be based on fundamental mechanisms and some very deep human philosophy, so it seems to me like they could have a huge impact. I had not thought about having a “free” iteration, and though I was aware of the 20% policy at Google I had not attempted a policy like you have at TrackAbout to this point.

    I am triggered to think first of isolating an experiment with these ideas between various projects we have going, but I also think just incorporating the philosophy of getting a break from continuous sprinting will go a long way.

    People do need time for their own creative energy, and they need a chance to recharge. Many developers I know spend time on the weekends writing code or reading up on some new technology… not related to their projects, and they are “relaxing” or recharging in their own way. That’s the way we keep moving forward.

    In the context of a project, getting to recharge within the context of the sprint cycle might also take some of the dread out of returning to an unsolved problem or tedious feature set, and could produce some new insights and energy for the developer and for the team.

    Thank you for laying out some creative ideas for us.

    Kind regards,

  4. I also ended up with a team that expressed the concern about the unending nature of sprints. They would get really upset about the relentless pace and point out how upcoming vacations, holidays, production support workloads, etc needed to be considered. And then they would proceed to commit themselves to more points than ever arguing with me why we should not reduce the pace. I think that the key phrase used on many agile sites is “sustainable pace”. So if people are saying that they can’t sustain the pace, then it must not be sustainable for some reason. My guess is the reasons are highly varied and some experimentation is required (inspect and adapt). We explored several options. One was to simply have a sprint every so often in which we committed to fewer points as suggested by others. The team was horrified by the idea because they had been priding themselves on increases in the pace. So, I suggested that we allow pointed “learning stories” in which anybody could identify something new to learn or try out. In that way, there was no reduction in points. We even had product owners buy-in as they understood why it was necessary to pay a little tuition along the way. However, the team tried it once or twice and then never tried again, quickly reverting back to old form. The reality of the situation is that the team is now in a slow decline in which the trend line for both planned and actual points is downward.

    Entropy happens unless new energy is introduced in to the system.

    • Rich,

      If you have the luxury of having multiple projects in different domains, you could also start mixing teams around between projects after a few cycles… not enough to lose too much institutional knowledge, but enough so that people learn from fresh people and those that roll off get to work in a new domain.

      Now, I think we can do that, in part, because we predicted some of the decline in advance and started our teams with the expectation that they might rotate around from time to time. In addition, I accept it is not as good an option if you only have one team, one project, or a single program domain to work within.

      In your agile project, use an agile resource model…


  5. […] Taking a Breather (John Sonmez) […]

Leave a Reply

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

You are commenting using your 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


%d bloggers like this: