Darryl.net

It is far more exciting to develop a new software product than to maintain an old one. A new product requires creative thinking, strong teamwork, and racing against a deadline. An old product requires bug fixing, late-night support calls, “scheduled downtime,” and saying goodbye to colleagues who are headed for the next cool thing. How should we accommodate the dull reality of maintenance mode? I discuss three options below.

1. Never enter a maintenance mode.
This is also affectionately known as “Always Be Shipping.” Essentially, your team ships early and maintains what is in production while simultaneously developing additional features. The team remains focused and motivated, fixes critical bugs when needed, and stays dedicated to the product. Unfortunately, this means no downtime for the developers or QA, little chance to step back and analyze performance and feedback, and a constant need to balance between product stability and feature development.

2. Hire a maintenance team.
Call a spade a spade. Maintenance is no fun, so hire someone else to do it. This gives a chance for lesser experience developers to come up to speed and potentially contribute to the product in the future (and keeps the “rock stars” focused on new bling). You could even go so far as to ship it half way around the world to Russia or India – though Bangalore (sorry, Bangaluru) doesn’t want your bugs anymore than you do. The main problem with this ‘outsource’ approach, however, is that the new engineers do not know the code and it is difficult to transition this knowledge. It will take much longer to stabilize the product and add management overhead.

3. Swap maintenance and development modes.
What if you could get around the problems of both #1 and #2 by taking a hybrid approach? If you are developing under “Agile” methodologies, why not split the team up into two groups – each with their own set of rock stars and newbies. Let’s call these two teams the “Red Team” and “Blue Team.”

In the lower row, the Blue Team has just finished a series of sprints developing new features. Now they move into maintenance mode on those new features for a few sprints. During that time, they also work with User Experience & Design (UED) to spec out new features that they will work on when they move back into development mode. In the upper row, the Blue Team moves back into development, and the Red Team moves into maintenance mode. UED now attaches to the Red Team.

There are many advantages to this approach:

• The team gets a breather during maintenance mode. Furthermore, they can concentrate on stabilizing what they just built, rather than writing new code.
• There is incentive to develop more robust code and to fix it quickly. The more solid the code, the more time the team can spend with UED during maintenance mode to think about the future.
• “Rock Stars” stick around because they are always either a) developing the new features, or b) thinking about new features.
• If there is a product manager for each team, this also gives time for the product manager to analyze performance of and feedback on the new features.
• The developers fixing the code know it intimately.
• You can bring new hires into the mix by having them join a maintenance team. Veterans can take time out to help the newbies fix and learn the codebase.
• You are still “always shipping.”

This might require a slightly larger team than initially planned. However, in the long run it could make up for the churn associated with major product launches.

Of course, this “Maintenance-Development Swapping” is just a theory of mine right now. I do intend to try it out in the future and will let you know how it goes. If you get a chance to try it out sooner, please comment on your experience.

No comments

Even though I work for Yahoo!, I have to take a moment to applaud the Google Mobile Maps team. After reading ‘Freeing Google From the Desktop‘ in the WSJ the other day on the bus, I decided to check out the Google mobile site on my WAP phone, even after Walt warned me that it wasn’t the right URL for my phone.

Here’s a summary of the wins:

1. Went to the regular mobile site on my phone and there was a link that read ‘On a mobile device?’ Brilliant, because this link appears at the top of a page on a WAP browser, allowing me to click on it without waiting for the rest of the page.
2. Clicked on it, and Google recognized my Treo and suggested compatible apps.
3. Downloaded maps quickly and easily installed it on my Treo.
4. Opened maps, and saw San Francisco (now, does everyone see this, or do they know where I live?).
5. Easy scrolling with my stylus. Relatively fast download of the map data with feedback to let me know how long I might have to wait.
6. Instant feedback on the zoom (a box shows where you’ll be looking and gives you a chance to adjust further before downloading).
7. All the features I want without adding any additional fluff I don’t want: Find location, Find nearby businesses, Directions, Satellite View, and Traffic. (OK, I have one request: traffic incidents. The red lines are a good indicator, but 101N always has traffic. An incident is even a better indicator that 280N might be a better choice.)
8. The directions feature is beautiful: From, To, and then hit the spacebar for each successive instruction.

