The beta release for the new mormon.org was released this weekend. Have a look.
We started the revamp several months ago. This is a great example of using a high fidelity functional prototype to understand what we were building up front, thereby decreasing development time.
The key new features include video testimonies from actual converts of the Church and an online chat where people who are interested in the Church can chat with members to learn more about the Gospel. We've been pilot testing the chat feature for several months and have already seen several people join.
Tech Talk Last Night
We had another tech talk last night in Mountain View, CA. About 30 or so people registered--almost 40 showed up. We had folks from:
It was great fun to meet LDS technologists (and some non-LDS ones) and talk about the Church and technology.
Thanks to all those who came, especially those who drove down all the way from Sacramento!!
- Cisco
- Ebay
- Dreamworks
- Oracle
- Barclays
- The State of California
- Sun Microsystems
- Sprint
It was great fun to meet LDS technologists (and some non-LDS ones) and talk about the Church and technology.
Thanks to all those who came, especially those who drove down all the way from Sacramento!!
Tech Talk in Mountain View
Just a reminder that we're having a tech talk in Mountain View, CA this next week. If you have time, head over to the lds tech site and register so we know how many people to expect.
The Maintenance Monkey
Maintenance. Call it bug fixing. Call it "keeping the wheels on." Call it warranty. Call it whatever you want.
Maintenance is a necessary evil. You're never going to get the product perfect. So you'll always be called upon to fix bugs. Typical large I.T. shops spend an extraordinary amount of effort on "maintenance." Estimates range from 10% of labor budget to 70%. In the past our maintenance budgets have been in the 50% range. That seemed obscene to me so we checked into the actual work being done and learned a lot as we've struggled to reduce the amount of time and money we spend on maintenance. When thinking through how to reduce maintenance expenditure, I recommend consideration of the following:
Use great prototypes to narrow the "gap of misunderstanding" between you and your customer regarding scope before you start development. The practice we're trying hard to implement is having Interaction Designers 6-8 weeks ahead of development before ever entering a Cycle/Milestone/Sprint/Release (or whatever you want to call it). So our "agility" comes from working back and forth with the customer on high fidelity prototypes. This substantially reduces the number of times a customer comes back after you're already done, asking for some new feature they thought "was going to be included from the very beginning."
Test, test, test! Don't under-invest in your QA team or in automation. We made the mistake of under-investing for a long time and felt the pain. We've staffed a high quality QA team with many engineers who could easily be developers in our shop. We find many, many bugs before our customers do. We can do much better, but the improvements in QA have materially decreased the amount we spend on maintenance.
Think Quality. As good as your QA team is you can't make them responsible for quality. They're responsible for offering information. They're not responsible for quality. Your project engineers (developer, infrastructure, networking, desktop, database, etc.) are responsible for quality. Create that culture.
Seperate enhancements from bug fixing. We found, as with most companies, that much of the work being billed as "maintenance" wasn't maintenance at all, but actually "enhancements." I think I may have heard an audible, commiserative sigh. You developers know precisely what I'm talking about:
"Agile development," though waking up and maturing to the realities of the enterprise, pushes the developer into the position of working continually to please the customer. It's hard to draw the line between bugs and enhancements. But drawing the line is critical. Which leads us to...
Implement good governance. Customers should not "shoulder tap" developers to fix bugs OR to make enhancements. Under any circumstance. Ever. Some kind of project manager, program manager, development manager, QA manager or otherwise dispassionate party should create a buffer between the customer (who has genuine needs) and the developer (who, bless his heart, only wants to serve the customer) to make sure that each bug listed is truly a bug. I've had more than one conversation with an executive who, when I mentioned that many enhancements were slipping through into maintenance, asked me why I was allowing his people to do that without his authorization. Learn to say no--gently. Help the customer understand why enhancements are different than bugs and why they should be handled differently. Similary, help the customer understand when it is or is not ok to choose NOT to fix a bug. Not every bug needs to be fixed!
Simplify bureaucracy. In our shop customers have historically tried to stuff enhancements through maintenance because the bureaucracy to do a new set of enhancements was so painful that they couldn't bear to even think about going through the process. We can't do that to our customers! Simplify bureaucracy as much as possible so you become a joy to work with. We have a long way to go on this score.
Allow (Force) customers to prioritize. I.T. should not be saying no. You should give the customer(s) information about what resources you have available, and they should (collectively) make decisions about what to do with the resource. You can cajole, influence, or merely suggest, but the customers should be making these calls. This year, we allowed our customers to re-direct maintenance budgets to new projects. In other words, for every hour saved on maintenance we are allowing that hour to be spent on new project work. Our maintenance expenditures continue to drop!!
How are you dealing with maintenance in your shops?
Maintenance is a necessary evil. You're never going to get the product perfect. So you'll always be called upon to fix bugs. Typical large I.T. shops spend an extraordinary amount of effort on "maintenance." Estimates range from 10% of labor budget to 70%. In the past our maintenance budgets have been in the 50% range. That seemed obscene to me so we checked into the actual work being done and learned a lot as we've struggled to reduce the amount of time and money we spend on maintenance. When thinking through how to reduce maintenance expenditure, I recommend consideration of the following:
Use great prototypes to narrow the "gap of misunderstanding" between you and your customer regarding scope before you start development. The practice we're trying hard to implement is having Interaction Designers 6-8 weeks ahead of development before ever entering a Cycle/Milestone/Sprint/Release (or whatever you want to call it). So our "agility" comes from working back and forth with the customer on high fidelity prototypes. This substantially reduces the number of times a customer comes back after you're already done, asking for some new feature they thought "was going to be included from the very beginning."
Test, test, test! Don't under-invest in your QA team or in automation. We made the mistake of under-investing for a long time and felt the pain. We've staffed a high quality QA team with many engineers who could easily be developers in our shop. We find many, many bugs before our customers do. We can do much better, but the improvements in QA have materially decreased the amount we spend on maintenance.
Think Quality. As good as your QA team is you can't make them responsible for quality. They're responsible for offering information. They're not responsible for quality. Your project engineers (developer, infrastructure, networking, desktop, database, etc.) are responsible for quality. Create that culture.
Seperate enhancements from bug fixing. We found, as with most companies, that much of the work being billed as "maintenance" wasn't maintenance at all, but actually "enhancements." I think I may have heard an audible, commiserative sigh. You developers know precisely what I'm talking about:
"Well, sure it's a bug! You promised me the ability to report and this is a report I need!"
"It's only a few hours, huh? I don't want to go back for approval. Just do it this once, wontcha?"
"Um. Hey Fred. Uh... Listen... I know you're working on a new project, but I was in the neighborhood and happened to have these tickets to the playoffs..."
"Agile development," though waking up and maturing to the realities of the enterprise, pushes the developer into the position of working continually to please the customer. It's hard to draw the line between bugs and enhancements. But drawing the line is critical. Which leads us to...
Implement good governance. Customers should not "shoulder tap" developers to fix bugs OR to make enhancements. Under any circumstance. Ever. Some kind of project manager, program manager, development manager, QA manager or otherwise dispassionate party should create a buffer between the customer (who has genuine needs) and the developer (who, bless his heart, only wants to serve the customer) to make sure that each bug listed is truly a bug. I've had more than one conversation with an executive who, when I mentioned that many enhancements were slipping through into maintenance, asked me why I was allowing his people to do that without his authorization. Learn to say no--gently. Help the customer understand why enhancements are different than bugs and why they should be handled differently. Similary, help the customer understand when it is or is not ok to choose NOT to fix a bug. Not every bug needs to be fixed!
Simplify bureaucracy. In our shop customers have historically tried to stuff enhancements through maintenance because the bureaucracy to do a new set of enhancements was so painful that they couldn't bear to even think about going through the process. We can't do that to our customers! Simplify bureaucracy as much as possible so you become a joy to work with. We have a long way to go on this score.
Allow (Force) customers to prioritize. I.T. should not be saying no. You should give the customer(s) information about what resources you have available, and they should (collectively) make decisions about what to do with the resource. You can cajole, influence, or merely suggest, but the customers should be making these calls. This year, we allowed our customers to re-direct maintenance budgets to new projects. In other words, for every hour saved on maintenance we are allowing that hour to be spent on new project work. Our maintenance expenditures continue to drop!!
How are you dealing with maintenance in your shops?
Subscribe to:
Comments (Atom)