What do you do when you get X months into a project which is using Scrum and either a story, a developer, a review or planning session makes it clear that a serious architectural problem is evident, which was not evident at the start of the project? Ignoring why it is so, whose fault it is or the reason the current architecture was chosen.

  • Asking "who's fault" isn't a productive question. It's better to figure out how to effectively move forward now and how to avoid it in the future.
    – RubberDuck
    Aug 15 '17 at 22:11
  • 1
    I've already addressed this on another reply: I'm specifically saying to ignore whose fault it is, why it is so or the reason the architecture was chosen. That is literally the last sentence in the post.
    – Matt W
    Aug 15 '17 at 22:14

Currently, I'm not working in Agile or Scrum daily so this may sound naive but couldn't you try to turn the architecture issue into a story? Support teams, DBAs, and future dev team can be described as a "user" and can have viewpoints on usability, scalability, DR/BC, etc. and you can toss them into the same evaluation process as any other user story.

  • This is my feeling, too. I guess it depends on the severity as to whether the solution gets tossed or large-scale refactoring can take place incrementally. I forget where, but I read about building wrapper APIs around units of functionality in order to seal them off and allow a form of wholesale replacement to begin. This is, of course, part of what is involved with breaking down a monolithic solution into microservices. Fortunately, this space isn't completely alien to me as I've been involved in a project which did that before and it does work.
    – Matt W
    Aug 15 '17 at 7:51

Short Answer

This may seem like an obvious or overly simple answer, but usually the right answer is to address it as soon as you see it. Simply put, it is usually better to fix it now than build a bunch more features on top of a flawed architecture before fixing it.

Also be open to the idea that you may need to fix some parts immediately to stop additional work from making the problem worse while other parts may be less urgent. That may help it be a little less massive of a refactoring effort.

PBI's Not User Stories

Scrum does not demand user stories. The idea that every backlog item can be a user story is a nice academic exercise, but don't get hung up on it. Put in the needed product backlog items to course correct your architecture.

As for producing a valuable increment, if the architecture is truly problematic, there is user value. Maybe it deadlocks after 100 concurrent users or you get data mixed between sessions or, maybe the technical problem is all code-related and your ability to develop fixes and user-requested features in the future will be hindered. Either way, there is value in that increment.

Use Constraints

It is hard to come up with the perfect architecture from the beginning. Decades of software development has taught us this. Use architectural constraints to help keep your architecture "in bounds" and help alert you when you're drifting too far. Progressive web apps offer a great example of architectural constraints. Some of those rules include:

  • App must work offline
  • App must work on all browsers
  • App structure should load and fill in content

These loose rules let the team make better architectural decisions without having to set an architecture in stone at the start.

This, of course, won't completely prevent your situation, but when it does occur, one or more constraints can usually come out of it to bring things back on track.

  • "Scrum does not demand user stories." While I accept this (though the knee-jerk reaction is the opposite!) it does demand stories which are INVEST compatible - that each story is Valuable (as you also say.) This is often drilled in by agile trainers, leaders and scrum masters as the maxim to live by. This does make it hard to reconcile how very non-user-oriented work should be viewed or described when the story writers have been indoctrinated this way. aka: pm.stackexchange.com/questions/22214/cant-do-vertical
    – Matt W
    Aug 15 '17 at 8:21
  • 3
    In Bill Wake's original article on INVEST, he puts it really well. "Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important." So, why should the customer care about this architectural change? Because they may be the user whose account information is shown to another user. xp123.com/articles/invest-in-good-stories-and-smart-tasks I personally love user stories and use them almost exclusively, but people shouldn't get stuck on the format if they can express the value otherwise.
    – Daniel
    Aug 15 '17 at 8:40

In Scrum, like most agile approaches to development, the whole team is responsible.

This is the 11th principle of the Agile Manifesto:

The best architectures, requirements, and designs emerge from self-organizing teams.

So I must point out, it is very likely that the same issue would have revealed it self at a much later stage (time wise) in a BDUF approach. At least now, instead of blaming an individual, the team will own the issue, fix it, learn from it and move on.

  • While I completely agree with what you're saying - and thank you for your response - I don't think this answers the question; How should a problem like that be addressed?
    – Matt W
    Aug 13 '17 at 10:45
  • You asked whose fault it was, not how to address the problem :)? Nevertheless, I believe I did answer that question as too; i.e. " the team will own the issue, fix it, learn from it and move on". So yes, leave it to the development team to figure it out. If you want to avoid this from ever happening again, then nothing can guarantee that but I have found it helpful to have some experienced developers on my team who use and coach others to use good engineering practices. More evolved teams often have a mature "Definition of Done" for all the user stories, which embody the agreed upon practices.
    – Muhammad
    Aug 13 '17 at 11:15
  • Sorry, but you're wrong about what I asked... "What do you do when...", "Ignoring why it is so, whose fault it is or the reason the current architecture was chosen." I wouldn't ask whose fault it is. I do agree with the DoD and mentoring approaches very much.
    – Matt W
    Aug 13 '17 at 11:57
  • Fair enough, my bad :).
    – Muhammad
    Aug 13 '17 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.