1

The team I am working on is trying to do agile development with 2 week sprints. I think we must be doing something wrong however, as we have to work like madmen to get the features implemented in the 2 weeks, leaving barely a few hours at the end for a quick QA cycle and no time for documentation or writing unit tests and definitely no time to ever refactor anything.

When should documentation etc. be done if one where to practice agile as it was originally envisioned?

Needless to say the way we are doing it now, many bugs escape into the field, and then people have to be yanked off their sprint task to work on hotfixes, which adds to the stress.

Note this is different to another question posted on this site (the "QA takes 12 weeks" question), as in our case the QA process is quite short and does not hold up the process as such, it just gets squeezed into the end.

fred basset
  • 121
  • 5
  • 11
    You *are* doing it wrong - you are putting too much in each sprint. You should allow enough time in each sprint to do unit-testing, refactoring etc. Or rather, the estimate for each feature should include testing, refactoring and documenting time. Moreover, refactoring and unit-testing are continuous activities, not something to be left at the end of the *day*, much less the end of a sprint. Otherwise, you are just doing a classic waterfall – Panagiotis Kanavos Sep 11 '15 at 15:04
  • 2
    related (possibly a duplicate): [Should we quit trying to do agile if QA takes 12 weeks?](http://programmers.stackexchange.com/q/96520/31260) – gnat Sep 11 '15 at 15:10
  • That is a good comment. I will bring it up with management, but there is always a huge amount of pressure to constantly turn out new features as quickly as possible. – fred basset Sep 11 '15 at 15:14
  • 3
    BTW who estimates the tasks in a sprint? If it's management, you aren't doing agile at all. If it's the developers, you are underestimating. – Panagiotis Kanavos Sep 11 '15 at 15:49
  • Sometimes management advises how many "points" a story is to be, other times it's us devs. Unfortunately there is pressure to give the shortest estimates possible. – fred basset Sep 11 '15 at 16:29
  • 1
    If you do not have any time to write unit tests or refactoring *at the end*, did you consider to write them *at the start and in the middle* of a sprint? For example, for the unit tests, try a more TDD like approach. Independently from this, refactor the pieces of code where you are going to add a new feature **before adding that feature**. – Doc Brown Sep 12 '15 at 05:03
  • Oh boy... "sometimes management advises on how many points a story is to be..." No. No. No. That has to stop if mgmt really wants you to be agile, let alone Agile. – RubberDuck Sep 13 '15 at 01:05

2 Answers2

10

There are a few approaches that you can take.

It seems like the ultimate problem that I'd want to address the "work like madmen" part. You should be striving for a sustainable pace, that is a level of effort that you can sustain indefinitely. The idea that you need to "work like madmen", yet aren't able to produce a quality product seems to be an issue.

How do you create a sustainable pace?

From a process perspective, take a look at your team organization. It seems like quality assurance is happening at the end. Consider the idea of a cross-functional team that works together. Don't put quality at the end, but involve quality at every step of the way. You may want to leverage continuous integration to help achieve this - if you have dedicated testers, regularly (nightly?) put changes into their hands and get feedback. Use automated tests to make sure that what they have is close to being correct, at least based on the developers interpretations of the expected results. If they find issues, update your automated tests to help prevent them from recurring.

From a team perspective, take a look at your sprint length. The length is almost always presented as 1-4 weeks. 2 weeks is on the shorter end of the spectrum. Maybe you'll be better off with longer sprints - adding an extra week or two.

From an estimation perspective, consider your definition of done. When is a story done? When it's implemented and unit tested? When it's integrated? When it's been integrated and passed acceptance criteria? It sounds like you need a solid definition of done and estimate the story points against the complete effort. That complete effort should likely include refactoring, unit testing, integration testing, and the acceptance testing effort. Make the whole team part of the effort.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • Thanks Thomas very good comments. I will try to discuss what we are using for our definition of done. I am pretty sure all it means at the moment is there is some code that has had some testing. Definitely no unit testing or documentation at the moment. I tried suggesting a 3 week sprint, but the managers recoiled in shock at that suggestion, thinking it would slow things down too much. A major problem is that virtually no-one else on the team sees any value in unit testing or documentation, so not sure what to do about that either. – fred basset Sep 11 '15 at 16:40
  • 2
    @fredbasset Does anyone else on the team see value in not having bugs? Because right now, they have no idea whether they have bugs or not. – Ross Patterson Sep 12 '15 at 03:46
6

The first thing to do is to recognise that your current approach isn't working. The amount of tasks being allocated to each sprint is causing you to have to cut corners and incur technical debt (eg bugs being released to customers). That technical debt then has to be repaid in subsequent sprints, slowing up future development.

You clearly have recognised that you have a problem. Your next task therefore is to explain this problem to management. They are expecting more than can be delivered and they are hurting the company as a result. Communicate this to them.

Finally you need a solution. That solution is to redefine when a task is done. Each task needs time for refactoring, unit testing, "QA" testing and documentation. Therefore agree with the team and management that all these activities must be carried out before a task is done. Then adjust your task estimates to allow for these activities. This will mean less tasks are scheduled in a sprint. Either accept (as an organisation) that less can be achieved in two weeks, or increase your sprint duration.

David Arno
  • 38,972
  • 9
  • 88
  • 121