3 Roadblocks to Scrum

From the Scrumptious Blog
by
Scrum is the most popular framework used within an agile environment to convert complex problems into valuable products and services. In this blog, we will examine all things Scrum to shed light on this wonderful organizational tool that is sweeping the globe. There will be engaging articles, interviews with experts and Q&A's. Are you ready to take the red pill? Then please join me on a fascinating journey down the rabbit hole, and into the world of Scrum.

About this Blog

RSS

Recent Posts

Losing a Scrum Team member

The Scrum Cold War

How SAFe is Scrum?

I think we can. I know we can.

Please don't bug me



Transformations of any kind within the organization are challenging at best, and disastrous at worst. Sometimes there are dynamics we can't avoid, like the time it takes for that transformation to take hold, or the strategic priorities of the organization not including a 100% full steam ahead of the Scrum implementation (ie. a never ending series of pilot projects).

There are, however, a few major roadblocks that we do have some control over. The first two deal mainly with process, and the third with mindset. We all know that Scrum has rules, events, roles and artifacts. But it also needs to have people with the right mindset, and who follow a proven process.

So, with all that being said, here are 3 roadblocks to Scrum faced by organizations all over the world:

1. Partial or Late Testing
There are some who don't mind leaving testing until after the Sprint, or partially completed by the end of the Sprint. While there are some exceptional circumstances when this may be required, here is Scrum Co-founder Jeff Sutherland's view on this:

"Do not end your Sprint without your software Done and bug free."

According to Dr. Sutherland, bugs that remain at the end of the Sprint can reduce speed of development by 50%, and in some rare cases up to 1,000%. In order to mitigate this, we need to "change engineering practices, implement continuous integration, and incorporate automatic testing into the builds". 

2. Backlog Mismanagement
Garbage In, Garbage Out! The products and services we produce are only as good as the refined Product Backlog items that find their way into the Sprint Backlog. I have spoken about this in a previous blog, but a poor Product Manager can render the backlog ineffective.

Dr. Sutherland asserts that 65% of features developed are "never or rarely used by customers" which means we are doing a "terrible job" in turning customer's needs into usable and relevant features. This wastes time, money and effort. His recommendation for this problem is to get a great Product Owner, produce a quality refined Product Backlog, and get continuous customer feedback in "30 days or less" to ensure every feature in the Backlog are only the features the customers want.

3. Management Involvement
Even when Scrum has been sanctioned at the Executive level, and is running full swing at the project level, if managers do not embrace Scrum and empower the team to work at the best of their ability, Scrum is going to be running with one engine in a two-engine plane. One major catastrophe, and the whole project could come crashing down.

Dr. Sutherland has some good advice in this area:

"Train your management team on how to run a modern corporation. It needs to be Agile and it needs to be Lean. Managers need to make a big shift in the way they think and how they work with teams."

A lot of this can be facilitated through a Scrum Master or coach to guide the organization and its management in the benefits and implementation of Scrum, but more importantly, the mindset, values and principles of Scrum.

                                                               * * *

Remember, a pitfall is a "hidden or unsuspected danger". It can also be defined as a trap; a trap for those who wish to sabotage the implementation of Scrum. We need to navigate the transformation minefield and avoid those pitfalls in order to reach our destination: a product or service that is fast-to-market, bug free, and what the customer really needs.


References
Sutherland, J. (2012) How to Avoid the Most Common Scrum Pitfalls. Available from: https://www.youtube.com/watch?v=KEu-YEv1LVo


Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature
 

 

Posted on: March 01, 2018 12:07 AM | Permalink

Comments (18)

Please login or join to subscribe to this item
Issues I encounter - Business involvement and buy-in (this is an IT thing), prioritization, and proper testing landscape; how to accomplish ACT, system, and integration testing. What is the expectation within the Sprint? How does testing fit in with the DoD? Do we have test environments? Who is responsible for what? These questions may depend on size and scale or organization/transformation.

