aspose file tools*
The moose likes Agile and Other Processes and the fly likes Agile Adoption in Traditional Maintenance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Agile Adoption in Traditional Maintenance" Watch "Agile Adoption in Traditional Maintenance" New topic
Author

Agile Adoption in Traditional Maintenance

Anadi Misra
Ranch Hand

Joined: Jun 03, 2008
Posts: 69
Hi,

I would want to know how effective is Agile in a typical maintenance scenario. Somthing like this

A develops a software(Agile) -> Released to Production as Service -> A acts on Service Verification -> Handover to B

B here is supposed to take care of Bug Fixes, Service Requests, Change Request etc.

I dont think XP/Scrum could help here, You dont certainly have a fixed set of User Stories at the start of a sprint, and more specifically many such projects have SLAs and OLAs and the like to take care of to deliver a bug-fix. It seems even TDD wont be much of an advantage here, unless ofcourse there are multiple bugs of the same type or so.

The other big problem is tranistion itself as we know things being in the project but I have seen "Just Enough Documentation" doesn't help the people at maintenance side as it is a complete new system for them

Any thoughts pals?
[ September 09, 2008: Message edited by: Anadi Misra ]

Anadi Mishra.
Jim Jarrett
Greenhorn

Joined: Oct 31, 2005
Posts: 4
I disagree - I literally just had this same discussion with my team lead. We're about to start a Scrum based project, and she was wondering how this could be useful to maintenance.


Call a sprint a fixed set of bugfixes or enhancements. Those bugfixes or enhancements are your user stories.

Then once you finish that fixed set, tested it out, it's ready to deploy to production. Whether you actually do or not, is up to you. But you should have a DEPLOYABLE result at the end, so if you move on to another set of bugfixes/enhancements, build on that previous iteration, until you actually do deploy.

This would be an excellent way to keep scope creep from happening in maintenance releases; instead of adding "just one more" thing, you only work on the agreed-upon set, but if you're releasing more often, then the wait to get "the next important thing" isn't as long as it may have been in the past.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Anadi Misra:
I dont think XP/Scrum could help here, You dont certainly have a fixed set of User Stories at the start of a sprint, and more specifically many such projects have SLAs and OLAs and the like to take care of to deliver a bug-fix.


You can still involve agile planning practices to help you better understand the work you take on and the overall cost and rate of development.

It seems even TDD wont be much of an advantage here, unless of course there are multiple bugs of the same type or so.

There are many additional potential benefits of TDD (most importantly, design impact, documentation, and the ability to refactor), enough to suggest that TDD can be a significant advantage.

If you follow TDD, then you buy into the notion that all changes to the system are effected by first writing a failing tests. There is no good reason that you would diverge from this basic rule for maintenance programming, unless you deliberately wanted the quality of the software to degrade.

The other big problem is tranistion itself as we know things being in the project but I have seen "Just Enough Documentation" doesn't help the people at maintenance side as it is a complete new system for them

Then it's not "just enough documentation," is it? Agile says, (a) produce what you need and (b) recognize that producing documentation has a cost. If you are transitioning to maintenance mode, then part of one iteration needs to involve producing appropriate documentation for the maintenance team.

Also, a test-driven system, done well, can provide the best documentation that a maintainer could ask for.

Regards,
Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Anadi Misra
Ranch Hand

Joined: Jun 03, 2008
Posts: 69
Hi,

Call a sprint a fixed set of bugfixes or enhancements. Those bugfixes or enhancements are your user stories.

Then once you finish that fixed set, tested it out, it's ready to deploy to production. Whether you actually do or not, is up to you. But you should have a DEPLOYABLE result at the end, so if you move on to another set of bugfixes/enhancements, build on that previous iteration, until you actually do deploy.


Interesting, but If I look at my colleagues in AM, a bug raised is a ticket with a deadline based on severity, say a S5 has five days for them, a ticket is closed and informed to the client once it is deployed to production. I cant actually see here what the sprint would be. This is because they dont really have the liberty to extend a S5 to more than 5 days. The problem is SLAs and OLAs which I feel cannot be answered by a sprint way.

