I have had the opportunity to work with some truly amazing teams that have achieved pretty amazing outcomes. One thing that every team has had in common is that, at one time, they were new to Scrum. When I engage with teams to discuss implementing the Scrum framework, they often raise potential impediments to adopting Scrum. Below are the five most common objections to Scrum and why they don’t hold any weight.
Too many meetings—we don’t have time! (Scrum events actually SAVE time.)
When I present the Scrum framework to a new team, I almost always hear someone cry out, “How can we get anything done with so many meetings?!.” The Scrum framework consists of five events (what the uninitiated refer to as meetings), three artifacts, and three roles. The five events in Scrum are as follows:
I’m not going to lie; it does seem like a lot from the outside looking in. But experience shows that getting together at least once per month to plan work is not unreasonable. Meeting again to discuss what the Developers accomplished at least once per month is also reasonable. And a quick discussion with the Scrum Team to talk about ways to improve how everything is working–that is, frankly, invaluable.
As for the Daily Scrum, this event is timeboxed to 15 minutes daily. This 15-minute meeting, if done well, can save hours the team might otherwise spend in problem-solving meetings.
In short, experience shows that the Scrum events actually SAVE time if used well. In fact, the Scrum events REDUCE the time Developers spend meeting.
We can’t deliver working software in less than one month! (You can if you deliver smaller pieces)
The second most common objection I hear is that the Developers won’t be able to deliver a Done increment in less than one month. This is my favorite objection because it is an opportunity to discuss some fundamental truths about Agile. To get to those truths, a bit of background is in order. According to the 15th State of Agile Report, one of the most common motivations organizations cite for transitioning to Agile is to accelerate software delivery. One of the impacts companies see after adopting Agile methods is improved time to market.
The figures above are from the 15th Annual State of Agile report, available at http://stateofagile.com.
But these figures don’t necessarily mean that Developers code any faster; it means that Agile teams work differently. Using traditional development methods, the customer has to wait for EVERYTHING to get done before they can use ANYTHING. With Scrum, the Developers focus on delivering the most valuable work to the customer in smaller increments rather than in one large deliverable. Incremental delivery allows the customer and the business to start receiving value sooner. So yes, Developers CAN deliver a Done increment in less than a month.
We have deadlines; we can’t use Scrum! (Scrum increases the probability of meeting deadlines.)
Many software development teams are under pressure to deliver work quickly because other teams have deadlines they need to meet. A common objection to Agile is that teams feel that when they have a schedule to meet, a traditional waterfall method is the only way to go. Nothing could be further from the truth. Not only can Scrum work in these situations, but in my experience, it increases the probability of meeting challenging deadlines. Scrum works well with deadlines because it’s based on empiricism, lean thinking, and an iterative approach to product delivery.
In a nutshell, empiricism is making decisions based on what is known. In practice, this means that rather than making all of the critical decisions about an initiative upfront, when the least is known, Agile initiatives practice just-in-time decision-making by planning smaller batches of work more often. Lean thinking means eliminating waste to focus only on the essentials, and iterative delivery involves delivering a usable product frequently.
See my article Can Scrum work for Hard Deadlines to learn more.
We need to PLAN! There’s no PLANNING in Scrum. (Scrum Teams actually PLAN more)
There’s a common misconception that Scrum Teams don’t plan. In fact, Agile teams plan MORE than waterfall teams; it just happens a little differently. With a traditional waterfall effort, planning occurs up front and for Agile teams, it takes place more frequently. Scrum Teams plan their work for the upcoming Sprint during the Sprint Planning event and during the Daily Scrum, where Developers plan their work for the next 24 hours. You can also argue that refinement of the Product Backlog is a form of planning. Scrum Teams spend up to ten percent of their time during every Sprint refining the Product Backlog to prepare them for future Sprints. Furthermore, the Product Owner presents a forecast at every Sprint Review. Forecasting can take many forms but generally shows potential upcoming deliveries for the Scrum Team in much the same way that a project plan shows upcoming deliverables in a project using waterfall methodology.
Our management team will never go for it (They might with the right approach)
Many teams fear that they don’t have the authority to change the way that they work. And it’s true; most teams need a little help to transition to Agile. Here are a few tips for engaging with the leadership team in discussions around an Agile transformation:
Focus on value delivery
When engaging with the leadership team to gain support for a transformation to Agile, focus on what Agile does best: delivery of value in smaller increments, sooner.
Focus on role clarity
Many leaders hesitate to transition to Agile simply because they don’t know enough about it. Provide training to the leadership team on what Agile means and how they can best engage with an Agile team. I recommend Rebel Scrum’s Professional Agile Leadership class. See my article, Resource Managers and Scrum, to learn more.
Focus on promoting self-management within guardrails
Once leadership supports Agile, focus on getting self-management right from the start by allowing people to self-organize into Scrum Teams within established guardrails. Guardrails are the limits within which teams self-organize.
Some guardrails that I have used in the past are as follows:
- Each team can work on any Product Backlog item.
- Each team has to be capable of delivering work with end-to-end functionality.
- Teams will have no more than ten team members each.
- Every team will have Developers and testers.
- Each team should have a mix of experience levels regarding development and testing.
- All teams must work from the same Product Backlog.
- All teams will use the same Definition of Done.
- All teams will use the same point system and estimation definitions.
- Once the teams self-organize, we will use that structure for at least four Sprints before evaluating the need for any changes at a retrospective meeting.
Some of these guardrails, such as requiring all teams to work from the same Product Backlog, are simply restatements of Scrum framework foundational elements. Others are strategic decisions management would make to encourage greater cross-functionality, such as the requirement that any team should be able to work on any Product Backlog item to deliver end-to-end functionality for the product. Without compromising the Scrum framework, each organization may have additional unique specifications within which teams can self-organize.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.