Why Timeboxing Sucks For Your New Agile Teams
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.
Comments (3)
Jeevan Mathew
try 3 weeks sprint?!
That’s just it Jeevan, that won’t solve the problem. It’s not the length of time, it’s the frame of mind and knowledge of how to breakdown stories. It could be that teams aren’t truly cross-functional and have a ton of dependencies. It could be they aren’t formed as a dedicated team.
I tend to say that if you can’t do 2 weeks, let’s try 1 week so we can learn how to properly break down features.
Thoughts?
David Adams
Much of the challenge in setting a time-box for the Sprint flows from the historical behavior among teams to start initiatives “in the database” and “building frameworks”. It is a practice that I call “Building from Inside-Out”. The main drawback of this pattern (outside of the difficulty it introduces with work breakdown) is that there is rarely valuable feedback loops from business users at some indeterminate point in the future. Inevitably, a myriad of decisions have already been made in that vacuum that leads to overruns and wasted time.
A better option is often to “Building from Outside-In” with more focus on the relationships, how you will display them, and how users will interact with them. Requirements are uncovered and clarified by real connections and conversations between the Dev team and users. Applications take shape on the visible surface and begin taking root back into the underlying frameworks that now represent identified / known internal requirements to satisfy what the users have already approved.