I’ve been told the Treo version is the nicest of the bunch, so maybe I’m a little spoiled. Kudos to Steve and the Google Mobile Maps team - an impressive product.

No comments

Often overlooked, a good vision is an octane boost for your project.

A good vision:

• is a short and concise statement or illustration
• has soul and is from the heart
• inspires; makes an impression
• starts with one person
• can be explained in less than a minute
• is a stretch, but feasible
• can help eliminate all the distractions that do not get you to your end goal quickly
• is embraced

A bad vision:

• is a meaningless sentence comprised of cliches and buzz words
• is forgotten two hours later
• leaves people more confused after hearing it
• is written in a 2 hour meeting with 10 colleagues
• doesn’t align people
• is a project plan used in lieu of a vision
• is used in water cooler jokes

The time to create a good vision (at LEAST a few days of individual thought, followed by some fine-tuning with stakeholders) is well worth the investment.

A few books to help: Leading Change by John P. Kotter and The Leadership Challenge by Kouzes and Posner.

No comments

Public Radio International (PRI) recently aired a repeat episode of This American Life called “Fiasco!” There are four ‘acts’ in the episode, each chronicling a horrible confluence of events that leads to utter chaos. For some reason, I found myself remembering equally poignant software development experiences when listening to three of the four ‘acts.’

Act One: a dramatic production pushed to its limits.
The actors are good, but are striving for something beyond their capabilities; the set is overdone, but beautiful; the technology is new, but promising… Peter Pan is flung into a giant mushroom because the high-tech flying machines are too hard to operate. Captain Hook flings his hook-hand into an old lady in the first row. The audience goes from forgiving to cackling and hungry-for-destruction.

Ever had a similar experience with a high-performing software team? Probably - these teams are usually pushed to their limits and on the verge of collapse. When managed well, amazing results can occur. However, when stretched too far in all directions, any setbacks can ricochet throughout the organization and tear a team apart. Sometimes, people outside the team (the ‘audience’) might help the fiasco along in order to poach prized engineers.

Act Two: castle defense gone wrong.
An army leader defending a medieval village makes many promises based on sound testing. When the time came to defend the village, the cauldron of oil didn’t get hot enough due to unforeseen heating fuel issues. The attackers, having giving into to their weariness from beating on the gate, a re-enraged when lukewarm oil is poured on them.

Testing and forecasting is a best-guess effort. Often, when put to the real world, previously elusive special cases seem to sprout like weeds from the beautifully designed garden that is your final product. Then, these issues cause other problems, like failing to meet a marketing deadline. Then the marketing team gets pissed and doesn’t want to support you in the future.

Act Three: attempting to oust Car Talk.
A local radio station doesn’t want to pay for the popular car show that has destroyed all others. The producers decide they can roll their own. Not only does it flop, but it gains a few ardent followers that won’t let it die, forcing the radio station to continue to produce the show while also airing the victor.

When a competitive software product has won, why do we continue to fight against it with the same formula? The me-too approach doesn’t win - further, it backs you into the corner of maintenence. The only way to get around this is to flank the competitor with something materially different. Open Office is a FREE me-too office suite that can’t gain traction. Firefox embraced the security angle to gain a foothold, but is still having a hard time because it is just another browser (maybe Flock has a chance).

Act Four: a fiasco as a force of good.
I couldn’t think of an example where a software development fiasco turned out to be something good.

To avoid these fiascos, check out the following document forwarded to me by Tim Anderson, a PM friend of mine: Is Your Project Out of Control? found on Team Central. I found many of the situations and tips to be valid.

Good luck controlling the chaos.

No comments