Adds/cuts uncovered: The making of a new release

This is a fun time to work at Microsoft and particularly Office. One of the biggest benefits of working in Office is the opportunity to interact with some of the most experienced and proficient software talent in the world. Internal at Microsoft, the Office development process and its leadership are held in high regard. The company recently moved many Office managers into the Windows organization to cross-pollinate the rigorous Office process is that part of the company. I’m confident Steven Sinofsky will do a great job—he and his team are the best around!

Vision, specs and features

The last few months the team has been iterating on different vision alternatives and working hard to craft a release that is most compelling to customers. As with every release, we always come up with far more ideas than we could possible complete without turning the product into a Frankenstein bug farm and the release into a dreaded death march. The project I’m working on (it’s not Access) has really some cool opportunities to change how people work with data in exciting ways—figuring out the schedule is fun and painful. Let me explain…

Our team is using the Access Projects template and SharePoint to put together a detailed plan of specs and features (I might blog about the database later if people find that interesting). Developers are deep into architectural design and figuring out costs and working with PM to draft spec names and features for each spec.

The first step is to put together SWAGS. These are wild guess at the number of developer days it would take to write the feature. Every week we are working to break down big estimates into smaller costs and tasks. Each spec and task are assigned a priority of 1, 2 or 3 (three’s always get cut). Along with breaking out costs developers are also working on SP bug fixes, improving the quality and maintainability of the code base, and playing with new prototypes. Yeah, I have seen some cool demos that last couple weeks—it is fun to walk around the develop halls and here “hey Clint, I have something to show you.”

Program Managers are busy working on visual click-through, doing customer research, arguing respectfully about vision directions, and writing one page specs. These are simple documents that describe chunks of work from a customer and scenario perspective. We also try to describe what the feature isn’t going to be.

Balance a schedule that overflows

As part of figuring out our schedule we put together project rollup reports. These rollup reports break the project into investment areas (categories) so that we can get an idea of investments for big bets. The team always generate more specs and features than is possible in 2 releases. Cutting that list back is hard. We always start by reflecting back on what the vision and customer scenarios. The first few cuts are pretty easy—we always have ideas on the schedule that would be cool but don’t tie into the vision, carry extra risk, or don’t address a broad enough customer need. The hard part comes several weeks into the process when you are 30% over and have trimmed things back.

There are four ways to balance a schedule after you have trimmed all the fat:

1. Cut a big area. Oh this is painful. The area is always interesting otherwise it still wouldn’t be on the schedule.
2. Cut all P2 tasks. With this strategy you cut of fingers but keep the body in tack. This strategy cuts everything that isn’t vital but keeps all the big bets on the table. The problem with this approach is it leaves you with zero wiggle room. When things take longer than first anticipated (and they always do) the team is left with tough decisions.
3. Code longer and test less. This is a scary way to move forward because it puts your project at risk of not having enough time to fix bugs. Customers typically don’t appreciate buggy, slow, or unsecure software. The last thing you want to be is a coupon in the box because you didn’t have time to finish it—that is what happened in Access 95 and team members still tell vivid stories.
4. Move the schedule out. This isn’t an option if you ship in Office. These days, I prefer to ship more frequently and iterate based on customer feedback.

The only way to balance a schedule that over booked is to break out the ax and make deep, swift cuts. Look for items in the schedule that aren’t required for the vision and introduce the most risk. It takes courage to avoid the temptation of hiding work items from the schedule or cutting all your P2 features. Both of these approaches chew into the schedule safety net and introduce risk.

When you make deep cuts don't plan on reheating it for a future release. The process needs to start all over again with identifying customer scenarios that drive break-though innovation. The next release needs to encompass ideas that are far bigger than your previous cut list.

Today, we cut some features I would have LOVED to ship. They weren’t required for the vision and just didn’t fit into the schedule. Those meetings are painful but super helpful in focusing resources on what is most important. In the end, it is more important to ship key break-through innovation than lots of mediocre features.

Comments

• Anonymous
  March 10, 2007
  Hi Clint, What's P2? Just out of curiosity, do you use Office 2007 speech recognition when preparing your posts for this blog?

• Anonymous
  March 11, 2007
  P2 is shorthand for Priority 2. I don't use speach recognition but I do try to write in a personable voice. Blogging is a challenge for me as my day job is unbelievable busy these days. But, I do think it is important for our customers to hear more about Access and Office. It is really helpful for me to get feedback on the quality of the project and issues you find important. Fortunately, people have been open and respectful in their responses. Posts about product issues challenge me to do a better job while positive posts about 2007 make all the long hard days and nights worth it.

• Anonymous
  March 12, 2007
  The comment has been removed

• Anonymous
  March 13, 2007
  Thanks Henry for the comment. Resources, Quality/Functionality, and Time are three great pivots for a project leader. Some times there is a temptation to add resources to a project that is going wrong. The more complex the project the less throwing more people at it will help. In the Access/Office world it is very difficult to recruit engineers with the ability to deal with the complexity. In most new hire cases, it takes 6 months before people are productive. There are cases where late in the cycle we have moved experienced developers from areas that were buttoned up to tackle areas with greater bugs and stability. You can gain grown but strategy is a bit limited... One of the challenges of developing software in Office is the limited flexibility of extending the schedule. Office is a train and you have to plan your schedule to get on the train. Quality/functionality are the levers I have available--lowering quality is the wrong answer. I like to plan a project where you can add features later in the release based on customer feedback and changing market dynamics. There is a balance because it is important to tackle big problems and stretch people to achieve more than they thought possible.