A Dysfunctional Scrum Retrospective

One of my previous workplaces claimed to practice Scrum and hired me to be their Scrum Master.  However, what they had was not Scrum at all!  This resulted in massive technical debt, a demotivated team and tons of undone work each and every sprint.   My role as Scrum Master was highly ineffectual and I resigned within two months.  The person they hired to replace me (another certified Scrum Master) fared no better – he resigned within two months as well.

I’m writing this retrospective to improve my skills, to learn and to become a better manager.

Scrum Master

I joined as Technical Lead & Scrum Master around Sprints 49-50 (two week Sprints).  I assume that the Scrum Master role was previously held by the CTO.

Product Owner

There were actually two Product Managers, one senior and one regular.  I considered the “regular” Product Manager to be the “actual” Scrum Product Owner because he worked the most with the Product Backlog (stored in Jira).  This Product Owner joined about two weeks before I did.  He was actually trying his best, but like me, ran into insurmountable organizational impediments.

The Senior Product Manager was with the company for much longer and had a better understanding of the product, market, internal processes and people. The Product Owner role was split between two people which is not supposed to happen.

Development Team

To my great surprise, the development team was fantastic.  The team size was above the recommended 9 (7 developers, 2 QA, 2 UI/UX).  It was cross functional and people were easy to speak to, get along with and eager to help one another (except for one developer).  The development team was co-located, which is good.

Sprint Planning

The good:

  • PO stressed that the development team provide estimates for everything.  No one was providing estimates until myself and a new Product Owner joined

The bad:

  • No development team members participated
  • The Sprint Planning was not held at the beginning of the Sprint
  • Sprint planning was done by the CTO on his own schedule where he had a spreadsheet listing the tasks to be done.  Then there would be a discussion between the CTO and PO where the CTO would explain (oftentimes very poorly) what the tasks meant
  • The Product Owner then translated the spreadsheet into the Product backlog tool (Jira)
  • No Sprint Goal was formed.  It was only an exercise in creating Product backlog items
  • Priority of the backlog items was set by the CTO – The PO held no power over his own backlog!

 

Daily Scrum

The good:

  • Consistent time and place

The bad:

  • The Daily Scrum was run by the CTO – he should not even be a part of the Daily Scrums
  • It was clear after a few Daily Scrums that the purpose was to report status of work to the CTO.  Each member of the team went one by one to tell the CTO what had been done the previous day and what they intended to do that day.  The main purpose of the Daily Scrum was twisted.
  • The number of participants (15) was well beyond the recommended Development team size of 3-9. The Product Owners (2), Scrum Master and some other staff who reported to the CTO, but were not on the development team were also expected to participate in the Daily Scrum to give status updates
  • Daily Scrums would frequently run over 15 minute time-box in due to the excessive number of participants.

Sprint Review

  • Did not occur

Sprint Retrospective

  • Happened once
  • No changes were added into the backlog afterwards

Sprint Duration

Sprint backlog items selected by Product Owner (under the direction of the CTO)

Sprint work could be inserted by the CEO and CTO

Cancelling a Sprint happened

Poker planning happened once to provide estimations to tasks.

No explicit Definition of Done (and no test cases or automated one)

 

What else went wrong? right?