How do I deal with a problem that will pop up in a later iteration

Question

This is an Agile development project and I do not have the ability to change that.

The design that will be the fastest and most obvious for the first phase of our project will not be compatible with the needs of our second phase. The change would not be difficult to implement now but it would take a little more time to implement.

Our PM is pushing for the quick phase 1 approach saying we will deal with the problem in phase 3 when we get there. Making the change at phase 3 will require refactoring and data transformation will be very intensive. Is there anything I can or should do now that fits in the agile methodology?

Answer 1

If you are truly doing agile, then your team should be fully empowered as to the implementation details and your PM shouldn't have a say in it.

On one hand, agile is all about delivering some value quickly, rather than waiting until every wanted feature is perfectly in place. This occasionally means reducing short term effort at the expense of additional long term work. That is one of the hardest habits to break. I know it has been for our team.

On the other hand, it is a myth that being agile requires foregoing all long term planning. It's perfectly fine, even encouraged, to think about "phase 3," as long as you recognize that business priorities may change to never implement it. That means if two weeks of extra work now could prevent two weeks of extra work in phase 3, no question you do it in phase 3. If one week of extra work now prevents two months of work in phase 3, there's little question about doing it now.

Between those extremes, your team must use their best judgement, but I would lean toward postponing the work when you could go either way. The reason is that by the time you get to phase 3, you will know a lot more about what you need. Perhaps you will need a large refactor anyway to incorporate some feature you haven't even thought about today, and all your work now is essentially wasted.

Answer 2

You're practicing Scrumerfall. The reference to phases, PM's, etc... leads me to believe that the team has embraced Agile where it feels like it fits, versus changing previous notions and conceptions on how the process works.

In either case, do what you need to do to complete the backlog item. You're theorizing that priorities wont shift in N months. This is one of the concrete concepts of Agile; delivering value in an iterative manner with the possibility to shift direction at a given point in time.

You can and should certainly take a smart approach to your code base, keeping it modular, loose coupling, etc... to aid in the re-factoring effort but the re-factoring effort is something that should exist throughout the process. It's ongoing. It's iterative. It's about making things better. Don't concern yourself with theorizing done, look at the backlog item and allow it to define done.

You can't always build Rome in a day but you can certainly lay the foundation for the future.

Answer 3

I can understand this sentiment where you know a great deal of refactoring will need to happen in a later iteration based on the user stories of the current iteration. It is a tough feeling and it drives me nuts sometimes too.

I would generally take a bigger picture of the situation. If it is not a great deal of work extra in the later sprint then by all means do what you need to do to deliver exactly what is planned for the current iteration. You can plan accordingly for the refactoring effort later.

If it will likely be an extraordinary amount of work later then I will start asking around about how important this particular sprint is to the stakeholders. Customers and other stakeholders sometimes don't necessarily care about every single sprint. Believe it or not Agile methodology tends to be a political pursuit in MANY organizations making sprints a shallow artificial deadline, Eg. Wanting to attract clients and good talent with buzz words like Agile.

If the stakeholders don't have a vested interest in the current sprint then it may be possible to convince them of reprioritizing some of the user stories to where it makes more sense. I highly urge against extending sprints if possible though. That sets a dangerous precedent.