Chapter
6
The Development Team
Change was in the air at a health insurance company where Todd was consulting, and with it came lots of excitement. The executive team had just approved funding a rewrite of a massive customer portal that was plagued with technical debt. The executives had heard great things about Scrum working well in other companies, and decided to make Scrum the project-management framework for the customer portal rewrite.
A leadership team was put into place that included people with a blend of agile and traditional project management experience. They decided that the following competencies were necessary for success: user experience, front-end development, web-service development, database administration, and infrastructure. They also decided that each competency area would have a product owner—and they hired Todd as one of those POs. (If you’ve read Chapter 4, The Product Owner, you know that having more than one product owner for a product is never a good thing, so this decision didn’t bode well for the project.)
Based on these competency areas, the leadership team decided that there should be seven development teams for the project:
| Team # | Team Competency |
|---|---|
| 1 | Database and Infrastructure |
| 2 | Web Services |
| 3 | Web Services |
| 4 | Front End and User Experience |
| 5 | Front End and User Experience |
| 6 | Front End and User Experience |
| 7 | Front End and User Experience |
The leadership team quickly hired people with the various skills required for the project, and the development teams got to work. Four months later, the dev teams hadn’t delivered a single line of code into any environment, let alone production. Proof of concepts existed for each competency area, but there was no full-stack integration between them. As pressure to deliver mounted, the teams started blaming each other for not fulfilling their obligations.
Nine months after the leadership devised their plan for the teams, the project was canceled. Stakeholders were irate over the amount of money that was spent and the lack of results. As a result of the project being an utter failure, 60 people lost their jobs.
There were many factors that led to this disaster, and in this chapter we’ll suggest ways to avoid similar issues on your projects. We’ll discuss various anti-patterns illustrated by this story, as well as other common ones we’ve encountered. Some of the issues we’ll describe are caused by poor decision-making that’s outside the development team’s control, while others are things the team can control. As a Scrum master, you need to be able to tackle both types of scenarios. We’ll teach you techniques that can help ensure your development teams succeed.