Why ‘Our Version of Scrum’ Often Fails to Deliver Results
The core of agile methodologies is pretty simple: Break down a larger job into smaller components and complete those smaller tasks in brief timeframes. There are numerous advantages – the short go-to-market time, continuous feedback, from both the stakeholders and the customers, the lower risk of product obsolescence, transparency, and so on.
However, as companies are increasingly adopting agile frameworks to develop the product, they often face unique challenges during implementation. Here, we'll examine three real-life scenarios where too much customization of Scrum impedes the organizations from reaping its benefits.
Consolidation of Scrum Events
Company A: The development team is self-sufficient – it has three developers, a QA, and a very hands-on engineering manager. 
The team tried to follow scrum principles as much as possible. However, a recent workload increase forced the team to merge the review and retrospective events into a single 2-hour meeting.
What could go wrong? The team still showed progress to the executives, got feedback, and tended to incorporate the learning to the next sprint. However, the developers started to fight to fiercely defend their works in front of the upper management. Even if some feature was not implemented correctly, the team was too busy pinpointing the flaws and ambiguities in the requirement specifications and demanding a full revision or simply claiming that the produced feature was actually the one the customers will prefer.
Not surprisingly, the team rarely engaged in discovering what could be improved or analyzing what bits were still working. Some team members were reserved sharing what went wrong in the last sprint, especially during the annual review seasons.
Scrum treats each event, namely sprint planning, review, retrospective, and daily stand-up as unique and equally important. If any of them is missed or less prioritized, it's simply not Scrum! To rectify the counter-productive measure above, the team should:
- Separate review and retrospective events; instead of a single 2-hour window, allot at least an hour for each - with a sizable time gap in between. Typically, a 4-week sprint consists of a 4-hour review and 3-hour retrospective meetings with duration proportionate to the shorter sprints(1).
- Receive executive feedbacks on the overall process/technical improvements in separate meetings that might include the manager and senior developers, if those topics could not be shared in appropriate Scrum events.
A Hodgepodge of Development Methodologies
Company B: A very traditional organization, this team has with a history of working in waterfall models – a Project Manager (PM), 2 testers, and 4 developers – with PM acting as the de-facto team lead.
The team was confused why it was receiving largely negative reviews on the product from the users. It maintained strict release criteria – prohibited anything to be released until the artifacts match 100% of the test and quality criteria. Not surprisingly, the team had a very long release cycle and gathered a large backlog.
As a last-ditch effort, it decided to move to an agile development process, but most of the team members do not have much experience. The team recruited agile consultants and tried to embark on the agile way because that is the “fad.”
So, the team invented a hybrid model of working combining the features of both Scrum and waterfall. It conducts daily stand-ups, arranges weekly status meetings (“project review” event, as it portrays), and often engages in discussions where productivity could be improved. However, even after a few months of run, the backlog still grows. And worse, the team sees people leaving the organization.
What happened here? The team is trying to emulate the scrum events, but not in a careful way. Too many customizations effectively were ruining the team’s progress. Here’s what it could do:
- define a fixed-length iteration and slice the larger stories into manageable (typically within a sprint) chunks.
- employ a Product Owner, who can create a product roadmap out of the lengthy project contract. For some time, the PM, if she is knowledgeable about the product could serve as a PO.
- divide the roadmap into smaller milestones and fasten releases around them. With more frequent release cycles, the customers could actually test what the product offers and suggest improvements (Big-bang vs frequent release(2)).
- stop resisting the agile transformations.
A Caution Point
This is not to mean that the waterfall model does not work; in the past, it showed varying levels of success in many projects, especially with requirement well-documented, technology well-understood, resources available, and product definition stable(3). The point is, if a team decides to go agile for whatever reasons (there are plenty(4)!), it should not drag past misfit elements in the new beginning.
Inefficient Team Composition
Company C: The development team is huge here consisting of people both from on- and off-shore. The team tried to bring everybody to one place so that people know what others were working on. The downside? The morning meeting often used to take almost an hour!
How this setup is affecting project resources? On one hand, the team expected that everybody including engineering leads were aware of what was going on in the project; but most often, people cared much less about others' works - over the years, the project has grown so complex that the constituent units could operate almost independently. This was just the right time to scale up the Scrum (e.g. Nexus, SAFe, etc.). In essence, the team,
- Should break down the current team into smaller ones, typically consisting of 3-9 people. These teams should operate as independent entities, except 1/2 key members (maybe the senior engineer, team lead, SME, or Product Owner) from each allot separate times to meet and discuss backlogs, sprint ongoings, blockers, etc. They will work on the same product backlog(5).
- The teams should reduce the morning scrums to a 15-minute window and get back to work on sprint backlogs.
However, this new arrangement can create some new challenges. The high-level meetings may fail to convey specific domain/ technical knowledge; since the information is not first-hand, the meeting may miss important nuances; Oh, the additional meetings will eat up precious development time!
Conclusion: Tweaking Scrum
At the end of the day, Scrum is merely an empirical framework for developing complex products, and a few tweaks here and there sometimes seem essential. However, those modifications should not disrupt the sustainable product development cycles – the whole Scrum team should carefully monitor whether team members are getting the needed environment/support(6), time/resource utilization is efficient, and too many process customizations are not hindering the team performance.
References:
1. Scrum Guide, scrum.org
1. Scrum Guide, scrum.org
2. Agile Product Ownership, Bart Gerardi
3. A Gentle Introduction to Agile & Lean Software Development, Stephen Haunts
4. Agile Project Management, James Turner
5. Nexus Framework, scrum.org
6. Agile Declaration of Independence, Jeff Sutherland, Scrum Inc.
