15

In an ideal Agile world, you quickly build a small, but useful subset of the desired end system, and give it to users. They're excited, because it's useful, they start using it and give feedback. You then work out what to add on to it, build that, and repeat until you run out of time.

I've had a couple of projects recently that involved replacing some kind of working system. The above model just didn't work at all: until you'd built a system that included virtually all the functionality of the existing system, users had no interest at all. They wouldn't use it.

How do you apply Agile when "the smallest useful subset" is "all of it"?

Steve Bennett
  • 3,419
  • 4
  • 20
  • 24
  • 3
    I have a question, is this new system a direct mirror of an existing feature set, and if so why are you changing it? –  May 02 '12 at 14:58
  • Users can show an interest or never get the new functionality. It's their choice, but in some business settings they may have supervisors who think otherwise. – JeffO May 02 '12 at 17:17

7 Answers7

14

The agile solution might be not to replace all in one go, but to phase the replacement in gradually.

Introduce the new system gradually, bit by bit, keeping parts of the old system running. The old system isn't switched off all in one go, it just fades away. The new parts provide new functionality or other benefits, so the users are delighted to use them. This is also less risky, as you have a 100% working system at all times.

MarkJ
  • 2,827
  • 1
  • 18
  • 18
  • 2
    +1 didn't even see your answer here before I said practically the same thing. Great minds and all ;) – Michael Brown May 02 '12 at 12:59
  • +1 for demonstrating that Agile may not be an ideal approach for certain kinds of real-life implementations. – pap May 02 '12 at 14:25
  • @pap Yes, *agile* (TM) has been hyped so hard there's a danger of blindly using one fixed methodology, without thinking about your own specific situation. – MarkJ May 02 '12 at 18:46
  • Keeping parts of the old system running implies spending development effort on integrating with the old system, right? – Steve Bennett May 03 '12 at 00:19
  • 1
    @SteveBennett: Yes, it does. That, of course, is a tradeoff. But the payoff is greatly reduced risk, and you only need to redo the part that needs redoing. – sleske May 03 '12 at 00:50
  • This is our approach. The problem with agile in our scenario is the legacy code is an inherited mess. It is impossible to size story complexity accurately when they heavily involve legacy. It is easy for the team to fail the sprint because of it. We're trying to determine how to deal with this in scrum. – kenchilada Feb 16 '17 at 15:47
6

Rather than re-writing the existing system (which as you mentioned will take quite some effort before the new system matches the existing functionality), consider the strangling vine approach. Basically, you implement new functionality using your new approach on top of the existing application. Eventually, as you address shortcomings of the old system to address new functionality, the new code will fully replace the old.

This requires more precision and effort than a "reboot" of the old app. But you get a shorter time to ROI. Also, going through the process, you can put hooks in place to enable the "new" system to be more easily strangled by the next "new" system.

Michael Brown
  • 21,684
  • 3
  • 46
  • 83
5

Releasing small increments into the world might work for greenfield projects but even then the small number of features might not be too useful.

Scrum advocates that after each sprint that the product is "Potentially Shippable". It does not have to be shipped but has to have the quality of a shippable product.

If you do want to give users an incremental version of the app then you can clasify it as Alpha then Beta then Release Candidate versions while still having the real Production app still being used.

You might find that new features get added and old ones get dropped if you are incorporating feedback from the users.

aqwert
  • 499
  • 2
  • 6
  • 1
    +1 that is exactly how we approached it. Although the whole idea of 'starting over' is very unagile. How hard have you tried considering to substitute the old solution bit by bit? – Kris Van Bael May 02 '12 at 06:01
  • @KrisVanBael that's theoretically better (and definitely an ideal) but it's another of those "it depends" questions - some old solutions are *really* old (so one is looking at platform changes) or the process is wired/integrated into the system end to end and the "bits" can be rather large. – Murph May 02 '12 at 08:19
  • I was working somewhere where the orginal was shipped to market very quickly and therefore the design was pretty bad. We had the idea of starting over with a better idea of what to do and hopefully better code. It never went ahead which was for the best cause the cost to benefit was not viable. If the existing system works then make small improvements to it overtime. – aqwert May 02 '12 at 21:02
