We’re in Crunch Time at work. That means we’re working extra hours and we’re deal with all the stresses that attend trying to complete and ship a product. This is not one of my favorite times of year…
I only have real experience in the software industry, so I don’t really have much to compare with – I don’t know if manufacturing jobs have similar periods, I don’t know of anything like this for a teacher or a policeman, maybe this is similar to the crunch that tax preparers deal with yearly.
One of the maxims that I learned early that applies to software projects and most projects in general is this: Projects are dominated by three factors: Scope, Schedule and Resources. You can pick two of those and fix them or set them as unchangeable but you can’t fix all three. So, these three factors form the triangle of legs which hold up the stool which is my product release.
Early on in a Release you start talking about what it is you want to do with the next Release of the product. That becomes a Feature list which forms the Scope for the work to be completed. Often you spend time determining a rough sizing for the work to be completed as well as a rough priority for that work. Typically it’s the case that some of the work is a “must have” and some of it is “nice to have” and some of it is related to either maintaining or improving the quality of the existing product and may not be customer visible at all. That last one is one to keey your eye on because it appears to be easy to drop or reduce because it’s not customer visible, but if you do that you quickly accrue what is called in our industry “technical debt” and technical debt is more expensive to deal with or pay off the further you get from the work. Accrue too much technical debt and you can drown in it and kill your product or make it so expensive to support that you can’t easily innovate. Failure to innovate quickly means someone else will come along and take away your business.
Schedule is often either a function of a regular release cyle (“we release twice yearly”) or it coincides with when you want to put a new product in either your customers hands or your sales folks hands. Think about the release of a big game for your computer or XBox or PS3. The market for games is huge around the holidays and almost non-existent (comparatively) in January and February. So, for schedule, it’s critical to get that game out in, let’s say, mid-November so it’s on the shelf for all the folks buying for the holidays. Miss that schedule and you’ve probably halved or quartered the amount of money you make from that game which probably means the difference between financial success and failure which, in turn, may lead to layoffs or other unpleasantness.
Resource, in the most simple case, are the folks who will do the work, though sometimes it can also include physical resources like computers and other hardware.
So, you can set or fix Scope and Schedule by saying that we’ll do the following 10 Features by April 1st, but in that case you need to be open to bringing on more folks to help. That’s expensive, though, so often Resources are considered fixed for the most part.
Schedule, for all the reasons we talked about above, may be fixed because of business reasons. We need to get that release out by April 1st because if we don’t, our sales guys won’t have a product to sell and if they don’t have a product to sell, they’ll sell something else offered by the company and our group will suffer for the lack of those sales. Sales are what keep our group and our company in business and make sure that I get to keep my job because we, as a group, produce a lot more money for the company than what it costs to employ us. As a result, for lots of legitimate reasons Resources and Schedule are often considered pretty fixed. Having said that, schedules do slip and how organizations handle that is what differentiates a successful organization from one that will likely suffer. Frankly, how to deal with a schedule slip is an entirely separate conversation but suffice to say it’s a combination of hard work, compromise and weighing the needs of the company and customers to try and produce the best product you can as close to the committed date to still satisfy your customers.
The other leg on the stool, Scope, is where I best like to work when it comes to managing a product release while still working hard to reach dates with a given set of people.
I’m a big proponent of the Agile Methodology of software development (though it’s been noted that Agile can certainly be applied to most any goal setting and delivery task like writing a book or learning to play an instrument). I like that it requires regular reviews of progress and adjustments based on the reality of the situation. Prior to Agile, projects tended to use something called the Waterfall Methology which involved planning up front for a mythical ship date out in the future and then working towards that. Very little to no opportunity for adjustment once that process was launched. Agile addresses that shortcoming with the notion of fixed iterations of work (say, two to four weeks), regular review of progress and priorities and a prioritized Backlog of work to be completed.
That last item, the prioritized Backlog is an important and effective way to manage Scope. If you have rational Product Owners, you can have a conversation about those 10 Features we mentioned earlier and determine which are Must Haves and which are Nice To Haves. Couple that with a rough sizing and you can start to figure out what will fit and what won’t in the alotted timeframe and have conversations about how we get to done.
Back to Crunch Time. Even in a good, positive and well meaning organization, you can and will still have Crunch Time. Even though we all know that all estimates for what it will take to complete a chunk of work are bogus and even if management applies our bogosity multiplier to a given estimate, there are still surprises. Bugs take longer to fix. Or you have more bugs than you expected. Folks get sick and Real Life intrudes on the best of plans. It’s said (or paraphrased) that no plan survives contact with the enemy. The enemy in this case is reality. Plans are made with the best of intentions and with the best data available but they are inherently fictional and the degree to which they are fictional is only known in its entirety in retrospect. Agile can help with that, but at some point you still have a release you have to get out the door by a given date.
Crunch Time has always had an unfortunate effect on me, personally. Especially since I moved in to management and our ability to make that release date is part of my job and my responsibility. As things get close and we move in to this phase, I find that I’m not able to disconnect from the job and work the way I do during the rest of the year. I consider it a strength of mine that I can usually leave work at work and by the time I’m at home my brain has shifted gears appropriately for being at home. Crunch Time breaks that model. Technology, unfortunatley in some ways, exacerbates that. Smart Phones means I can check work email anywhere and anytime, even in the bathroom. That means I can respond at 7pm or 10pm. I can check email as soon as my eyes open at 6am and all it takes is something that requires my involvement and the brain engages in work mode and home mode is gone. And I need home mode. Home mode is when I hang out with my wife, do the things that are important to me and do things that are not work. It’s that work/life balance. If I don’t get enough of that, and I assume that’s true for everyone, then I start to suffer. And that suffering isn’t limited to just the work hours.
The net result of this is that Crunch Time wears in a way that is unique. I don’t have a good way to manage it. I don’t have to check email in the morning but I do because if I see an issue and get it unstuck or addressed then, it may save someone 3 hours later in the day. If I can respond to an email at 10pm, it may mean the folks we work with in other parts of the world are also not stuck. That doesn’t happen daily, by any means, but it still requires a shift in to work mode and that’s expensive for my brain. Context switching is always expensive and the context switch from work mode to home mode is always a difficult one.
I do try to slip in time to take a walk or exercise when I can. I make time for the relationships in my life because despite being an introvert, I know that those relationships are critical to my happiness. Meantime, I’ll buckle down, do what I have to do and we’ll try to once again conjure the miracle that is an on-time delivery of a complicated software project with over one million lines of code written by a team of 40-50 folks from at least three locations across the globe and tested with thousands of tests and thousands of hours of cpu time on computers running all over the world to increase our confidence in the quality of what we’re shipping. And, you know what? It’ll still have bugs and some of those will be ugly. And we’ll start fixing those and start talking about what the next release has to have and how quickly it has to have it and start the process all over again!
0 Comments