Having said that I think this way will certainly work for say Service Requests or Change requests were a window of 15 days is provided.

I agree that TDD is still adoptable. May be thats the only part that can be adopted.
[ September 10, 2008: Message edited by: Anadi Misra ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Anadi Misra:
Interesting, but If I look at my colleagues in AM, a bug raised is a ticket with a deadline based on severity, say a S5 has five days for them, a ticket is closed and informed to the client once it is deployed to production. I cant actually see here what the sprint would be.


That would depend on what percentage of incoming bugs have such a tight deadline for fixing. You might need to have shorter sprints, and or to plan a contingent of fixing-not-yet-know-bugs tasks for a sprint.

Remember that one property of Agile teams is that they release to production often. And once they released, they are basically in maintenance mode, anyway. So, it might even be fair to say that most Agile projects out there are actually maintenance projects.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Amr Elssamadisy
author
Ranch Hand

Joined: Sep 08, 2008
Posts: 37
Pinging in late, but better late than never

So Anandi, I would like you to characterize your maintenance team in terms of either pains or business values, and then we can talk about what practices - if any - maybe useful. Since I don't know your exact context, it is difficult for me to give a precise answer.

This is actually the premise of the book, and why I pulled apart methodologies like XP and Scrum into their component practices, because they are not granular enough.

But back to your particulars and a few possible suggestions based on other maintenance teams I've worked with:

1) You are right, iterations might be difficult in such a situation and are not necessarily needed.

Let's assume time to market is very important - it usually is when you have a showstopper bug that needs to get out asap to a client. Here are a set of practices that will generally help immensely:

1) Automated tests - both unit and functional. This allows you to fix bugs quickly because you are not worried about breaking other parts of the code. It literally eliminates extra work in regression testing and gives great confidence.

2) Refactoring - all too often in maintenance mode we put a 'band-aid' as a fix because we are in a rush or we don't understand the full problem. This slowly degrades the design and creates a design debt so, over time, maintenance is more painful and slower. Leveraging automated tests and refactoring will allow you to keep up - and many times improve - your response time.

3) Test Driven Requirements. What happens when you are transferring knowledge between teams? You mentioned "just enough documentation" not enough. Let me suggest that static documentation - that quickly gets out of date and can be misunderstood is not enough either. If, however, your requirements are executable tests, then they are precise, abundant, and always up to date.

There are many more things that I could talk about, but this is a taste. It all begins with understanding the goals for your team and your context.

Hope this helps - Amr


Amr Elssamadisy<br /><a href="http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1220909336&sr=8-1" target="_blank" rel="nofollow">Agile Adoption Patterns</a>
Anadi Misra
Ranch Hand

Joined: Jun 03, 2008
Posts: 69
Hi! Amr,

Thanks for the reply, this way can help better

I would like you to characterize your maintenance team in terms of either pains or business values


I would go for business values and in this case the most important business value is delivering the fix within deadline, and yea time to market here is really important. I have done with automated tests, unit and functional, and continuous integration as well so that part is taken care of.

Test Driven Requirements: Not sure how will this be applied to a process where bugs are reported to defect management system from production environment, either by a call from end user to call-centers or by End-To-End testers in this case. But yes, I'll try playing with this concept to see.

Some information or some elaboration/reference will be helpful.
Amr Elssamadisy
author
Ranch Hand

Joined: Sep 08, 2008
Posts: 37
Sure, check out my first book which is freely downloadable from InfoQ. Test Driven Requirements is defined.

It is also known as Story driven development. And is very related to Behaviour Driven Development (BDD).
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Anadi Misra:

Test Driven Requirements: Not sure how will this be applied to a process where bugs are reported to defect management system from production environment, either by a call from end user to call-centers or by End-To-End testers in this case. But yes, I'll try playing with this concept to see.


Basically you would write a test that shows that the bug exists (by failing) - preferably in a way that the person who reported the bug can understand it and verify that it's really testing the behavior he wants to be fixed. Then fix the bug and see the test succeed. Voila!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Agile Adoption in Traditional Maintenance