Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
What SDLC methodology would you use for an end-of-life software application?
Network:50



My team develops new enhancement in a very old software application (6+ years). I joined this team about 4 months ago and my assessment is that we are seeing some of the classic symptoms of maintaining a legacy application.The team so far uses 2 week sprints and practices scrum. These are the problems.
1. Our estimates are never accurate because we find new challenges while implementing new enhancements. (eg: pieces of dead code, convoluted change to existing module)
2. We never have met sprint commitments because you cannot estimate unknown challenges.
3. We have 2-3 bugs out of delivered functionality because the existing code is too fragile.

There isn't budget to rewrite the application. The product has been very successful but the ride from inception to production of a feature is extremely bumpy.
I was considering switching over to ScrumBan or Kanban since there is no value to committing points in a sprint. Looking for some thoughts here!
Sort By:
Network:1746



There are a mix of topic in your question. Let me clarify my point of view: 1-if you are performing maintenance and you will perform maintenance in the future to follow Agile based method is not recommendable because you need to keep a critical asset in some place: knowledge. As you know, follow Agile based methods keep knowledge into the head of people that are participating right now so we aware about that people rotation. 2-estimation methods always have an inherent error no matter the method you use (see Barry Bohem´s Cone of Uncertainty) but the worst method in that matter is story points (by the way, I am using it). So, undertand the inherent error to face the deviations. 3-you are loosing focus. If you detect possibilities of improvements then they must be shifted out to next sprints (recommendable). 4-in your case, the approach is not the problem. Do not fall in the trap of the silver bullet syndrome.
Network:14



I agree with Sergio. If this application is indeed "end-of-life" (by this statement, I interpret you are NOT going to commit to this application in the long run, only keep it running until the replacement is ready to deploy to production and then decommission THIS application), then spending effort to remediate technical debt (dead code, streamlining existing logic, etc.) is not relevant to the scope of your maintenance effort and should not be done (even if tempting).
Sprint preparation MUST include an assessment of the complexity and the size/impact of the proposed change. That is the "point" of committing to points in a Sprint during pre-planning. By the time the entry is ready for inclusion in the Sprint, the understanding of the change scope and complexity is fairly complete, the tasks listed, and tests identified. Changing to ScrumBan or Kanban does not change the need to clearly define the tasks and expected (testable) results.

Invest a little effort in preparation for the Sprint content, and control the desire to "fix" challenges that are not in scope (put them in the Sprint backlog). This will make your estimation more reliable, your commitments easier to achieve (don't forget to leave some of your Sprint effort for addressing the unpredictable resource demand), and your code less likely to create production defects.
Network:1304



Shweta -

It's funny that you consider a 6+ year application as "old". I suppose that makes the ones I've worked with downright ancient :-)

In such circumstances, if you cannot replace the application in a reasonable time frame, then I'd suggest using research spikes as a means of quantifying how risky a given new feature will be given the legacy challenges the team is facing. That will make your sizing of those features more accurate over time.

I'd also suggest spending some team capacity (assuming your PO is supportive) in refactoring or fixing some of the more fragile code assuming there is a good automation test suite in place to highlight regressions.

Kiron
...
1 reply by Shweta Pai
Feb 14, 2019 7:54 AM
Shweta Pai
...
Kiron - Yeah, what makes me consider it as old is a couple of things. 1) The time spent on upgrades. Some of the supported libraries were obsolete and we have to spend time upgrading to just keep the current functionality afloat. 2) We are doing some tech sessions and spikes but when you actually start coding, we figure that there are more landmines. 3) With the app changing hands over the years, there are lots of bandaid fixes, making it more challenging.

Over the months, I have been in that team, I have had the team drop their velocity by almost 50% to at least get an handle on the backlog. They were drowning before. We started having the agile ceremonies properly and better refinement sessions. The developers started having spikes too. That has definitely helped but need to have better results.
Network:2275



Shweta, looks like good topic to learn more about the life cycle of the system development, I guess your concern about IT and the software.
Network:151



I think and If it is software package which is working perfectly fine and your team enhancing it for future needs. Try to find out teams understanding of complete package. Its technical aspects- Skills, coding style, Inter connectivity, Interfaces, DB etc. May be due to poor understanding above issues are happening.

Try to figure out Theme- Epic-Features-User stories. See if you further break down user stories so that they could complete it in a day. Small chunks will help you in better estimating. Reduce team velocity if require. Retrospect and ensure action items are addressed in next sprints
Network:50



Feb 12, 2019 5:46 PM
Replying to Kiron Bondale
...
Shweta -

It's funny that you consider a 6+ year application as "old". I suppose that makes the ones I've worked with downright ancient :-)

In such circumstances, if you cannot replace the application in a reasonable time frame, then I'd suggest using research spikes as a means of quantifying how risky a given new feature will be given the legacy challenges the team is facing. That will make your sizing of those features more accurate over time.

I'd also suggest spending some team capacity (assuming your PO is supportive) in refactoring or fixing some of the more fragile code assuming there is a good automation test suite in place to highlight regressions.

Kiron
Kiron - Yeah, what makes me consider it as old is a couple of things. 1) The time spent on upgrades. Some of the supported libraries were obsolete and we have to spend time upgrading to just keep the current functionality afloat. 2) We are doing some tech sessions and spikes but when you actually start coding, we figure that there are more landmines. 3) With the app changing hands over the years, there are lots of bandaid fixes, making it more challenging.

Over the months, I have been in that team, I have had the team drop their velocity by almost 50% to at least get an handle on the backlog. They were drowning before. We started having the agile ceremonies properly and better refinement sessions. The developers started having spikes too. That has definitely helped but need to have better results.

Please login or join to reply

Content ID:
ADVERTISEMENTS

A low voter turnout is an indication of fewer people going to the polls.

- Dan Quayle

ADVERTISEMENT

Sponsors