Work expands to fill all time available for its completion
I’ve been thinking lately about time and deadlines. Do any of these sound familiar?
- You go to a meeting scheduled for an hour. A project decision is made in the first fifteen minutes, and the next forty-five minutes are spent discussing and re-hashing that decision…only to then settle on the original decision.
- Your software team works in two week sprints yet seems to scramble in the last several days of each sprint to finish the bulk of the work.
- In a project with a deadline months away, the requested feature list continues to change and grow while the deadline remains the same.
These examples are all instances of Parkinson’s Law: “work expands so as to fill the time available for its completion.”
I think these are the perils of project work when we allow too much time. Even in Agile software development environments, it’s very tempting to dream up large products with long timelines and then want to know exactly what is getting built and when it will be completed. With big feature requests, old habits die hard. It’s easy to slip back into Waterfall software development delusions such as:
- That business stakeholders know and can articulate exactly what they want at the beginning of a project
- That the software team understands everything described about that large product and can know ahead of time how they will build it
- That a team can accurately estimate how long it will take to build that large feature
- That nothing that was planned will change for the duration of the project
- That the product delivered at the deadline will be exactly what everybody involved in the project expects.
Lean Startup and Agile software development practices were supposed to solve these problems! Large products come with a large timeline, which is often longer than desired or expected. Shouldn’t we build an MVP (minimum viable product) to ship a product quickly, learn from our customers, and iterate rapidly on that product? Paul Graham talked about getting a crude “version 1” out the door and iterating rapidly in his “Six Principles for Making New Things” years before The Lean Startup popularized it. (Funny aside: “Six Principles for Making New Things” has been one of the most helpful things I’ve ever read on a bathroom wall.)
Cut time to reduce project expansion
Have your Agile projects become more like Waterfall projects? Do people want to define exactly what is getting built before the project launches, and your product delivery is estimated to be many months away? Try getting things done faster by cutting time.
- Reduce your sprint length. One of my software developers wisely suggested reducing our sprints to 1 week on an important project whose initial long timeline made people uneasy. It’s working really well! The team is more focused. Collaboration improves. Blockers get resolved faster. Everybody realizes that there is not time to spare because they know they only have days to build the next iteration of our product.
- Cut meeting length, frequency, and number of attendees. Software builders and other thought workers benefit from long stretches of time where they can focus and enter a state of flow (getting “in the zone” where they are hyper-productive and focused). Having excessive meetings throughout the day cuts a large block of potentially productive time into a bunch of smaller chunks of time between meetings. Rather than schedule a half-hour meeting, can something be decided in 5 minutes of discussion? Is an hour-long meeting with 8 people necessary, or could the objective be met in 30 minutes with 3 people if everyone knew the intention of the meeting in advance and were prepared before attending the meeting?
- Be able to release a product iteration at the end of each sprint. This applies to software developers and product owners. Collaborate to determine what useful product iteration could be released at the end of a sprint. If the answer is “we can’t release anything,” then drill into why. Are you trying to build the perfect product for Iteration 1? Could you build something simple and iterate multiple times before it make it available to your entire customer base? Aggressively question the belief that nothing of value can be produced in a single sprint. If you absolutely cannot complete work in one sprint to release a product iteration, make use of feature toggles to deploy the code anyway without affecting the product shown to end-users until it’s complete.
- State a product goal for each sprint. Keep it visible and top-of-mind throughout the sprint. When your software team and product owner can both articulate what new features will be available at the end of the sprint, it becomes more real. If there is no clarity to a sprint’s work or it’s a cobbled-together list of unrelated features, that speaks to a lack of focus on the product or understanding of how to iterate to build a finished product.
Reducing time lets you get more done
Get more done by reducing the amount of time allowed to do something. Ok, technically, you won’t get more done. However, you’ll get more of the most important things done. Consider this perspective when a business stakeholder demands a feature in only a few weeks that “should” take months. Software folks sometimes balk at how unreasonable it is to build “Feature X” in weeks or assume that business people just don’t understand how long it takes to build software. But, what if that demanding business leader does understand how long it takes to build large features? What if they’re setting an aggressive deadline to drive focus from everyone involved in building the product: from business stakeholders to designers to product owners and software engineers. You can use this same “cutting time” strategy at your team level to drive focus and finish faster as well. When you don’t have time to do the least important things, you’ll reassess whether they need done at all.