Implementing Scrum with a new team can be a daunting task. In most cases, it can be something that is looked down upon, seen as something unnecessary or added-work. We’ve already covered overcoming fears and ego in an Agile transformation and the Coach’s role here.
Our first thoughts around this is that there may have been a gap in communicating the true value of going Scrum. Debbie Nichols says that there are three main ways that teams receive Scrum backlash:
- Adapting to a New Process
- Hating the Daily Scrum
- Estimation Tasks are a Nightmare
Debbie goes on to say that teams “Can, and should, adjust Scrum to meet both the needs and temperaments of their members.” I know of certain individuals that may balk at this and say it isn’t Scrum at all if some of the very fine-tuned aspects of Scrum aren’t participated in. Whether you’re on one side of the fence or another, it’s worth looking at Debbie’s blockers.
New Processes Don’t Have to Suck
Adapting to a new process can be a pain in the butt. We’ve all been there. Whether it is having the team take time out to build up a product backlog, or start logging all their work (or a Product Owner should do that), in many teams they would give you a response of: “Work before paperwork.” We get that, totally, and we agree with Debbie that it may make sense to incrementally build this out.
We see three ways to help with this process:
- Have your Product Owner begin building out a prioritized backlog and have the team start taking their work from that.
- Have your team start looking at work in functional chunks and work with a Product Owner to prioritize those chunks into logical lengths of time (2 weeks, 1 month).
- Have your team start documenting tasks associated with work they are doing and post it somewhere. This begins the process of creating information radiators for the team to revolve around.
Hating on the Daily Scrum
Debbie’s experience on the daily Scrum has been negative. It seems that in a corporate world filled with meetings, a daily Scrum is just another additional meeting. This need not be the case at all! Daily Scrums are one of the best ways to communicate progress and issues daily! In our estimation, this is one of the key tenants of what makes Scrum successful: Constant collaboration, communication, and face time.
We see three ways to help with this:
- Just do it. Have a ScrumMaster or a team lead begin the Scrum at a designated time in the beginning. Lead by example and show transparency to your team. Let them know what’s going on!
- Have different team members start the Scrum each day. This will start putting the emphasis on the team leading it and not some designated leader.
- Facilitate better conversation and elicit better details during the Scrum. More on that here and here.
Find more information on Scrum of Scrums here.
Coming from a development background, we totally understand this issue. So what to do? Give a reasonable estimation for a piece of work, double it and hope it all comes out in the wash, right? Well not really. Even though the Agile software development landscape is ripe with horror stories about estimation, it doesn’t have to be that way. Remember though, it’s not so much matching estimates with original estimate schedules, but understanding capacity of a team to complete work (with value)! We’re not in 1970-1990′s. Traditional project management has wanted to make sure that we match estimates with schedules. This is not the case in Agile development! Estimates and schedules in Agile software development is a continual conversation with Product Owners and the team!
We see three ways to help with this:
- Estimation can be a black box every single time. Start documenting relative estimates to very well known LOE’s that the team is aware of already. Does the monthly build take 30 minutes with all it’s processes? Ask the question whether a piece of functionality takes as long as the monthly build. Revolve around that.
- T-Shirt sizes are great, as long as they are consistent. But it may be of value to have different categories of estimates. Say: SWAG (Very high estimate, usually 2-3x the size), Feature Specific Estimates (Estimates around specific functionality), Task-Level Estimates (A fair estimate of tasks to complete a feature). Again, start documenting all of these and create known estimation points to pivot around.
- Talk about Size and Complexity. They are two very different things. The complexity of a small feature may have huge impact to a feature. Bring these two issues to the front. Receiving a bland estimation about a feature doesn’t help you understand the potential complexity and LOE of a feature if you don’t talk about it. Remember to think of these two things.
Implementing Scrum can be a complex issue with any beginning team, but it doesn’t need to be. Take it step by step and move towards a pace that is comfortable for your team.
Debbie Nichols says that:
“Remember that there is no ultimate authority dictating that your team must implement Scrum “by the book.” Like other agile methodologies, Scrum is nothing more than a collection of good ideas.”
While some may disagree with this sentiment, we are inclined to say that every company and team is different. Remember, the goal is to bring value to your team, department, client, customer, or company. If Scrum can provide value in even the smallest parts (in the beginning), it’s a worthwhile journey!