-2

As SCRUM teams are self-organized they are free to choose how to implement tasks.

However, isn't there a risk that teams could end up deciding to do for instance full re-writes (instead of constant refactoring) every few years just because there is a new fancy framework out there that does things slightly more efficiently, ignoring the overall economic perspective?

If yes, how can this issue be dealt with in SCRUM?

  • 6
    This is people problem, not technical problem. If your developers feel rewrite is necessary, yet you feel they are just nice-to-have, but not necessary, then communication has failed somewhere. – Euphoric Aug 1 '18 at 7:49
  • If I understand you correctly, you maintain that refactoring is always more efficient than a complete rewrite. What makes you think that? – Giorgio Aug 1 '18 at 7:51
  • "that does things more efficiently, ignoring the economic perspective" You are contradicting yourself here. If things can be made more efficient, then that is perfectly reasonable economic perspective. – Euphoric Aug 1 '18 at 7:52
  • 4
    The question could be more concise. How about "Developers are an irresponsible lot who just want to fiddle around in a sneaky kind of way. How do we deal with that?" And than offer two options, to keep people from bringing up anything you have not though of yourself yet, to get them in the right mind set. – Martin Maat Aug 1 '18 at 8:23
  • @MartinMaat I hope you forgot your /s – Euphoric Aug 1 '18 at 10:02
7

The economical viewpoint is in principle on the shoulders of the Product Owner (PO), who is interested in maximising the value that is delivered, and is business savvy. He/she does so by proritizing the product backlog items.

The Development Team is committed to deliver working software and implement product backlog items negotiated in the sprint planning meetings. Whether this requires rewriting or refactoring is a technical decision that belongs to the team. There must be trust that the team is doing the best choice, and there can't be PO interference on technical decisions without the risk of breaking an efficient team dynamic.

Now, if the team would decide to rewrite major parts with the consequence of slowing down the delivery pipeline over a longer period, it would certainly not be for fancy reasons. It might be a necessary investment. However, as this would impact the burndown rate and thus the sprint planning over a longer period, this should be discussed and agreed with the PO by clarifying what's at stake, and giving predictability.

The controversial use of developer stories can help to keep visibity on such technical tasks, but these shall be used in the sprint backlog and shall not polute the product backlog, if they don't bring additional value to the users.

It could be also be that the adoption of a new framework could significantly improve (or even enable) existing user stories, in which case it would be something that matters to PO as well and would so indirectly appear in the product backlog.

Attention: the thought that DT could start turning wild and is not committed to the product delivery bears the risk of breaking a fundamental trust. This might undermine the effectiveness of the agile approach, and in the worst case evolve into a self-fulfilling prophecy (e.g. DT starts to hide these technical aspects to PO fearing misunderstanding, and the PO only observing an unexplainable measurable decrease in performance, creating doubt and suspicion, which decreases DT motivation and increase turnover, etc.).

6

This is silly. For every time a team went and re-wrote everything every few years, there's literally hundreds of teams who are stuck in some God awful mess because product owners demand features over paying down technical debt.

How can this problem be solved?

As with all things, process cannot solve people problems. And people problems are rarely ever solved...

In the end, your technical stakeholders and business stakeholders need to actually work together to find a suitable balance to provide the most value to the customer short term and long term.

But practically - you don't, because it's not a problem. The overwhelmingly more common problem is the team that needs to do a rewrite, but feel as though they can't.

5

In practice this just isn't true. The Scrum team, can't write backlog items and a rewrite would generally affect much more than the scope of a single task.

Secondly, Tasks must be estimated. This gives the Product Owner visibility of the economic impact of tasks. If the cost of the feature is too high, then it won't be put in the sprint.

Thirdly, Everyday the team has a standup which the Product Owner can attend and listen in on. Everyone would soon become aware of the rewrite and question it.

Having said all that, CV driven development is a thing. Product Owners should be aware of alternate approaches to deliver features and Team Members motivation (ie bonuses) should be aligned with their employers goals

3

Scrum requires trust. You should trust that your developers are doing the right thing.

I'm a developer and have been a team lead a few times. From my perspective, you have three options when maintaining a codebase:

  1. Pay down technical debt over time
  2. Pay a lump sum by rewriting components (or the whole application) periodically
  3. Not pay the debt, and suffer the consequences of a legacy codebase that can't be maintained

Not paying down technical debt is the fastest way to lose good developers. No one wants to spend six hours reading logic to make a one-line change. It's a waste of everyone's time.

Using the latest frameworks is not just about CV building or getting fancy new features. You are also renewing the window of vendor and community support for the frameworks and tools you use.

Personally, I believe that rewrites are better business decisions because you are consolidating the work over a shorter period of time, and it requires fewer rounds of regression testing.

Given the nature of Scrum, it may appear that simple tasks are estimated far higher than necessary, but this is going to happen when the development team is addressing technical debt. You should get used to it.

Scrum works best when the parties trust each other. You can't ask the development team to build the product and then question the manner in which they build it. Non-developers often don't realize how quickly a codebase turns into a mess during a frenzy of feature enhancements.

  • 1
    "Scrum requires trust. You should trust that your developers are doing the right thing.": Any working environment requires trust. – Giorgio Aug 7 '18 at 8:25
0

Needless to say this shouldn't happen. Stories for sprints should be groomed and selected for an upcoming sprint with the help of the PO. If the story isn't of sufficiently high priority, it wouldn't even make it into the sprint to start with.

This is all assuming a story would even be considered rather than being rejected out of hand. It would be hard to craft a As a... I want... so that... story framed from the user's point of view when there is zero benefit other than the developer getting a warm feeling as they're using bleeding edge technology they can put on their CV.

Ultimately, you have a failure of process here.

  • 1
    Example formulation (it depends on the specific case, of course): "As a... I want this library (on which my product is based) to be upgraded to the newest version so that in one year's time I will still get bug fixes." – Giorgio Aug 1 '18 at 10:07
  • @Giorgio The OP specifically mentioned a new framework rather than an update. Even then, it isn't uncommon to simply stick with a version (even an out of support one) as it is a known quantity and to do so would avoid substantial regression testing. – Robbie Dee Aug 1 '18 at 10:08
  • As I said, it depends on the situation. My point is that a technology upgrade can have a use for the customer and, in that case, you can write user stories for it. – Giorgio Aug 1 '18 at 10:24
  • @Giorgio Of course, but only if the user has a requirement that can be satisfied by a new framework. Customers rarely care what framework is used as long as it does the job. – Robbie Dee Aug 1 '18 at 10:29

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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