Case Study: Scrum Followed Properly Versus Not

Note: My following article Case Study: Scrum Followed Properly Versus Not is originally published in Scrum Alliance 

Case Study: Scrum Followed Properly Versus Not

It is not the methodology or the tool that fails to deliver quality software but it is the people involved. I strongly believe in the opening statement and here am sharing a case study of when Scrum was followed properly versus when it was not followed properly. Before that let me share the essence of Scrum as documented in the 'Do Better Scrum', which is

Majority of the teams have a common knowledge on Scrum including the basics such as

but more often than not the essence of Scrum is overlooked by the teams, which fail to follow Scrum properly.

This case study is about two Engineering teams,  ‘Team A’ and ‘Team B’, both following Scrum but one team missing practicing the very essence of Scrum while the other team practicing it to the core. 

‘Team A’ believed it was delivering software using Scrum by having The Team, Scrum Master and a Product Owner. Team was having Scrum Artifacts including Product Backlog, Sprint Backlog and Scrum Ceremonies including Sprint Planning, Daily Scrum and a Sprint Cycle of 4 weeks. But still the team was struggling to deliver software incrementally, which was shippable and could be rolled out to production. To its advantage, ‘Team A’ was also collocated including having an onsite Product Owner and most of its stakeholders. But still results were not there in the form of regular delivery of most valuable features in production and more importantly, not very happy stakeholders. 

Project was then handed out to a virtual team, ‘Team B’. ‘Team B’ not only practices core Scrum principles but also believes in the essence of Scrum. ‘Team B’ being virtual could not have Daily Scrums because of time constraints but using collaboration tools, was able to effectively and efficiently share what they worked on previous working day, what was their plan for next working day and if there are any impediments. Team was able to communicate robustly with the Product Owner through collaboration tools on user stories, acceptance criteria, design of the new features and agree upon definition of done. ‘Team B’ did have weekly calls with stakeholders to sync up on the status of the sprint. Team was disciplined in defining their Sprint Release Cycle including defining the milestones like Sprint Planning Meeting, Code Freeze, Functional Testing, Integration Testing, Sprint Reviews, Stakeholder Sign off and Sprint Retrospectives, associated with their respective dates.

By sharing a transparent sprint release plan with dates & milestones and following the same meticulously, ‘Team B’ demonstrated following the essence of Scrum. As a result, ‘Team B’ not only delivered the project on schedule and with quality but also was able to refactor the code written by ‘Team A’, getting rid of most of the technical debt. 

So lets analyze a little more on what was the difference between both the teams. ‘Team A’ was less disciplined in ensuring visibility into the team’s progress and honestly communicating about progress and risks. Team struggled to organize itself around the work and failed in delivering the most valuable features regularly. As a result, ‘Team A’ was not able to receive valuable feedback from stakeholders and with no way to retrospect on its work, the team set itself up for failure. It was not a case of team not working hard enough but more a case of failure on its part to properly plan, set expectations and delivery frequently. As the team was committing itself for a 4 weeks sprint cycle, development team allowed itself some short term code wins by providing the features without paying attention to long term goals of insuring scalability, reliability, availability and maintainability of the feature. The QA team was brought in late into the sprint cycles and thus losing the advantage of having second opinion on the requirements early to find any gaps. By the time QA team found any requirements gap, development team would have moved ahead into middle of next sprint cycle.  Team also missed setting expectations with stakeholders on the timelines of signing off on the sprint items, thus not allowing them to provide timely feedbacks and missing the opportunity to improve on the delivered features.

In contrast, ‘Team B’ though virtual, was disciplined in planning well, setting expectations by being transparent & robustly communicating using collaboration tools and finally able to deliver most business valued features frequently.

I look forward to read your feedback on how properly your team follows the essence of Scrum.

References:

•  Do Better Scrum