Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Timebox != Commitment

DZone's Guide to

Timebox != Commitment

· Agile Zone
Free Resource

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

Procrastinating this evening, I got lost in a long stream of tweets about timeboxing, fascinated at how much disdain was aimed at a simple unit of time, and how it was blamed for sloppy workmanship, poor quality, panic and many other dysfunctional behaviors.

Having already given up on doing anything I needed to do tonight, I jumped into the stream to challenge this point of view. After a few back and forths I realized the disdain arose not from anything a timebox actually is, but what people confuse it with.

It seems there is an understanding of a timebox that goes something like this.

  1. Set a timebox size
  2. Commit to a bunch of work
  3. Realize you are failing to complete it all
  4. Rush to finish
  5. Produce crappy work
  6. Be exhausted
  7. Go to #2—repeat until dead, or company goes out of business

The only part of this that has anything to do with timeboxing is #1. The rest is about making promises you can’t keep, and doing it again and again. Timebox antagonists call this commitment.

Here’s my understanding of timeboxing.

  1. Set a timebox size
  2. Engage in dialog with requester/s. Review requests, prioritize
  3. Select a request, small enough to fit inside the timebox
  4. Complete the work to the satisfaction of the requester
  5. Breathe [reassess remaining requests if necessary]
  6. Go to #3—until there is no request that can fit in the remaining time.
  7. Stop work [if time remaining, take Slack time]
  8. Reflect. Learn from mistakes, and adapt accordingly
  9. Go to #2—repeat until all requests met, or deadline arrived at.

Hard to really get the essence of this in pseudocode, but I think it’s reasonably clear. There is still commitment in this description, but it is a reasonable, wise commitment. The work committed to is independent of the timebox length. The timebox is there to create rhythm, and to create space. It is a heartbeat. That’s all.

Life abounds with natural rhythm, finding our own work rhythm and honoring it is a beautiful thing. It requires release though, an alignment with life. 

If you are using a timebox to force commitment in order to meet externally imposed goals, and you are not changing your behavior when this becomes apparent. Go ahead, blame the timebox. It’s easier than looking to thyself.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

Published at DZone with permission of Tobias Mayer. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}