What does Scrum mean to you and your organization? While Scrum is a fairly well defined framework, this question will elicit a different response in almost any organization. Scrum.org defines Scrum as a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. I like this description.
Scrum.org goes on to break down the role of a Scrum Master as fostering an environment where:
- A Product Owner orders the work for a complex problem into a Product Backlog.
- The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
- Repeat
A Product Owner will often be a PM or Analyst depending on the organization/product size. This person manages a fairly complex discovery process. There are lots of failure points throughout this part of the process starting with finding the right individual to manage the product, but branching out much further. Blockers occur when intra-department work happens, when a vendor is required, and when leadership shifts priorities for the business. While none of these are directly related to Scrum Fundamentals, they will all make the process fail.
Next, we get into really planning timeframes and quality control. The development team should be coming together here and deciding how difficult projects will be. Point values are then assigned to tasks/sub-tasks, and the team takes ownership of the work. All too often in this scenario, we’ll see the PM exert undue influence on this process because of business priorities. Resources are often finite, and goals can be pushed from leadership that don’t align with them. But, trusting the development team to gauge as a team the difficulty of tasks will have a much better prediction rate than other methods. It’s important to keep our expectations aligned with reality during this process.
If this isn’t working, you’ll quickly be able to see results and adjust. This is key to a good Scrum environment, and ultimately, we find the real problem with Scrum in most organization. Any experienced developer can make a long list of what is often found during this process. And a lot of what comes out of this is great knowledge for the team. People can talk about blockers, and discuss different methodologies and best practices. And a proper review of the points system and individual contributions will often help better gauge the hierarchy of talent in the organization.
But, there are many problems that we find in review that aren’t truly related to Scrum, but rather the product creation process and organization as a whole. Scrum has no methodology to fix a vendor who takes 3 weeks to start providing support. Scrum has no methodology for solving an insufficient budget from leadership. Scrum has no methodology of to fix culture issues that often occur within an organization or team. And Scrum can’t stop the natural disasters that happen during the course of business.
So, what’s the real problem with Scrum? It’s when people have unrealistic expectations of what it is. Scrum is much more than 4 bullet points on a whiteboard, but it’s by design an adaptable and lightwork framework that can fit into different organizational structures. It’s not the end-all be-all of helping your development team to succeed. Scrum can be an effective cog in the wheel when implemented and managed well. It’s important we don’t get discouraged when we run into issues.
Luckily, the biggest problem with Scrum is resolvable. Proper communication and expectation setting can go a long way to creating a successful product.
Have you been struggling to properly get Scrum working in your organization? Alternative Solutions is your expert resource on all things Scrum and Product Development. Schedule a conversation with one of our resources today about how we can help your team succeed!