Bug or new feature? How agile development teams avoid being overwhelmed by their customers

Door Patrick Verheij

Imagine this fascinating scenario:\r\n\r\nA software development team explains that they feel overwhelmed by an endless stream of bug reports coming from different customers. The repair work never seems to end because every fix seems to introduce new requests. The team members complain about this “drudge work” and are eager to innovate instead. Alas, the repair work keeps coming in leaving no time for even reflection on how to escape this unwanted situation.\r\n\r\nThank you for explaining your situation to me, dear team. Thanks also for asking me to help you reflect on this situation. It is awesome that you actually took some time for that. A great step forward already!\r\n\r\nWhile working with this team, I soon found out that their software product has been live and available for quite a while and is being used by different customers. I also found out that the software product is quite complex, meaning that the customer can use it in such ways that sometimes even the developers are like “okaaaay, that’s interesting but not how we intended it to work!”\r\n\r\nNot surprisingly, the complexity (or is it ambiguity?) of the software product causes a steady stream of customer requests towards the development team.\r\n\r\nNow here’s the interesting part: I quickly found out that the team doesn’t really distinguish between bugs and new features.\r\n\r\nThey appear to see every request that comes in as a bug report meaning “something which has to be fixed as soon as possible”.\r\n\r\nWhen looking at the complexity of the product, it isn’t really that strange that the team doesn’t really distinguishing between bugs and new features because it appears to be quite difficult to do so! Alas, it is not a winning strategy to continue like this because of several reasons:\r\n

    \r\n

  • The team feels stressed out by the ever incoming stream of requests
  • \r\n

  • The customers don’t feel the product really moves forward
  • \r\n

  • The team doesn’t feel they move the product forward
  • \r\n

  • The team is afraid the overall quality of the product is declining
  • \r\n

  • The product moves forward, but not necessarily in a direction which is beneficial for the business needs behind it, both for the customers AND for the company supplying the product
  • \r\n

\r\nOops! This team just found out that the have a potential business risk. Time for some mitigation, errr…contingency!\r\n\r\nNow let’s look at the symptoms, which surfaced after some digging:\r\n

    \r\n

  • A lot of the stress among the development team members appears to be caused by a business owner who presses for innovation without properly addressing or even recognizing the potential business risk mentioned above.
  • \r\n

  • There are no agreements between customers and developers about how to distinguish bugs from new features let alone about how to deal with the difference.
  • \r\n

  • The SLA (Service Level Agreement) doesn’t distinguish between these either.
  • \r\n

  • Acceptance testing apparently doesn’t raise any questions about the nature of the test findings and possible consequences for maintaining live software.
  • \r\n

  • Developers and end users do not collaborate regularly during development.
  • \r\n

  • The time between a software release and the first incident report coming from a customer is quite long (weeks or even months).
  • \r\n

  • The developers spend a lot of effort testing, using and improving their own software but still the customers find many other things than they do.
  • \r\n

  • Work is often left unfinished because the team regularly shifts their focus to other priorities. This adds significantly to the stress level of the team.
  • \r\n

  • Analyzing bugs is difficult because of lack of documentation. Knowledge about the software product mainly lives in the heads of the developers. If one or two developers quit, the team AND the whole company have a major issue.
  • \r\n

  • There is no significant dialog about the validity of the team’s results and future plans during Sprint Reviews. Sprint Reviews are not much more than show cases about what a new increment adds to the previous installment of the software.
  • \r\n

  • Same for the Sprint Retrospectives. The team talks about symptoms, but appears to be incapable of doing more than “scratching the surface” over and over again. The Product Owner is not attending Sprint Retrospectives regularly.
  • \r\n

\r\nEven more worrying is the fact that the team doesn’t know if they can actually slow down a bit to do more serious reflection and create a better development strategy. The business case behind the software product isn’t really know to the team.\r\n\r\nOf course you have recognized the paradox by now: this team actually HAS to slow down and create a better strategy to stand a chance of turning the tide. They need to evaluate the existing development strategy and make sure all stakeholders involved understand it, including the development team. Then they can start a meaningful dialog about that strategy and improve it bit by bit while executing it.\r\n\r\nFrom an agile point of view, this team can do several more things to turn the tide:\r\n

    \r\n

  1. First of all, start doing proper Sprint Reviews and evaluate the Sprint results more decently. Of course with the proper stakeholders being present. Raise the question if the results are according to plan and if the business case is still valid. If initially it appears that there is no proper plan or business case, then there’s the opportunity to create one. Also be clear about things that were planned but not finished and about impediments that surfaced during the Sprint (the team is using Scrum, if that wasn’t clear yet).
  2. \r\n

  3. Learn to distinguish between real bugs and feature requests by analyzing the incoming requests and discussing these with the end user. Then agree on which ones to address immediately and which one to postpone or even ignore. The team can start doing this already during the next acceptance testing.
  4. \r\n

  5. To have more grip on incoming requests, the development team should find a way to work more closely with their customers. Perhaps they can start with one particular important customer and gradually involve others.
  6. \r\n

  7. Finish the work you start, dear team. Agree on when and how to shift to new priorities. When it happens, keep track of the unfinished work and agree on how much of that is acceptable.
  8. \r\n

  9. Start writing proper maintenance documentation. Learn what you need to document as a minimum and be ready to explain exactly why you do that. Also learn what is the most convenient document format for the purpose.
  10. \r\n

  11. Improve team Retrospectives. Find out if and exactly how the team is improving. Be specific. Find impediments and priorities for improvement. Make sure the team members properly discuss whatever needs to be discussed and learn to ask powerful questions. Improving their ability to recognize process flaws and their skill to address these should be a priority.
  12. \r\n

\r\nForemost, this team and any team should learn how to properly assess the situation they are in. From any perspective. And if they can’t or suspect they can’t, they should know when to ask for help and to whom to turn. That’s also part of a team’s strategy.\r\n\r\nI hope this article also clearly shows that any software development team needs to have at least some business insight to function properly. This team in particular needs to review their business case and business strategy regarding the involvement of their customers.\r\n\r\n—\r\n\r\nIf you liked reading this case, perhaps you will enjoy my other ramblings.

Patrick Verheij

06 59 443 447

Andere posts

Klik hier