Slowing down of an agile team as the development progresses

Question

Let's consider an agile software project.

In the beginning of a project each Story can be implemented quite quickly because the code base is small, there're few dependecies between different parts of code, we don't have to maintain backward compatibility etc.

But as the team moves forward the code base becomes larger, more complex - it requires more time to understand all the dependecies. We need to spend more time talking to other developers about the current architecture. A Story that used to be done during a few days, now becomes to require at lest a week.

Nearer to the end of the project fixing even a minor bug often becomes very difficult because the code base is huge, there are a lot of dependecies and restrictions (for example, backward compatibility).

So as the team progresses its velocity should slow down. The same Story in the beginning of the project may be estimated as 1 Story Point, but the this very Story taken into development at the end of the project may be estimated by the team as 10 Story Points or greater.

Agile manifest sates that an agile team should maintain a constant pace - is it really possible?

The team, of course, may begin to give more points to Stories to compensate for this complexity increasing, but that would mean that Story Point itself isn't a fixed unit of measure, and threrefore we can't use Story Points for forecasting the amount of time required to complete the project.

Answer 1

There are a few things to consider.

Regarding "constant pace", the Manifest for Agile Software Development says:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This does not say anything about the complexity of work increasing or decreasing over time. It also doesn't speak to the rate at which work items get done. What it says is that the level of effort that all of the stakeholders maintains should be sustainable for an indefinite period of time. This is to discourage activities that lead to burnout - long days, extra days, or other "crunch time" activities that cause physical and mental exhaustion, stress, negativity toward the work environment, or any of the other effects or symptoms of burnout. The idea is that you want to maintain a stable team for the long-term efforts, and "sustainable development" and "constant pace" is one thing that can help to promote this.

The increase in complexity of a system over time is normal, but there are ways to mitigate it. The first is to recognize the two types of complexities that may exist in the system - accidental and essential complexity. Some systems are simply complex - they come from the problem(s) being solved and are inherent. You may be able to isolate the complexity, but it exists. Accidental complexity is something that is introduced unnecessarily and can be fixed.

As a system grows and matures, it's important to not only add useful functionality, but deprecate and eventually remove functionality that no longer adds value. This is part of product management and needs to balance the cost of supporting and maintaining a given piece of functionality with the value that it adds to end users.

Technical debt is another factor. Minimizing reckless technical debt and paying down prudent technical debt can help to improve the ability to maintain the system. When you do decide to incur technical debt, also have a plan to pay it back. When you apply lessons learned, have robust test cases to support modifications (including refactoring), have appropriate documentation (including maintaining readable code), and ensure that you can think through the impact of design decisions, you can reduce the impact of the complexity.

Even if you do everything right, though, you're going to slow down. The best you can do is minimize how much you slow down.

Answer 2

Obviously a case of Flacid Scrum as defined by Martin Fowler.

There's a mess I've heard about with quite a few projects recently. It works out like this:

• They want to use an agile process, and pick Scrum
• They adopt the Scrum practices, and maybe even the principles
• After a while progress is slow because the code base is a mess

What's happened is that they haven't paid enough attention to the internal quality of their software. If you make that mistake you'll soon find your productivity dragged down because it's much harder to add new features than you'd like. You've taken on a crippling TechnicalDebt and your scrum has gone weak at the knees. (And if you've been in a real scrum, you'll know that's a Bad Thing.)

Solution is simple in theory :

If you're looking to introduce scrum, make sure you pay good attention to technical practices. We tend to apply many of those from Extreme Programming and they fit just fine. XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work. Sniping aside, the XP practices make a good starting point - and are certainly going to be much better than doing nothing at all.

In practice tho, XP practices take lots of skill and discipline. And adding XP practices to already existing project means you first need to pay down most of the technical debt. And my experience is that it might take years of focused effort to do that. So you need to take more long-term approach to it.