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.
- Data Architecture via Modeling and Data Flows
- Data Analysis
- Coding in Scala and Java
- Data Analytics
- Data Warehousing
- Stored Procedures
- Testing and Automation
- 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.
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.