These are items I'm encountering. I need to write about it :)

This is related to management involvement. Managers need to be trained on what the roles of their staff will be, and what they should be empowered to do. Giving everyone "agile" training doesn't teach an individual how to be an effective product owner or a manager how to empower his staff to serve in that capacity.

Thanks Andrew, Eduin and Fernando.

Andrew, that's a decent list. I'm sure it's even longer than that when we really get into it. When you say "do we have test environments?" what are the testing options you go with if the answer is no?

Aaron you make a good point. Many organizations have Agile training, and then the participants walk away with "Ok now what do I do?"

Good article, Sante and thanks for your insights on this.
I think we need total commitment from the customer and their management. If the stakeholders are not in the room, it's not going to work. Ultimately "scrum is going to be running with one engine in a two-engine plane".

Sante, that is a frightening thought. I don't know. Obviously, there is testing at the development level with Unit Tests, but there has to be some type of staging environment hierarchy to have released functionality tested; from an acceptance level, through integration with functionality pushed from other modules. Of course, then there is regression, which is another puzzle piece. Honestly, testing seems to be the most challenging aspect. Am I overthinking it? How do you keep testing as agile as the development?

Thanks Anish, it's not easy, but identifying any roadblocks is the first step. It comes down to acknowledgement without blame. When that occurs, a solution can then be found.

Andrew, yeah it's a tough one. I probably shouldn't be saying this but I see testing in a software environment as a process under the management of Agile frameworks like Scrum. But I think you're right (and Jeff Sutherland seems to back it up) that testing is one of the biggest challenges.

Thanks Sante, scrum ..scrum.. scrum.. I am excited to dig more into scrum.

Thanks Riyadh, yes Scrum, Scrum and more Scrum lol.

Sante
Yes :) I started to read and hear a lot about scrum.

Good Article

@Andrew - so finally how do you manage testing within sprint and ensuring "bug free" product as recommended? Is SIT considered part of sprints?

I have had challenges where defects fixing takes up time and the team is able to take in only fewer user stories

Thanks for sharing

@Tanuja - I'm still trying to figure that out :) A lot is constrained by the organization and environment.Ideally, during a sprint, the team is concerned at the story level with the ACT's. A chosen point needs to be determined for SIT and again for IT. Each of these contains different activities, criteria, and thresholds. Anything past ACT should not be a sprint, though those activities at some point would have to happen in parallel with ongoing sprints. Then those defects are entered and prioritized in the backlog

Within a sprint, there are two scenarios; 1) The story ACT can pass even with noted defects. The story moves forward while the defects are logged, moved into the backlog, and prioritized accordingly to be taken up in a future sprint, 2) The ACT's fail and the story is kicked back to the developer within that sprint.

Andrew, it's good to keep figuring things out or else life gets boring.

Tanuja, as Jeff Sutherland said, unfixed bugs after the Sprint can make delivery up to 10 times longer than anticipated. If that isn't incentive enough to get those bugs wiped clean before the end of the Sprint, I don't know what is.

Sante it's a total motivation no don't and I totally agree with what Jeff Sutherland has said. I was trying to find out what other organizations do. In an IT environment, while the developers are coding and unit testing, how do we manage to get the code moved for integration testing and fix bugs all before the sprint ends and still manage to efficiently utilize all the team members during then sprint duration.

There's no one best answer Tanuja. But a few things to consider: is the team equipped with the appropriate number and skill set for the testing required? There might be a bottleneck. Are the bugs categorized and severity levels assigned so you know which ones must be fixed by the end of the Sprint and which ones can wait? What is the process to minimize bugs in the first place (ie. pair programming)? Or if it's an issue with systems integration, is there a testing team focused on this possibly from IT, or is this falling more on the development team which creates a situation where the bugs gets ping-ponged back and forth.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"There is not one wise man in 20 that will praise himself."

- William Shakespeare

ADVERTISEMENT

Sponsors