Scrum - something for maintenance projects?
Phew.. Been a couple of busy weeks. I have just become the project leader in a 5 person project. I've been in this project with various roles since I started in May last year. This is a great opportunity for me to be part of something and to change it to something better if possible. Not that you always need change, but I tend to think that change is good in so many ways that some changes should be made in order for people to stay with a project over a long period of time. I really wonder why so many people do not want such a job. The possibility to be a change-maker!
The challenge in our project is that it is an "old" project by IT standards and it is in maintenance phase. The project consists of 5 people in a good blend of experienced and not so experienced. Me being part of the latter when it comes to my new role. What I find interesting is the energy I feel about this! I've always felt that I put out the questions to my surroundings. It now seems that I will be put to the test myself and have to do action based on others questions and requirements.
Hopefully I will be able to change some elements in the project so that we can work in new ways and see change bring new energy in to the project. I have a dream about an energic group of people working together to make the best they have ever made. When we deliver we should be proud of what we have done and feel that it was worth it. This is a bit childish and naive, but I think it is possible if one can create the right circumstances. It can happen! I really look forward to work with the people, the environment and the product from within this role.
With this perspective I have looked to Scrum. I see elements in Scrum that can be usefully applied in our project. These elements being the product backlog, sprint backlog, daily scrum and burndown charts. Especially the sprint backlog as this will allow developers to focus on these issues and then the burndown chart to see the progress and make it possible to feel that we are moving toward a goal.
Our project is in maintenance phase which I find exiting for this kind of "method". This means we have bugs being reported as well as new functionality into Jira. This will be our starting point when we begin to work on our product backlog.
So there you have some of my thought on change in our project. Maybe someone have seen Scrum used in maintenance projects earlier and would like to give a comment?
2 comments:
Congratulations on your new position. Good to see you have such high spirits for going into that kind of project that so many detest :)
I haven't used Scrum for a pure maintenance projects. However, I have seen projects entering into the maintenance phase where the Scrum "rythm" has gradually faded away, mostly due to lack of dedicated resources, but that doesn't seem to be a problem in your case.
I would recommend that you put alot of energy into keep on releasing new deployments at the end of each sprint, even if the releases are meant for testing only. Maintenance tasks are easy to break down since the domain is clear and the work to be done is well defined in most cases.
Define the goals in road maps. Study some mature open source projects and see how they keep doing maintenance releases at a steady pace (Eclipse for instance). I guess you're also familiar with Confluence's new release cycle.
More specifically, use branching in subversion combined with use of the maven-release-plugin if you are using these tools. Test-driving and continous integration are also good techniques you should adopt if you haven't already.
Other than that, good luck! I hope your enthusiasm rubs off on your team-mates as well :)
Thank you Thomas!
I will be sure to have a look at other projects.
Post a Comment