Starting to Do Scrum Correctly is Hard!
I have been part of one company that transitioned to scrum.
On another contract I worked on, the team stated they were agile, but that really meant they just held “status meetings” (that were called standups) every morning.
The third company had a few teams attempt to start the process, but there was not management buy-in.
So what made one company successful, whereas other companies failed? Let’s explore.
Failing to Use Scrum: Not Having a Clue
This one is the easiest diagnose. Those with leadership directly above the team that’s making the transition either do not know the basics of this development process, or they don’t care.
Some say they follow the process just to check off a box. They don’t really care to do it. This is a very straightforward reason explaining why the process is not followed.
No Management Buy-In
I believe this is the most common cause I’ve seen for scrum failing.
Development teams can choose to follow the process. This might work for a while, but eventually a higher-level decision might make everything fall apart.
For example, intervals called sprints are used to scope what will be done within a period of time. These can vary from a week to a month. Generally I’ve seen two weeks being used.
You must be able to somewhat accurately predict what you can accomplish in those two weeks.
What happens if something super urgent comes up during the middle of the sprint? Adding more work to the sprint not only means other stuff won’t get done, but it also breaks the team’s focus and costs some amount of context-switching time (or, worse, overtime is expected to finish everything).
Doing this once is a bad thing. But I’ve seen it happen over and over and over again.
It is very difficult to do scrum when the business cannot focus on the same priority over a trivial amount of time such as a week or two. There’s not a lot of point to planning when that plan is just going to be shredded a quarter or halfway through the sprint.
How do you prevent interruptions?
- When something is done, make sure it really is done. (Code compiling is not “done” – code tested in the system and working properly is done.) This helps prevent some crises from ever happening.
- If a big problem does occur, push out working on it until the next sprint. If that’s not possible, prevent them from occurring as much as possible. Learn from previous mistakes!
No True Product Owners
When someone does not truly own the product (or multiple pieces of the business don’t have ‘owners’), this is a recipe for frustration.
If a product owner “owns” a product, but then someone else is able to change course for that product, that person is not really an owner of the product.
This just leads to extreme frustration. You “own” the product, but in name only. You don’t actually make the final decisions on what happens for that product.
Problems rising from this is shifting priorities or an unclear focus on the key business objectives. Without clear focus, it is hard to evaluate if all the work being done on a product is actually going somewhere.
The Funny Thing Is Scrum Is Actually Working in These Cases!
In the case of constant interruptions or not having true product owners, agile is actually working as intended.
The framework does not necessarily provide an instant fix to problems. The biggest thing I’ve seen from scrum is the ability to point out issues sooner. To give more visibility.
This doesn’t magically fix the problems. All it does is allow the business to react to the problems sooner. Hopefully by planning and being proactive rather than reacting.
That might mean descoping some features or pushing back a delivery date. But those decisions can be made earlier in the process as there is more transparency into what is happening.
But rather than continue the process, what often happens is the practice is dropped. Oh, scrum doesn’t work because our business is special! Not really. Your unwillingness to change is quite common. And that is why scrum “doesn’t work”.
The Successful Transition to Scrum
In the successful transition to scrum, I can point to a few key points in time that could have made the whole thing implode.
Misunderstanding of Scrum
In one sprint review, a sales person/project manager asks us why the team had not finished what they “committed” to.
A lot of people hear only the things they want to about scrum. They don’t acknowledge it takes a lot of work to get there. They only want to enjoy the benefits of quicker delivery times or higher quality without the changes it pushes into an organization.
This was due to a lack of understanding about scrum. The ScrumMaster talked to that stakeholder after the meeting, and a day or two later, that same person apologized to the team.
Which goes to my previous point of needing manager buy-in. The ScrumMaster would not have been able to do that without having support from superiors that following the process is more important than meeting a date.
Addressing Issues Rather than Ignoring Them
In another instance, the team got very frustrated with the entire process. Rather than let this all get swept under the rug and ignoring it, the ScrumMaster had a retrospective in the middle of the sprint. As a result of this, a lot of things changed.
Once again, this required manager buy-in to make tough decisions. It also required descoping functionality or having tough conversations with customers.
I see a lot of sprint retrospectives involve a lot of complaining and not a lot of fixing. While this may make the team members feel better, it does not help everybody improve. Retrospectives have to result in some good action items, and those items need to be addressed.
Adopting It Across the Organization
Having successfully followed the process within a few teams in the business, it was adopted across the entire organization.
This began with training. Some people that were certified scrummasters (from previous off-campus training) held a two-day event to teach 100-200 engineers how to follow the process.
Once several teams adopted the process, the business implemented a higher-level 10 week planning period. This involved multiple scrum teams getting together to plan 5 sprints.
This allowed high business objectives to be pushed down in a defined way across multiple teams. It greatly improved collaboration between teams.
For example, during this meeting, a team might discover they have a dependency on another team. A discussion would be had so the other team would agree to deliver some piece of functionality by a certain date so the other team could use it.
This identified dependencies early in the process (more visibility!), so teams could proactively plan rather than react to blockers happening further down the line.
Knowing how scrum works is fairly simple (although several people ‘think’ they know when they don’t). Adopting the practice and following it on a day-to-day basis is very challenging.
Common practices must be changed.
Learning and changing based on lessons learned must occur.
Slowing down at first in order to become faster later must also be accepted.
But in the end, it is well worth it. Just like changing the oil in your car is necessary for good automobile performance, proactively setting priorities and constantly learning and changing based on those lessons is needed for good business performance.