Sunday, March 05, 2006
Re: Cote on Enterprise Agile
Cote has a good post on Enterprise Agile. All too often the consultants and academics of the world punt on providing advice on how to apply an idea to your work environment. It's great to see Cote taking this issue head on. That is how can enterprise software vendors use and apply agile. Here are some of my ideas building from Cote.
Re:Scrums-of-Scrums needs work:
This is all about fighting the fiefdom mentality. If you have multiple teams, then at some point infighting will start. Each team will think the other team is a bunch of idiots. If they are geographically separated, then this divide will start faster and grow deeper over time. To combat this you need to make sure at least some people are rotating amongst the various teams. This helps minimize the amount of animosity. Also, you have to find first-line managers who are willing to reassign resources without making it an emotional endurance test. If employee A has the skills to something on team 1, then let him move and encourage it. The single most important thing though is to make sure the teams understand they are working on one collective product. Instilling a common vision in everyone helps keep everyone on the same page
Re: Sales and Marketing
The truth about enterprise software is it's more like consulting then consumer software. A consultant engaged on a long-term project needs to cultivate a good client relationship. Most enterprise software revenue actually comes from maintenance. So what should the software sales rep be selling? First, he has to sell only the features in the product. Now, in return for towing the line on features, he should be able to sell predictability and reliability. That is the software is going to release on time every time. Everyone knows software releases are late and sometimes moslty lacking. Agile fixes this if nothing else. You should be able to easily predict when your going to release. As far as presenting the road map to customers, limit your discussions to only the story cards done in the first few iterations. This way you have them in the bag by the time customers are hearing about them. Enterprise software is more like a marathon then a sprint. You will never have all the features done for all the customers. However, if you deliver on time, then you are way ahead of the crowd. More importantly, customers will start to appreciate this thus preserving your maintenance revenue.
Re: Support:
Make support its own agile team. This group should be responsible for creating all hot fixes. All hot fixes should be rolled into quarterly service packs. Service packs should only contain bug fixes, no new features. Most importantly, make sure this team is staffed with people who like the firefighting that comes with the job. Support can't be a dumping ground for low performers. Think about it, support is one of the most important parts of the company. They are chartered with working with the customers at the most difficult times. If you don't staff it with good people, say goodbye to the maintenance revenue.
Re: Upgrades
If you are delivering package software then it's impossible to give customer new releases more than a few times a year. Ideally, I think you have one major and one minor release every year with service packs every quarter. The upgrade rarely works and mostly fails because it has been tested in a controlled environment. The best option is to replicate a real customers environment and test the upgrade on that. If that is not possible, then find the largest customer you have. Chances are they were already planning on testing your software before it goes into their production environment. Commit yourself to working with them to test the upgrade. Both sides win here, your largest customer gets preferred treatment and you get to really test the upgrade.
Okay, that's it from me. I think this is a great topic and would be very interested in how others are doing Enterprise Agile. ¶ 5:52 PM
Re:Scrums-of-Scrums needs work:
This is all about fighting the fiefdom mentality. If you have multiple teams, then at some point infighting will start. Each team will think the other team is a bunch of idiots. If they are geographically separated, then this divide will start faster and grow deeper over time. To combat this you need to make sure at least some people are rotating amongst the various teams. This helps minimize the amount of animosity. Also, you have to find first-line managers who are willing to reassign resources without making it an emotional endurance test. If employee A has the skills to something on team 1, then let him move and encourage it. The single most important thing though is to make sure the teams understand they are working on one collective product. Instilling a common vision in everyone helps keep everyone on the same page
Re: Sales and Marketing
The truth about enterprise software is it's more like consulting then consumer software. A consultant engaged on a long-term project needs to cultivate a good client relationship. Most enterprise software revenue actually comes from maintenance. So what should the software sales rep be selling? First, he has to sell only the features in the product. Now, in return for towing the line on features, he should be able to sell predictability and reliability. That is the software is going to release on time every time. Everyone knows software releases are late and sometimes moslty lacking. Agile fixes this if nothing else. You should be able to easily predict when your going to release. As far as presenting the road map to customers, limit your discussions to only the story cards done in the first few iterations. This way you have them in the bag by the time customers are hearing about them. Enterprise software is more like a marathon then a sprint. You will never have all the features done for all the customers. However, if you deliver on time, then you are way ahead of the crowd. More importantly, customers will start to appreciate this thus preserving your maintenance revenue.
Re: Support:
Make support its own agile team. This group should be responsible for creating all hot fixes. All hot fixes should be rolled into quarterly service packs. Service packs should only contain bug fixes, no new features. Most importantly, make sure this team is staffed with people who like the firefighting that comes with the job. Support can't be a dumping ground for low performers. Think about it, support is one of the most important parts of the company. They are chartered with working with the customers at the most difficult times. If you don't staff it with good people, say goodbye to the maintenance revenue.
Re: Upgrades
If you are delivering package software then it's impossible to give customer new releases more than a few times a year. Ideally, I think you have one major and one minor release every year with service packs every quarter. The upgrade rarely works and mostly fails because it has been tested in a controlled environment. The best option is to replicate a real customers environment and test the upgrade on that. If that is not possible, then find the largest customer you have. Chances are they were already planning on testing your software before it goes into their production environment. Commit yourself to working with them to test the upgrade. Both sides win here, your largest customer gets preferred treatment and you get to really test the upgrade.
Okay, that's it from me. I think this is a great topic and would be very interested in how others are doing Enterprise Agile. ¶ 5:52 PM
