Scrum is a framework that helps teams work together to solve problems and create products in complex environments. It is the most commonly used Agile technology with about 66% of Agile users implementing Scrum in 2021 [1].

So while Agile is an overarching philosophy of collaboration, Scrum is its most popular implementation – just like karate and Taekwondo are specific forms of martial arts.

Agile is abstract; the entire Agile manifesto is only 73 words, including the title [2].

Scrum is specific; it is a system for project management with pillars, steps, and a process flow of value-delivery meetings called sprint ceremonies. You can take multi-day courses to earn any number of Scrum certifications, such as the Certified Scrum Master (CSM). Your binder of notes from this course could easily weigh a few pounds.

We’ll be looking at how to adapt Scrum to project challenges through each of the four Scrum sprint ceremonies: standup, planning, demo/review, and retrospective. These adaptations could also be called ScrumButs, as in, I would really love to implement Scrum by the book (But)(Reason)(Workaround).

There is generally a negative connotation associated with ScrumButs because they expose a dysfunction in working conditions [3]. But ideal conditions are rare, so these workarounds address the realities of projects, rather than dysfunctions of a project.

Here are five ScrumButs broken out by ceremony. We use Scrum, but…

Daily Standup/Scrum

#1 There should be a single Daily Scrum call, but we require a lot of coordination with our sister office in Mumbai to support 24/5 development and production support, so we have implemented a morning and evening Scrum call for US-to-India handoffs. This not only improves the relationship between our US and India team members, but also maximizes our effectiveness within a project’s scope and timeline.

Sprint Planning

#2 Sprint work should be allocated at the beginning of each sprint during planning, but production support requires teams to add work mid-sprint, so we estimate a reserve of production support points by team member during our planning sessions. This ensures that the team can respond to ad-hoc severe incidents and complete planned work without burning out.

#3 We value iterative development, but project scope is often bounded by a Statement of Work (SOW). Late-project changes sometimes showcase team flexibility; other times, they just showcase scope creep [4]. So, our product owners manage/prioritize all stakeholder requests through a product backlog, but also work with project sponsors to defer work to following development cycles or redefine SOWs for new priorities.

Sprint Demo/Review

#4 Sprint reviews should include key stakeholders and end users, but it is not always possible to get time and buy-in. So, we perform sprint demos with just the Scrum team to still create transparency and socialize knowledge. Wherever possible and when helpful, we deliver updated mock-ups and designs to end users via email/chat.

Sprint Retrospective

#5 Sprint retrospectives should happen at the end of every sprint so the Scrum team can inspect itself—celebrating wins and identifying areas for process improvement. But it can be a lot of overhead when working across time zones means early mornings or late nights. So, during busy seasons we implement asynchronous retrospectives where team members publish feedback to a shared location.

Each project will face its challenges when adapting to Scrum. At PDG Consulting, our team has seen it all—so we are prepared and are adept at overcoming and adapting to unforeseen circumstances. Whether a project is experiencing scope creep, or merely faced with the inherent challenges of coordinating with offshore, our industry-experienced team members can help implement Scrum to deliver projects timely and accurately. Contact us today to learn how.