Anti patterns that leads to Development team not delivering value

A lot of times, I work with organisations who claim to be agile. However, there is a difference between the ‘being’ and the ‘doing’. Scrum, obvious, is not a silver bullet and doesn’t solve the problem instead, exposes it. I have work with a variety of organisations in my career, and one thing seems to keep recurring, Development team often don’t have the opportunity to be trained in scrum.

Below are some key indications, from my experience, of a scrum team which isn’t delivering value to customers:

  • Tech/ Dev lead is responsible for assigning tasks/work items to the teams. The Team waits for the Tech Lead before pulling work from the sprint backlog.
  • Breaking down of user stories is discouraged by the Tech Lead. “We don’t need to break stories down. It is a waste of time, and we can spend that time coding”. It is okay not to break down a story, if small. However, a story that takes the whole of the sprint to complete needs to be split and/or broken down into smaller chunks.
  • Tech Lead: “How about limiting the time developers spend delivering one line of status update? They could give their updates to  me, and I then attend the daily scrum that way, developers can spend more time coding.”  
  • The Tech lead is the only one that does code review and/ or peers review, but at the moment, he has other meetings to attend, and he will prioritise the code review later or when it gets round to it.
  • An average use story spends 4-6 weeks in progress- travelling from one sprint to the next and eventually returning to the product backlog because of missing requirements. This often leads to the Team experiencing challenges to work as a team.
  • Increase in defect rate happens as a result of the above. Also, Developers and the Testers goals for the sprint aren’t aligned; developers seem to believe that they are “done” when coding ends and not when the work item is tested. Definition of Done is not  adhered to
  • Developers are assigned stories to work on during the sprint, but they are quick to drop work items or spend the whole of the sprint working on it when they feel it is complicated to work on instead of pairing with another individual to unravel the story. 
  • Code review takes an average of two days to complete why? Amongst other factors, this happens because of back and forth messages and also Tech Lead only approve it.
  • Metrics are not taken seriously or encouraged by the management.
  • Development Lead act the spokesperson for the Developers; however, they don’t feel responsible for the QAs. 
  • Sense of urgency (Lack of): Product owner assures the Team that it is okay not to finish the sprint,  it is also okay to swap stories from the product backlog around. 
  • No timeline for dependencies to be completed- these dependencies are the results of component teams building the product. There are pros and cons to components team structure.
  • The Sprint Retrospective is seen as a waste of time by the Team because they could have spent that time finishing their work. Yet the Team fails to inspect and adapt, and they often complain about the same thing that keeps coming up at every sprint retrospective.

 

2 Comments

  1. Nasima Shafiul June 4, 2020 at 4:14 pm

    Nice write up, Kemmy!

    Reply
    1. Kemmy Raji July 2, 2020 at 2:24 pm

      Thanks! Nasmima

      Reply

Leave A Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.