Development Team – Why your Scrum Doesn’t Work (2/3)

Originally posted on www.debooij.training

Many teams and organizations struggle to get the most out of Scrum. In a previous post “Don’t blame “agile” for existing problems” I shared my analysis why agile or Scrum itself often gets the blame. In this second post out of three I will focus on what the most common mistakes are with Scrum that lead to dysfunctional Scrum. This time we take the perspective of the Development Team.

Scrum roles and responsibilities

Over the years I have learned and experienced that most symptoms can be traced back to not adhering to the responsibilities of the Scrum Roles. That’s why I have sliced this topic into three separate posts:

• Product Owner – Why your Scrum Doesn’t work (1/3)
• Development Team – Why your Scrum Doesn’t work (2/3)
• Scrum Master – Why your Scrum Doesn’t work (3/3)

Each post takes the perspective from the role being covered. I explore high impact discrepancies between how Scrum is intended (referred to as Professional Scrum) and how it is often practiced and misunderstood. The posts are based on my own experience when I practiced the roles of Development Team (member), Product Owner, and Scrum Master. And on recurring examples my students mention during my Scrum.org courses.

Development Team

Professional Scrum Development Team

A Professional Scrum Development Team is a group of dedicated professionals that create a potentially releasable product increment with the aim to achieve a specific goal – the Sprint Goal. They do this every Sprint (1 month or less). By turning Product Backlog items into a working product so frequently, they mitigate risk early and continuously:

• Technical risk: does it actually work? And does it successfully integrate with the previous product Increment?
• Business risk: does it actually solve an end user problem? Does it fulfil the targeted need?

As a result, the Development Team not only delivers value but also enables the agility of the Scrum Team. To safeguard this, the Development Team develops a Definition of “Done” they commit to at all times. It states what they need to do to keep the product increment in a releasable state. The Development Team is responsible for the increment, and as consequence they are responsible for the quality of the increment.

Cross-functional and self-organizing

The Development Team is a cross-functional team. This means they have all the skills that are required to deliver a potentially releasable increment every Sprint. And they are a self-organizing team. No one tells the Development Team how to do this. We trust them to get the job done. Based on the Sprint Goal that the Scrum Team crafts during Sprint Planning, the Development Team regularly inspects and adapts their progress and their plan to achieve the Sprint Goal – the Sprint Backlog. When new insights emerge, the Sprint Backlog likely changes throughout the Sprint. The Development Team owns the Sprint Backlog, and is the only one that can change it. At least every Daily Scrum they inspect their progress towards the Sprint Goal and create their plan for the next 24 hours accordingly.

At the same time, self-organization implies that they resolve their own challenges, both technical / product related, and interpersonal / collaboration related. However, the Scrum Master helps them grow their capabilities to resolve these challenges in an effective manner.

Customer collaboration and refinement

The Development Team closely collaborates with end users to better understand their needs and what is valuable for them. And together with the Product Owner, they continuously refine the Product Backlog to capture just enough details. At the same time they strive for “ready” Product Backlog items on the top of the Product Backlog. In other words, the Development Team deems these items small and clear enough to turn them into a potentially releasable increment within the time-box of the Sprint.

Why this might not work for you

Misinterpretations by the organization

Your organization might have slightly different expectations, like:

• Just execute the tasks that we defined. You are the hands, not the brains.
• Velocity is a good indicator for measuring how well the Development Team performs
• If we need to get it done faster you simply need to work harder
• The Product Owner can trade quality for more speed
• If we have a last minute request we can push it into the Sprint
• It’s okay if the Development Team is not fully cross-functional. They can collaborate with other departments to fill any possible gaps.
• We need to closely monitor the Development Team since they are self-organizing. Otherwise it will lead to anarchy.
  • Luckily we have the Scrum Master and Product Owner to manage them closely.
• We need to keep customers and end users away from the Development Team so they can spend more time at creating the product.
• If we involve our customers more frequently and even during development, they will get the impression we are incompetent and not capable to capture their requirements up-front
• Our customers don’t want us to release more often

Misinterpretations by the Development Team

Or maybe you – as a member of the Development Team – have a different understanding of the Development Team role, like:

• I need to only focus on my own tasks in the Sprint
• The most important thing is that I’m am productive
• Working together means we will be less productive = waste
• If I can’t complete my work because I’m depending on others it’s not my problem.
• Having to work with end users distracts me from doing my job
• If we finish all work that was identified during Sprint Planning it equals a successful Sprint
• The Product Owner should describe all requirements in detail so that there can be no surprises during the Sprint
• If we have people issues in the Development Team the Scrum Masters will take care of it
• As a matter of fact, we can shove all our issues that distract us from doing our work to the Scrum Master
• If there are unforeseen circumstances we must ask the Product Owner to make a decision
• If the Product Owner tells us to take on additional work, it’s okay to sacrifice quality to make it happen
• It’s okay if we didn’t manage all the work from the Definition of Done, as long as we covered all the functional aspects from our Sprint Backlog. We can finish the remaining work in the next Sprint.
• All communication with stakeholders must be done via the Product Owner
• We will inform the Product Owner about the Sprint during the Sprint Review
• It’s good enough if we integrate all our work from the Sprint at the end of the Sprint

What you can do about it

Frequently inspect what we should expect from a Professional Scrum Development Team. For example by attending a Professional Scrum Foundations or Professional Scrum Developer course, studying the book Scrum – a Pocket Guide, and revisiting the Scrum Guide. Furthermore, reflect on how you practice the role at this moment. Only then you can identify discrepancies. And as a result you can figure out what you can do to change it for the better. Your Scrum Master can be of service here. If you want to know how, have a look at this post:

The responsibilities of the Scrum Master

What about the Product Owner and Scrum Master perspective?

Read here the  Product Owner perspective and Scrum Master perspective.