Top 10 Things that Developers Should Watch for in Scrum-Driven Development
WEBINAR: On-demand webcast
How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >
Since the 1995 paper published by Jeff Sutherland and Ken Schwaber describing Scrum methodology, Scrum has taken software development by storm, with tech firms increasingly adopting the Scrum/Agile mantra as their development paradigm.
Scrum is very different from the classic waterfall model and while it has its upsides, there are a few things to keep in mind when using the Scrum methodology to ensure that your team can deliver what is expected of them.Based on my experience, I have gathered a list of top 10 things that can shape the success of a Scrum-oriented development team.
We will go through them in no particular order.
#1 Not Having a Product Backlog or a Vested Product Owner
As a Scrum-driven team, you need to ensure that you have a product backlog to work from. Not having enough items to work on will cause your engineers to starve for engineering problems to figure out.
Not only do you need to have a backlog, you also need to have a product owner (who is typically responsible for providing requirements and arranging for engineering resources to work on the project) who can provide clarification on any requirements that are on the backlog. As part of getting tasks on your backlog, you need to ensure that all the requirements are clearly understood and technical requirements are answered. You do not want a situation where your team is planning to start a task in a specific sprint but have many questions on what the work means.
#2 Overestimating What can be Delivered in a Sprint
Overestimating how much can be delivered in a sprint can happen when the basis of estimation is tied to the ability of a specific engineer. Some teams choose to cost a task in terms of engineering hours to get that task completed.
One pitfall in that approach is that the same task can take two hours for a senior engineer, while it will take a week for a relatively junior engineer. To ensure that you get a consistent basis that can work for everyone, one approach that I have seen applied successfully is to base the task on the complexity (like simple tasks take one point, coding a relatively advanced function will take two points and building a complex validation can be estimated as three points, and so on. How you arrive at the points is also important. To ensure the same basis, everyone should try to swag the points for a task and take the average.
#3 Overdoing Scrum Planning
This can happen in one of two cases:
1. There is enough work carried over from the last sprint that can cover the sprint being planned. In such cases, there is no reason to visit the backlog to find items that need to be finished (if the priorities do not change) and energy spent in Scrum planning can be better used somewhere else.
2. Scrum master does not have a planned roadmap of features for the product and is worried about things on the backlog.
#4 Tools Don’t Matter, Accessibility Does
Teams new to scrum can typically struggle more with the tools than the methodology. Teams can toggle between post-its, bean points, Scrum board or other ways to represent the tasks that will be executed in the sprint. What is important to note is that the tools are not important, the philosophy is. Settle down on one set of tools so that the team can get used to them. Focus on making the Scrum board accessible because it is important for the team to know the progress of all the tasks planned in the sprint.
#5 Relying on Scrum Heroes
The success to Scrum is to make sure you do not rely on Scrum heroes – those one or two folks who can deliver equal to what the rest of the team delivers. You do not want your sprint to suffer tremendously in case your “heroes” fall sick or leave your team mid-sprint.
If you have a rotating scrum-master, make sure that the scrum-master “on call” understands the responsibility well and drives the scrum process effectively. Make sure you have an experienced scrum-master to mentor the new scrum-master if he/she senses that the sprint needs a correction.
#7 Interruptions to Planned Tasks
Scrum deliverables can change radically if there are unplanned interruptions which require the team to change focus on any high-priority fires that need to be handled. If fires are a regular thing that your team encounters, make sure to plan your sprint accordingly.
#8 Not Demo-able Quality
Engineers feel that they achieved something when the software they write does something that they can show to others. In that light, it is important to plan sprints with demo-able features in mind. Stagger the features such that the team can build something that can be shown as working software at the end of the sprint.
#9 Defining Done
Features that the product manager wants do not directly translate into tasks. Instead they might be epics, user stories or tasks. If your team can only accommodate a user story (based on resourcing), make sure that you can try to plan an whole epic because the product owner would not agree with the something which does not match the requirements, resulting in morale issues with the development team. Factor time to incorporate feedback from product owners and plan the corrections as separate tasks. That will allow time and schedule to complete the feature in a truly “done” manner.
#10 Imposing Scrum When Other Methodology Works Just Fine
There are certain products where Scrum does not work – military, medical devices, etc. In such cases, applying Scrum methodology can backfire and cause goals to slip. If your organization already uses a different methodology, which works fine for its needs, do not go gung-ho on Scrum just because it is the new buzzword in town. Think and then decide what is best for your team.
In this article, we learned about the top 10 things that can lead to hiccups/failures of Scrum. If you have a list of things you want to share with others, please leave them as comments.
About the Author
Vipul Patel is a Program Manager currently working at Amazon Corporation. He has formerly worked at Microsoft in the Lync team and in the .NET team (in the Base Class libraries and the Debugging and Profiling team). He can be reached at firstname.lastname@example.org