During my twelve years as a developer I have gone through more crunch times than I can remember. Those that I remember, I have good memories from; late night pizzas, bonding with team members, solving big and small problems (and creating others at the same time), high fives and laughs. These memories comes at the cost of occasional all nighters, long weeks, longer weekends, months of every sprint having a hard deadline, etc. I don’t dare to say I have seen it all, but this all adds up and these times have taught me a few lessons. I want to share what I’ve learned about the good parts of crunch time, while avoiding its debatable effect on productivity.
Crunching on version 1.0 and version 5.6 is not the same.
In my experience, crunching is probably most effective when you have an early stage green field project. Then most of those late nights are spent hammering code at the keyboard. These are the happy times of crunching, the times that we remember. But be careful, that prototype your team created for a client demo, if the client likes it, chances are it will end up as a product and you have to maintain it.
As your codebase gets older and your project slowly shift towards some big ball of mud state (possibly because of some decisions you made during crunch time), crunch time changes. Now most of your time is spent trying not to break things, debugging obscure issues, making changes you normally would not do, all while being forced to use some library/framework you know is not the best fit and have been meaning to replace but never seem to find the time.
What are the good parts?
During crunch time good and bad things happen. Down the road, these actions will make or break your team and product. In my experience teams work differently during crunch time than during their regular sprints. Comparing these different work systems (for the lack of a better word) can give us some ideas on how we can improve our daily work. For some teams I have been on, it did not make that big of a difference. Crunch mode simply meant more hours at the office. For other teams, the work system changed dramatically.
Be biased towards action
When faced with an architectural challenge during a two week sprint, it’s easy for a developer to delay making a decision, go to a stand up and say that the team needs more time and we need to plan this into the next sprint. In most cases that’s an acceptable approach. This is more likely to happen in bigger organizations that have some sort of developer hierarchy and decision making move up the ladder.
During crunch time that decision is made on the spot. You ask your colleagues for input, you debate back and forth until you reach a decision the team is comfortable with and then move forward. This is mostly a cultural thing. Encourage your developers to make decisions, do some research, talk to other developers and then go ahead with the implementation and own it.
Clear goals
When crunching the list of work to be done is finite, clear and shared with everyone. The finish line is well defined, you finish your work and release. This clear and mutual understanding helps with productivity and morale. During regular sprints, depending on teams, the goal of a sprint can be vague and the deadline (end of the sprint) is soft. It can be helpful to have goal oriented sprints and also have some long term goals for the teams.
Autonomy
Sometimes crunch time brings to together multiple teams that now need to work closer together than ever before. Now there is no time to debate who should do what and how, things simply get done and worked on together, developers and DevOps sit together fixing deployment issues, testers and business people discuss requirements, etc. Instead of multiple teams, we have a single team where alignment is done face to face.
Too often teams are split up by roles (although this is changing fast) or are dependent on some knowledge/expertise that is not a part of the team. This often means cross team issues with alignment and responsibilities. We should instead focus on creating autonomous teams which are fully responsible.
(Over) Communicate
This is key. During crunch, when faced with a problem you seek help, because you know it needs to be fixed before tomorrow. You often end up pairing on difficult problems and there is a constant communication between all team members; what features are done, what failed testing, etc. This could and should be a part of the everyday culture of your team. One example of this, is instead of enforcing so called quiet hours, always assume others are available at all times to help you. If they’re busy, they simply say no.
Conclusion
I’m not a fan of crunch time, but it is widely used in the software industry. Most often there are some good reasons why teams are pushed to deliver. In my opinion and experience, this is often a big part of a companies DNA that is hard for us developers to change. One thing we can do, is identify the positive parts of the crunch time work system and incorporate into our regular sprints.
Photo credit: Grímsá, Iceland. Own photo.