Timeboxes are by definition the goal of trying to complete x amount of work in y amount of time. When time is up so are you. They have been applied to all sorts of industries and activities;
- Software Development
- Manufacturing
- Getting Ready for Bed
The goal is to create small enough tasks that the user is comfortably able to estimate and complete in that box of time. Can you code this in one day or in 1 week. If you take a look at this definition from Wikipedia you can see how some project styles keep timeboxes quite small – 1 to 2 weeks while others go on for 3 – 4 months.
Lesson #1: The total value of what you accomplish in a Timebox is variable and differs by size and scope of project.
So in essence, what I did on one project for a Timebox I cannot apply to another project (necessarily) and I need to apply some “insight” to ensure that I’m not painting myself into a corner… or a box.
How do Timeboxes handle Scope Creep? They don’t, Scope Creep goes onto the backlog and it stays there until the next box. Nothing new here, if you were building a feature in Beta 1 and received some feedback from your trials, it automatically gets punted to Beta 2 (to be built in) and/or if your team judged if valuable enough, you could do it now and push some of other Priority One feature out.
Lesson #2: Timeboxes should not prevent creativity in Software Development.
Although a strict timebox can ensure you ship on time (conceivably) what about the gal who is coding this feature now and it makes sense to fix it now, rather than create an item for the next release? Why write code that is going to be overwritten in a release?
Alright, so I can be creative (still coming up with ideas whilst I code like a machine) and my timeboxes can be variable, but what about all that ongoing QA work of automation and performance? How does that fit into the box?
Lesson #3: Timeboxing should not include QA
There I said it. QA should not include Timeboxing (said it again). Why? Because QA should iterating over and over again, finding issues, running test cases in parallel, building up Edge Cases as Happy ones pass – in essence QA is a worm that should constantly be evolving, trying to stay ahead of the game. Not all Timeboxing includes QA, some do, some don’t – I don’t believe it should.
Any QA team will have a list of test cases they are going to run, the more you touch, the more they test, the more they run and the longer they take. You can run run as many tests in parallel as you want. At the end of the day, you’ll realize this to be true when you sit down with QA and you start running through the litany of tests that you want them to run – “oh yeah can you run this suite too, I might have touched something there, and you can write some tests for these paths, I’d be interested in knowing how it performs, etc, etc, etc”.
Time well spent, that cannot always be boxed, but should be correctly estimated.
You probably have very different views on Timeboxing and that’s great and that is the point – there is no one size fits all methodology that works for everyone on every project, take aspects of the best methodologies that you have worked on, merge them together and make something that fits your organization – “WaterFallingDownAnAgilePathToNimbleness” – if it works, go with it.
Welcome to the gray zone.
