This week we tackle the second role in Scrum, the development team. The development team covers the people that aren’t the scrum master or product owner — the group of people that actually takes an idea and converts it into something tangible. Not that everyone on the team doesn’t have a hand in delivering value, but in general it’s the development team that has their fingers on the keyboard(s). Ryan and Todd are presenting scrum in this book very much from a software-centric point of view, therefore the term development team makes perfect sense. The big “but” is that the term can create an impression that Scrum is only for development teams. The term “development” creates a boundary that excludes groups of people that configure software, deal with problem tickets, or don’t deliver software to somebody from using Scrum. Scrum is a framework that is applicable to any form of work. Don’t get hung up on the word development. If you want to get hung up on a word, pick the word team. We will revisit the idea of a team in the coming two weeks. Remember that a group and a team are not the same things.
Todd and Ryan discuss seven anti-patterns in this chapter. They begin with the age-old bugaboo of a team that doesn’t have the necessary skills. Building teams requires that you think of the output and then staff the team with all the requisite skills to deliver. If you have the luxury of creating a team from a green field, the authors suggest that you think of what it means to be “done” and then make sure that you have all the skills to move from idea to done scrum. Note, if you lead an existing team this exercise is useful so that you can shape the team, but unless you have an active skills market in the organization, shaping might have to happen on an evolutionary timescale. A further consideration that many teams and organizations miss in the Scrum Guide is that there is an expectation that a team will take work from the idea stage all the way to production (or delivery). Team skills and capabilities should reflect the entire job.
Three of the anti-patterns in the book that resonates with me are ”it is not my job,” “teams are too large,” and “everybody for themselves scenario.” These are a reflection of team formation failures. In my cases, I often observe groups that are a reflection of how Human Resources wants to group people – oftentimes built on the matrix management thinking. Constructed without a direct reference to a common delivery goal or around a value chain, they end up being too large and/or a collection of specialists.
Late last year I sat in on a daily Scrum of roughly 22 people. I say roughly because I was counting the number of people that I could see on the Teams participant panel, perhaps there were more. The event took 37 minutes to get through the event (root canals take less time) which equates to 814 minutes or approximately 13.6 hours of productive time. The event was a poster child for large team dysfunctions. There were at least 4 sub-teams (they developed naturally), and when people from one sub-team spoke the others turned their cameras off (I have no clue what they were doing). There was no collaboration between groups, they did not have a common goal and often were working on unrelated projects. Concepts like self-organization or self-management become a pipe dream which causes a need for more management overhead in teams that are too large.
The “everyone for themselves” anti-pattern is one of the more pernicious problems. Jeff and Ryan’s advice is to limit work as a tool to generate collaboration. Limiting the work in progress so that people tend to work together, more coaching, and techniques like pairing are all great ideas IF the group has a common business goal. Where there is not a common business goal ”one for all and all for one” will not be the team motto.
Earlier in my career I took over a team working a set of problem ticket queues from approximately seven or eight separate and distinct applications. The apps were all somewhat related to credit card file maintenance. Every team member had a specific specialty (and a laundry list of certifications for that specialty). The organization required 100% capacity utilization and had exacting service level objectives (SLO). Not meeting the SLOs led to real money penalties for the company. When I inherited the team there was no incentive for anyone to act in any manner that wasn’t everyone for themselves. It took two years of slow nudging to get my leader to understand that organizational structure and policies kept the team from significant improvement. Over time we were able to create a team that met all the SLOs. Note: when a new site manager was appointed the old rules returned and we experienced 100% turnover.
One of the more interesting statements in this chapter is on page 71. “Scrum doesn’t recognize specializations in titles.” Many organizations have a strong degree of specialization in titles, job descriptions, and incentives for promotion and higher pay. The huge proliferation in certifications is a direct reflection of this observation in action. People spend a huge amount of time and effort getting and maintaining certifications. That effort causes people to defend their specializations. That defense left to its own devices generates boundaries (and “it isn’t my role” behaviors). Having a common team goal and holding the WHOLE team accountable for that goal is a good first step at avoiding this team dysfunction.
Next week we will complete the team by diving into the Scrum Master role.
If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems
This Week’s Installment
Week 1: Re-read Logistics and Front Matter – https://bit.ly/3mgz9P6
Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad – https://bit.ly/37w4Dv9
Week 3: Breaking Bad Scrum with a Value-Driven Approach – http://bit.ly/3stGc9Q
Week 4: The Product Owner – https://bit.ly/3qpKvSn
Week 5: The Product Backlog – http://bit.ly/3cAEk9c
