Project Practitioners > Scrum is not Difficult; Abandoning the Familiar Is

Scrum is not Difficult; Abandoning the Familiar Is

By Brian Irwin

Scrum is one of the easiest frameworks to understand. I’ve heard it said that, while Scrum is easily understood, it’s difficult to do. While teams and organizations do struggle with Scrum, I tend to disagree with the wholesale statement that Scrum is difficult to do. One of the reasons I believe this Focusstatement came about is that teams and organizations aren’t realizing the benefits they originally expected they’d receive when first adopting Scrum. The Scrum framework is intentionally lightweight and easily understood. Struggling to implement something that’s easily understood is indicative of different issues.

Before I get too deep into this post, I’d like to state that I believe people are generally good and want to do the right thing. That being said, people (and I include myself in this demographic) tend to gravitate to the familiar, the known. To organizations and teams just beginning a journey into agile Scrum is not familiar, far from it. As a result, pre-existing patterns and behaviors Oppenness.jpgresurface on Scrum teams and in new agile organizations that make it seem as if Scrum is difficult to do—it’s not! However, I do agree that it’s difficult to do Scrum while still embracing traditional behaviors such as meetings extending past pre-determined and agreed upon time-boxes, management failing to relinquish command-and-control for servant leadership styles, and organizations demanding project time, cost, and schedule all be fixed. Scrum isn’t difficult; abandoning the familiar patterns and behaviors is the part that’s difficult.


The ScrumMaster is supposed to address and help remove these issues. Sadly, ScrumMasters in many organizations are often too busy to address these issues because they’re simultaneously given other duties and/or they lack the courage to address them for fear they’ll lose their jobs. We may be able to minimize some of the difficulties if we force ourselves to periodically review the why behind the Scrum events. If we don’t pay close attention to remembering why we’re holding these events in the first place our teams and organizations can easily fall into mechanistic Scrum events which lead to Respectlackluster results and waste. Let’s review each Scrum event from the perspective of “why” we do them—their intent and objective(s). Prior to doing so, I’d like to reinforce that the overall intent of each event is to provide a formal opportunity to inspect and adapt. We should always be operating on three pillars—transparency, inspection, and adaptation.

THE SPRINT

The primary objective of a Sprint is to get committed features to a state of done so these features
can provide value to the customer. The Sprint is the container in which all other Scrum events reside. Far too often I see teams carry over work from Sprint to Sprint. Symptoms indicative of traditional behavior include, but are not limited to, team members performing in their respective role only (developer, tester, etc.) forgetting the one-for-all and all-for-one spirit of the team in Scrum; testing being cut short at the end of a Sprint; and Sprints defined by waterfall phases such as a design Sprint followed by a development Sprint, then a testing Sprint, etc.

SPRINT PLANNING

The objective of Sprint planning is to arrive at a team commitment on what will be completed at the end of the forthcoming Sprint. In Sprint Planning, the Scrum team will identify what will be taken into the Sprint and the development team will identify how the value will be created. But, at its core, the team’s objective is to arrive at a commitment that can be supported by all.

DAILY SCRUM

The objective of the Daily Scrum (daily standup) is to synchronize activities for the next 24-hours. To me it’s also about individual commitment, accountability, and responsibility to the team. Some also recommend that a goal of this event is to surface impediments. While this is one of the three questions answered, I’ve seen individuals save the surfacing of issues until the Daily Scrum—even if the Courageimpediment was identified an hour after the previous days’ meeting. Surface impediments immediately. This meeting has become more commonly known as the daily standup because of a common practice of having team members all stand to assist in keeping the meeting focused and aiding in adherence to the 15-minute time-box. However, it’s formally known as a Daily Scrum. Typical dysfunction demonstrated in this meeting is allowing the meeting to transform it into a troubleshooting session and providing a venue for management to direct the team—the same team we’re trying to grow into a self-organizing high-performance team, by the way.

SPRINT REVIEW

The objective of the Sprint Review is to generate feedback through the demonstration of working Commitmentsoftware completed during the preceding Sprint. I’ve often heard this event referred to as the “sprint demo”. Yes, we are demonstrating working software during this event but by calling it a demo we can forget that the primary purpose is to generate feedback that we can use to make the product better. In short, the Sprint Review is to generate feedback to improve the product.

SPRINT RETROSPECTIVE

The objective of the Sprint Retrospective is to inspect and adapt the team and process. Much like the Sprint Review being an opportunity to improve the product, the Sprint Retrospective provides an opportunity to improve the team and the process. As a recovering project manager I recall sitting through many “lessons learned” meetings that resulted in reams of paper being destroyed to record these lessons, but that rarely resulted in any true learning as I witnessed the same mistakes made time and time again. Without fail or exception, nature repeatedly provides the same lessons until we learn them. Because of this I often refer to them as “lessons observed” meetings.

I encourage you to reiterate these objectives at the beginning of each of the Scrum events. I’ve found that by doing so you can quickly refocus and calibrate the team about why they are there in the first place.



Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy



Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds


Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.