3

I worked on a massive line of business application replacement for a major national cable tv network. The new system development was done with SCRUM, it was about a 18-24 month development project to re-implement almost all the major sub-systems; which were approaching 10 years old.

There was a planning phase of like 6 months before the development started, but it was approached as SCRUM as well. This is where the product owner wrote high level stores and epics after existing system analysis and interviewing the customers.

The existing system was extremely stable as went into critical maintenance mode; only show stopper issues were fixed, everything just logged for historical purposes and to make sure the same issues didn't appear in the new system.

The new system evolved as described in an Agile process, it was extremely smooth for the most part. When the replacement system reached feature partity, it didn't go into production, but into parallel production trials. A sub-set of non-critical workers started using both systems, to validate that the new system behaved like the old one; with the old bugs fixed of course.

When the new system achieved almost 100% new features complete it was rolled out for general parallel production runs, which lasted a couple of months.

Once it was deemed by the customer to meet their needs, the old system was backed up, switched off and sat. I assume they have re-purposed the old system hardware because they never needed to revert to the old system after cut over.

2

I still think agile adds a lot of value in this scenario.

It's just that you have a very defined end goal of 'replace the current system.'

Agile techniques and processes can still get you there more effectively.

For instance:

You can still deliver on the system iteratively and in small sprints.

You can still use agile techniques to prioritise the work after communicating with the key people.

You can still use agile to plan based on observed velocity.

You can still use agile techniques and philosophies such as spreading knowledge, TDD, clean coding to enhance the quality and internal design of the project.

If you have people who are genuinely 'not interested' in the project and not engaging with the project until they have a perfect replacement, you have a bigger problem regardless of whether you are using waterfall, agile, or indeed any process.

1

It works the same, but this approach will be harder to sell to existing users. They may not want the new system and they don't want to be interupted with periodic testing. They want to wait as long as possible and then just test it in the end. Most users feel this way to a certain extent, but it's up to those in charge to educate them. In their mind, you're working with an existing application, so you should know what it's suppose to do, why bother them?

Make them understand that you don't want to do it this way because you think it will be fun and you get lonely using a waterfall process. It will make a better app in the long run.

A key selling point may be to implement that one change during the building of the new app they've always wanted, but could never get in the old system.

JeffO
  • 36,816
  • 2
  • 57
  • 124
0

If I have an old rusted out car that I need to drive to get to work, and I go to the dealership to purchase a new car. The model that I want is out of stock so they have to order it from the factory and it will be a little while before it comes in.

The dealer then out of good faith decides to give you the cars engine block until the car you ordered has come in. What are you supposed to do with a car engine? Sure I can hook up some components to test it and make it works, but it really doesn't help get me to work tomorrow where the old rusted out car does.

Granted there is a far cry different between building a car and building custom software, but let's ignore that for the sake of argument. The point of the story is not to be perplexed that the client finds no use for incremental changes when they already have software that is good enough to get the job done now. It already fills their need for the time being.

That isn't to say that Agile is not an important part of the process here because it does allow for continuous feedback to the client on the status of the project. They can ensure that progress is being made before major milestones and deliverables. They can identify potential problems and issues earlier before it becomes too costly a mistake to fix.

Maybe as the car customer you just want to look at and evaluate the engine to make sure that you are indeed going to get what you anticipated. Oops, I actually wanted a 6 cylinder engine instead of the 4 cylinder engine! Didn't I tell you that earlier? No problem, lets put a change into the factory order.

Sell the idea to the clients that it is in their best interest to use the new software releases not as a replacement just yet but to evaluate it and make sure that they are happy with each step along the way.

Matthew Flynn
  • 13,345
  • 2
  • 38
  • 57
maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • Yeah, but my experience has so far been, to follow the metaphor, that car customers don't know anything about engines, and can't tell you anything useful from looking at one. When they're in hypothetical mode, the feedback is pretty superficial "oh, that looks like it would do what we want" and you don't get much until they actually use it for the first time to solve a real problem. – Steve Bennett May 03 '12 at 09:48