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:
- Cut a big area. Oh this is painful. The area is always interesting otherwise it still wouldn’t be on the schedule.
- 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.
- 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.
- 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.