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
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:
