-3

We have a few developers who are slower than the typical agile expectation. They get fewer tickets completed in a given sprint. But on the upside, their work is more correct and higher quality.

Is this expected in an agile team, where you always get a few that is slower?

7
  • No, but if it works for your team, then that's OK. Agile is a general approach, not a set of rigid commands. Mar 11 at 21:17
  • 6
    Agile doesn't even figure into this equation. Any team, any development methodology, and you will find fast and slow developers. That's life. Mar 11 at 21:25
  • 3
    "In an agile team, is it helpful to have a majority of developers who are rushing out low-quality, bug-ridden code?"
    – jonrsharpe
    Mar 11 at 23:14
  • 1
    slower than ... expectation. So the expectation is not user happiness with working functionality?. True anacdote: Joe was the programmer that management told us to be like. He is the most productive on the team! I got to fix some of his code that failed acceptance testing. It took me two weeks. The difference? My fix worked, did not break existing code, did not hold up the release failing layers of testing, and got into production. The later any given bug is fixed (or prevented) the more expensive - studies and experience have proven this for many decades now.
    – radarbob
    Mar 11 at 23:33
  • 2
    And to add to what @radarbob posted, when you hear, "Joe is great! He's always fixing problems!" Eventually someone catches on and figures out, "Hey, Joe is always creating problems. That he then has to fix..." Don't be Joe - Joe ain't a rock star, Joe's just a rock. (As in, "As smart as...") Mar 11 at 23:54
8

This question is based on a false premise. An individual on a team is not "agile" or "not agile". Agility isn't about being fast in completing units of work, it refers to the ability of the team or organization to respond to changes in a highly uncertain or ambiguous environment.

On a team, different people do indeed work at different rates. There are lots of factors. It could be related to things like familiarity with the tools and technology, familiarity with the codebase, the ability to focus, the ability to get questions answered if things come up, and others. Without a good understanding of the team and the team's dynamics, I really can't get into specifics.

However, I will add that having "more correct and higher quality" work is usually faster. This is something that has been known for a long time and is at the heart of Lean methodologies. Building quality in from the beginning reduces the waste associated with downstream inspection and test activities. If you have people who are progressing work downstream with defects, they are probably getting less value-added work done than the people doing higher quality work the first time, in the long run.

1
  • progressing work downstream with defects, they are probably getting less value-added work done Amen, brothers and sisters! I've noticed that the later defects are found the earlier the defects were introduced. Consequently, production bug fixes tend to be hack jobs, getting hacky-er over time. If the now fatal flaws are not addressed ( Not! It's production! ) eventually maintenance can devolve to a bug-inducing-bug-fix, non-value added, feedback loop. The deepest cut of all was the customer head guy telling me: "we don't report bugs any more because we know they'll never get fixed."
    – radarbob
    Mar 12 at 0:55
3

We have a few developers who are slower than the typical agile expectation. They get fewer tickets completed in a given sprint.

That doesn't mean they aren't agile. No two people on a team will work at the same speed. In agile software development, "agile" refers to the whole team rather than individuals. Either the whole team is agile or it's not.

In fact, you could argue that every team needs some who are slower. They bring a different perspective. For example, they may complete fewer points because they write more tests, or work on harder problems, or who write more documentation, or any number of other reasons.

But on the upside, their work is more correct and higher quality.

Higher quality work? Why wouldn't you want as much of that as you could get?

Agile isn't about speed per se. It's a development model that attempts to make sure you're building the right product with the appropriate quality, in a sustainable manner, with course corrections early and often.

Is this expected in an agile team, where you always get a few that is slower?

Absolutely, yes.

1
  • 1
    "Agile isn't about speed per se." – Really, the only thing agile has to do with speed at all is that it requires fast feedback loops. Mar 12 at 1:00
2

Agile development is not a race. Finishing tickets is a rubbish measurement when these finished tickets then all get flagged up in QA or worse, lead to customer complaints. Same if rushed tickets lead to code that's a maintenance nightmare.

With your comment "They get fewer tickets completed in a given sprint. But on the upside, their work is more correct and higher quality." it seems that someone thinks that completing more tickets incorrectly and in lower quality is actually a good thing. It isn't.

To answer your question, agile development is not related to speed.

And if you don't want to end up with a codebase that will actively slow your team down, look for more quality in your development.

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.