when relevant content is
added and updated.
I have spent a large part of my career in software working either at established companies on new projects that haven’t made their first customer yet, or early stage startups. They usually have a fun, carefree feel. We spend time exploring the latest technologies and implementing those with the latest in development techniques. The schedules are lax, if there are schedules at all. It is easy to fall into that sort of groove when you don’t have any customers yet.
But, oh how things change when that first big customer signs on. Sales makes deals with customers for things that don’e exist, and then then the crunch starts.
The typical response I have seen is people (metaphorically) setting their hair on fire and running through the streets. The development team has mandatory overtime and weekend shifts. Sprints become commitments instead of a pull system, meaning that the product team rattles off a list of things that have to get done and then says “get it done.”
This is myopic in so many ways. Management sends a message that this is temporary. We will only have to work like this, under these deadlines and conditions, until this customer is in productions. Let me blow your mind real quick, Software development is driven by sales. There will always be another big deadline and another huge customer. If there isn’t, you probably don’t have much paycheck security.
The places I have actually enjoyed working at aim for sustainability. Rather than how can we meet this deadline, they ask how can we work efficiently and develop the skill we need to not put our employees in a bad position. Start with the low hanging fruit.
Deadlines usually put us into a feature factory state. We have a list of things the customer needs, and we churn through that list one by one till we are done. But, most people aren’t spending even half of their day doing feature work for a number of reasons — meetings to clarify bad requirements, figuring out how to work with parts of the code base that can only be described as an abomination, taking 2 hour lunches every day that include oil changes and hair cuts. The lowest of the fruit is getting your development staff working 8 hour days. Make lunches reasonable, get them in to the office on time, and cut down on meetings to fix things that weren’t done right the first time.
The harder part, and the more important one is constantly assessing and adjusting your process. Hack away at the chaff so that people can work quickly. Shortening the feedback loop has been the most important part of this in my experience. Most companies I work with have a start and stop flow. Developers develop, and then testers test, and this goes back and forth over a period of days. They are living on the illusion of speed, like taking a back road with lots of stop signs because you don’t want to sit in traffic on the freeway for a few minutes.
Pairing and automation feel slow in the moment. Rather than writing writing writing and then delivering, we write a test and then stumble, and then write code and then find a bug. The entire process is thought intensive, but it never stops. Shortening a feedback loop by testing in pace with development trades the illusion of speed now, for overall speed. There is less retracing steps, and less finding new things to fix in the future (aka failure demand).
Crunch time is completely avoidable, but it takes constant effort. This about what you are doing today? How can you improve your skill level just a little bit? How can you make your process slightly more efficient? Crunch time is a lot less crunchy when you keep that attitude over long periods of time.