Can Agile Maintenance Maintain Agility?
Just a few days back we fell of the bandwagon and it hurt badly. I'd say our most agile department was forced to close down and put the 10+ games they had into maintenance. Then almost all of the resources was reassigned into core business areas. But nothing bad without some tiny bit of good. In our case it was that we finally got both time and a quite substantial incitement to deal with how we maintain our products and how we run projects also.
The product owners has not been accountable for ROI, or it simply hasn't been possible to calculate if a great ROI was better than a huge ROI. From a sound software development standpoint the business has been too successful. But the tide has turned. I finally got everyone accepting that we have to be more restrictive when starting projects. Previously a project has been a pool of resources following every whim of the product owner. But in a competitive world you change the software to earn money. The majority of such changes are either tuning or larger re-structuring extensions that is they can either be handled outside of a project (tuning existing functionality) or they can be allocated to a project. A project that actually has an objective, something that can be fulfilled. The products and projects we have are challenged by consumer producer patterns but that is another story.
Maintenance was previously done by the projects and maintenance is by its nature hard to predict and estimate so project and sprint planning was almost impossible to do with accuracy. I can not really count all the times when sprints has been ruined by defects from the live environment, unforeseen changes in payment solutions and what have you not. To never be able to meet the targets you set up is seriously disheartening to the team members. But now I feel we can give them the opportunity to actually make realistic plans that they will meet.
Maintenance will be done by a dedicated team outside of the projects in a day-to-day activity. The day-to-day work will then be structured around a backlog and the sprints will match the release cycle of patches allowing us to utilize Scrum as the driver of the day-to-day work. To prioritize what to do will be simple and regulated by pre-designed rules.
Can we make this work? In theory and with our history it seems like a very good idea that should work out of the box - but I guess that I'll have the opportunity to get back on the subject. Hopefully Ill have a success story to share as well as a set of lessons learned from the things that didn't work as planned.
The product owners has not been accountable for ROI, or it simply hasn't been possible to calculate if a great ROI was better than a huge ROI. From a sound software development standpoint the business has been too successful. But the tide has turned. I finally got everyone accepting that we have to be more restrictive when starting projects. Previously a project has been a pool of resources following every whim of the product owner. But in a competitive world you change the software to earn money. The majority of such changes are either tuning or larger re-structuring extensions that is they can either be handled outside of a project (tuning existing functionality) or they can be allocated to a project. A project that actually has an objective, something that can be fulfilled. The products and projects we have are challenged by consumer producer patterns but that is another story.
Maintenance was previously done by the projects and maintenance is by its nature hard to predict and estimate so project and sprint planning was almost impossible to do with accuracy. I can not really count all the times when sprints has been ruined by defects from the live environment, unforeseen changes in payment solutions and what have you not. To never be able to meet the targets you set up is seriously disheartening to the team members. But now I feel we can give them the opportunity to actually make realistic plans that they will meet.
Maintenance will be done by a dedicated team outside of the projects in a day-to-day activity. The day-to-day work will then be structured around a backlog and the sprints will match the release cycle of patches allowing us to utilize Scrum as the driver of the day-to-day work. To prioritize what to do will be simple and regulated by pre-designed rules.
- Catastrophic defects
- Critical defects
- Highest prioritized item on backlog
Can we make this work? In theory and with our history it seems like a very good idea that should work out of the box - but I guess that I'll have the opportunity to get back on the subject. Hopefully Ill have a success story to share as well as a set of lessons learned from the things that didn't work as planned.
Comments