Ship it: Make releasing software on time as common as sunrise

In the past 18-months, Code42 has released on time seven significant feature and performance updates to its flagship CrashPlan product. In this article, Code42 Senior Vice President of Product Development John Durant expounds on one of the key principles for these kinds of successful releases. With more than 20 years of leadership in the technical industry—including time at Microsoft’s Redmond Washington headquarters and as an executive at Code42—John draws on both successes and failures, and shares what works in a world where the best-laid plans can sometimes be no match for the unexpected. Learn more about what is in these new Code42 software releases here.

Anyone in the software business knows how hard it is to ship on time. Most people go into a new project, a new product, a new tech role with the best of intentions: “We’ll do this right this time!” But, too often they end up in the same situation they pledged to avoid: shipping buggy features late and over budget while managing to create internal frustration at all levels. This spiral can be avoided by aligning yourself, your team and stakeholders to a few key principles.

When the unexpected surely occurs, something’s gotta give

Even for the best-managed projects, the possible spoilers are myriad. Staff changes, poor planning, and other factors can have very big impacts on the success of a project. For example, losing one of your key subject matter experts (SMEs) right in the middle of a project can disrupt the entire delivery process and timeline. Tool failures often cause widespread inefficiencies in the team and bog the project down. Vital dependencies usually change a project from green to red in an instant and throw the broader initiative into chaos. When disruptions intrude, smart stakeholders know that something has to give. Returning to the three elements you can control (people, schedule, and scope), you look at your options.

Staffing is slow to change

It is very difficult to quickly change the staffing side of the equation. Onboarding takes a lot of time, and people are usually not productive for weeks or months. And, that assumes that there is budget to hire to new people. Normally, staffing budgets are set at the beginning of a calendar year, and senior leaders loathe spending some of their “get out of jail free” cards on staffing when they know potentially worse problems will come their way.

Schedule changes are expensive

What about the schedule? This is where most people focus their energy. While it is painful to change milestones and delivery dates, many consider this to be the easiest to adjust. After all, it’s just a small string of text. All you have to do is change “10 August 2014” to “10 January 2015.” Voilà! All that remains is to start communicating the date change, and that can be solved with some emails and meetings—maybe even a press release and some damage control if the dates have been public. But, those of us who have been in the business a long time have learned that schedule changes are very expensive and contain many hidden costs. And, frequently it turns out that solving the issues that caused the schedule change in the first place ends up being delayed. Put another way, changing the schedule tends to cause the proverbial can to be kicked down the road.

Scope changes are painful, but productive

Changing the scope is arguably the most painful lever to pull. It tends to be painful because it involves compromising a lot of expectations across many different departments internally and into the external marketplace. Customers crave certain features and fixes, and a very competitive marketplace is thirsty for break-out product advances. And, everyone is keen to make sure that each release is of the highest quality. Executives, who have visibility into all the dimensions of the business, are very attuned to these forces and thus push product management to deliver more. Put simply, there’s a ton of pressure for project scope to be large and expansive.

I am persuaded by long experience and observation that failure to control, communicate, and collaborate effectively around the scope of the project is the main reason for most project failures—and I’m not alone in this view. A leading site, project-management.com, lists the top ten reasons for project failures. Mistakes range from gaps in process, to unrealistic expectations, to poor leadership and communication. The most common misstep: poor scope management. Mediocre processes can still be adequate when project breadth reflects these inefficiencies and is more restrained. Breakdowns in communication and expectations often have to do with changes to project scope—especially the need to trim product features.

Reigning in scope takes true leadership

One of the rarest displays of leadership is when a project owner or primary stakeholder stands up for controlling product scope. Very few leaders want to put their necks out and raise the flag for delivering less. They fear looking feeble or faithless, and it is far easier to pound the table and make seemingly brave commitments to big plans. But, time and again, these bold promises end up becoming boondoggles—and everyone involved ends up enervated.

What are your top priorities?

One of the most important things you can do is to prioritize and rank feature/fix requests taking into account your high quality standard. Prioritize everything on a simple 1,2,3 scale. Of course this scale is all relative, but its important that everyone share the same understanding of what they mean.

For my part, I tend to describe them this way: If we were building a motor car, the priority-1 features would be a chassis, accelerator, steering mechanism, brakes, wheels, engine and gas tank. Plainly put: these elements enable the car to move, steer and stop. Priority-2 features would be seats, body, gears and shifting, windshield, and lights. The priority-3 features should be the longest list. In the car, they would include items like seat belts, carpet, climate controls, stereo system and a spare tire. There should be healthy discussion about these things among stakeholders, and disagreement is expected. But, no one should ever consider starting the project until there is agreement and transparency about these priorities.

What elements are mission-critical?

After establishing priorities, you are ready to do the even harder task: ranking. You must rank all of the things you assigned to the first priority category. Let’s go back to the priority-1 features for the car. I would rank them this way: 1) chassis 2) wheels 3) steering mechanism 4) engine 5) brakes 6) gas tank 7) accelerator. Think about ranking items like this: What if your time was cut short and you had to deliver the project much earlier than expected? What could you live without if you absolutely had to? In our example, we could do without the gas tank. We would only be able to run the engine until the fuel in the line was expended—but that may be the best we can do for now. Or, rather than a real gas tank we could strap an empty milk jug to the chassis and use that for car’s first iteration. We could do without the accelerator by setting the engine’s idle speed such that it is as useful as possible without requiring a change. Great project managers and product managers are adept at quickly assessing these trade-offs on the fly. Always start by ranking priorities, and make sure your team attacks them in ranked order. The first items are the most important.

The line between a pragmatic solution and an unviable product

As we make trade-offs in the face of scope changes, where is the line between delivering an adequate solution (given the circumstances) and simply failing to deliver? What is the minimum viable product (MVP)? In the car example, if we cut the accelerator, gas tank, or brakes, is it still really a car? Will anyone want it? Is the scope too minimal? These are important questions. At a certain point, the scope becomes so narrow that there is no point in incurring the costs. There is little chance that anyone will want the final product.

However, more often, people fall into the temptation to include too many features in the MVP. This starts the project on shaky footing. If it succeeds, it will most likely be the result of mere chance. An MVP should be truly minimal—the absolute bare minimum needed to constitute a recognizable product, not the minimum to needed to be a killer product. Once again I return to the example of the car: A chassis, wheels, steering, engine and brakes would constitute a recognizable car—barely. That is the underlying concept of an MVP.

Focusing on scope, from kickoff through completion

As you manage product releases, you can always retreat to the three dimensions (people or resources, time, and scope) of project management to understand what is happening or should happen in your project. As you plan and execute your product release, make sure that managing product scope is given proper attention, that you exercise extreme discipline in assuring that features and fixes are properly prioritized and ranked. Also, make sure you have a shared and transparent understanding of what constitutes an MVP. With the solid foundation of a realistic scope, you will find that your releases will generate less drama and will be more predictable and pleasing for all involved. Chances are you will be the one who has to stand up and demonstrate true leadership in showing others the wisdom of proper scope control. You will need to be resilient as you encounter opposition, and you’ll have to draw on all your powers of persuasion as you argue that sometimes delivering less can ultimately deliver more predictability, quality and satisfaction among those who do the work. Your team—and your customers—will trust you more as they begin to see that your next release is as certain as the next sunrise.

Download The Guide to Modern Endpoint Backup and Data Visibility to learn more about selecting a modern endpoint backup solution in a dangerous world.

Code42_Guide_to_Modern_Endpoint_Backup_Banner


Leave a Reply

Your email address will not be published. Required fields are marked *

*