How To Have Scrum In Sustenance or Maintenance Projects – Agile In Support Work
Posted on October 1, 2011
Filed Under Scrum Basics | Leave a Comment
Scrum framework can be applied to maintenance or support kind of work too. There is a misconception that the Scrum framework doesn’t hold good for maintenance work. Actually, it may look a little challenging initially to tailor Scrum to fit sustenance. Here is a brief on what could be done.
Generally, Support/Maintenance work involves lot of churn. Changes happen almost daily. Team has to work on high priority customer issues and sprint plan will keep getting interferences (unpredictable user stories) and tasks may need to be added in the middle of a Sprint. Maintenance project may not have releases as in the case of development projects. How do we handle this?
-
Important thing to note here is to have a short Sprint. Generally 1 Week Sprint. This will make the Sprint Plan to focus on priority items that need to be worked, through out the week and to resolve issues. This will make customer happy.
-
Keep more buffer time while planning the sprint – You never know if an escalated issue might land in your bin that may override all other current issues. If you have about 20% buffer time, you may be comfortably handle priority items without much impacting the sprint plan. If not new issues come, we just continue with the work and if there is bandwidth left, we may pick up more issues from the issues-pool.
-
Scrum-ban technique is being adapted by many. It is a combination of Scrum and Kanban method. It mainly categorizes support tasks in to “Not started”, “In progress”, “Done” on a white board. Post its with task description will be used to categorize the current pool of tasks. For more do check this nice article.
Information Refrigerators vs. Information Radiators In Agile Software Development
Posted on March 12, 2011
Filed Under Scrum Basics | 1 Comment
We have seen detailed project reports generated week on week, stored in a repository where all managers have access to and the reports are safely protected by password. The reports may be quiet detailed that it provides in-depth information on the project status but often they do not serve the purpose. Firstly, the reports are not visible to all and secondly someone needs to dig up the report to get the information. We call such information as Information Refrigerators.
An Information Refrigerator is a chart you have to open up and dig around in before you find the ketchup you’re looking for.
One of the best practice of Agile software development is Information Radiator.
An information radiator displays information in a place where passersby can see it. With information radiators, the passersby don’t need to ask questions; the information simply hits them as they pass. Unlike Information Refrigerators, it takes very little energy to view the information.
An information radiator is a large display of critical team information that is continuously updated and located in a spot where the team can see it constantly. The term "information radiator" was introduced extensively with a solid theoretical framework in Agile Software Development by Alistair Cockburn
Information radiators are typically used to display the status of work, the condition of tests or load build status, the progress of the team. Team members are free to update the information radiator as and when the status changes. Some information radiators may have rules about how they are updated. Whiteboards, flip charts, poster boards or large monitor displays can all be used as the base media for an information radiator. In one of the projects where Agile Software Development is strongly practiced, we have seen large monitor which displays the unit test status, the load build status etc in a visible color codes fashion that is easy to digest.
Here is an example of a task board:
Source : http://www.mountaingoatsoftware.com
keep looking »

