Significance of Time Boxing
Fundamentally, it’s designed to establish a sense of urgency and to coerce the team to focus their efforts on getting something done. This is based on one of the Agile Manifesto principles that suggests the best way to show progress is to produce demonstrable working product, not documentation - Wow, what a concept! That’s not to say you don’t need documentation. In many cases this is required for ISO, FDA and other standards, but documentation is just one of the artifacts that needs to get produced during the course of the sprint – it’s not the bee-all and end-all.
Traditionally developers left to their own devices do things the waterfall way – this has been in-grained over years and years of training them to do it this way. So emphasis on precision, accuracy and detail were the order of the day. This led more often than not into analysis paralysis, and large amounts of extra effort into designing for goliath when you’re only intending to ship david. Through waterfall, you were only given one shot to get it right so we forced product managers to think of ABSOLUTELY everything. And of course developers therefore had to design for ABSOLUTELY everything.
The theme behind time boxing is the concept behind Just in Time manufacturing and emergent thinking and dare I say this “Good Enough”!. You plan and design for what is most important at that time. Nothing more, nothing less. And the architecture and product grows, emerges, and is refactored to deal with new requirements as they pop to the top.
This is not an impossible feat, it’s been done many times over and over. If I told you that we built our software and tracked our own software development using our own product since the 3rd week in development would you believe me? This is absolutely fact. There was no such thing as losing data for us. Rather the schema and the data and the architecture grew as the requirements grew. And everything emerged systematically as the scope increased over time. This is pretty much unheard of in our industry. And until such time as your Product Owner says it’s good enough, you continue to expect change and evolve the product over time.
This is a huge change in mindset and it takes hard work and good engineering practices to do it this way. So for example if you don’t have an automated test harness, and you don’t have significant unit test coverage (we have 100% unit test coverage), you’re not going to be able to work this way.
While on my Scrum training with Ken Schwaber (highly recommended by the way) one of the team members at my table asked how we managed to keep our developers productive when there’s so much testing that takes place prior to the end of each sprint. Well believe it or not, there’s lots and lots of stuff that developers have to work on besides getting to code complete (what this means is a subject for another blog) and throwing it over the fence to QA to test. To name just a few of these tasks, automated test scripts, integration test scripts, design docs, coding standards, unit tests, integration test scripts, production deployment scripts, performance monitoring scripts. To build well engineered products there’s no shortage of work to get done.
Although I am not that hung up on the length of some of these meetings (in particular the Sprint Planning meetings, especially if it’s your first sprint planning meeting and the first time this team is working together) I still think that they represent good guidelines and should be adhered to if at all possible.
If during the time boxed sprint planning meeting, you’re not able to complete the task breakdown, don’t sweat. Let the tasks emerge overtime. During the Sprint, as things evolve and knowledge is gained, new tasks can be added by the team to the backlog. People, especially engineers are intelligent human beings and left to self manage especially in a team setting, will figure it out believe it or not! So don’t be scared to dive in and get your feet wet even when you don’t know the full picture. Use the time boxes to get you going. Just make sure you don’t leave the engineering practices behind.
Written by: Jack Milunksy - COO at Brightspark and Co-founder of Agilebuddy (An Agile project management tool, built with rich collaboration features for Scrum teams). For more from Jack please visit: www.twitter.com/agilebuddy and blog.agilebuddy.com
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)