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

Why Timeboxing Sucks For Your New Agile Teams

DZone's Guide to

Why Timeboxing Sucks For Your New Agile Teams

Time boxing gets a bad rap. Learn how to fix issues with time boxing by having your agile teams work in new, different ways.

· 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.

Ever heard these from teams before regarding timeboxing?

  • “What we do won’t fit into a 2 week window”
  • “The nature of our work is too creative for a timebox”
  • <<<Fill in your variation here>>>

If you work with agile teams, some variation of these statements will be familiar. I consistently hear new teams say this over and over when I form new sets of teams.

Here’s the deal, the problem is not the time box. In fact, the time box is exposing problems you need to solve!

Let’s check out some examples of the team’s timeboxing complaints above.

“What We Do Won’t Fit Into a 2 Week Window”

An example team that could have this problem is a one that is siloed by discipline. I am currently working with a set of agile data teams that fit this mold. The team members are very much specialists.

They have:

  • Data Architecture via Modeling and Data Flows
  • ETL
  • Data Analysis
  • Coding in Scala and Java
  • Data Analytics
  • Data Warehousing
  • Stored Procedures
  • Testing and Automation
  • Reporting
  • Deployment
  • And probably a few more things that I don’t even know about

In total these capabilities make up  a cross-functional team. Inside that team they typically do these tasks in sequence waiting for each other to finish. It’s no wonder they can’t fit anything into a sprint!

To Fix This

This team is finding ways to work in parallel. This feels a lot like design by contract for each of these sequential items.

To Make This Even Faster

The team will generalize a bit more to swarm around work that can’t be broken into the design by contract method.

Swarming will require team members learn how to maintain their specialty while learning how to help out with another capability needed by the team. That doesn’t mean be a specialist in both, keep your sanity. So, “If I know ETL, can I learn to help with Data Analysis or Stored Procedures?”

Let’s take a look at another common one.

“The Nature of Our Work Is Too Creative for the Time Box”

Regarding creatives… there is a large belief that most every discipline in product development is creative by that discipline.

We all see ourselves that way. There is a natural tendency to want to go somewhere, be creative, and come back with our creation. However, the importance of feedback is never more apparent than in truly creative environments.

Let’s consider a company creating it’s brand identity. The brand is going to have a significant impact on how customers pick and choose the company or a competitor. Even in this environment, we don’t want to have a team go away and comeback with some gold-plated logo that misses the mark after 3 months.

To Fix This

Instead we want to see steady progress toward success. By keeping the actual creative property transparent while collaborating around it, we can maintain visibility of the value that is being created and decide when enough is good enough.

Getting Small

Multiple creatives will be taken into the timebox because no one likes to commit to one thing and have it miss after two weeks. That’s too much risk, so they break it down into smaller deliverables. This benefits the “creative” and the customer.

To Wrap Up

Timeboxing is not the problem. Timeboxing exposes problems and encourages innovation to find new solutions. From our sprints to daily commitments and on to release planning you will find timeboxes everywhere in agile systems. If you use something like the pomodoro technique, it’s in most every part of your day. This is a critical part for teams to realize as a benefit, not a problem.

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:
agile ,team collaboration ,time management

Published at DZone with permission of Mike Cottmeyer, DZone MVB. 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 }}