“We need an API team and a UI team”
Are you serious?— Episode 36
Scrum Teams need certain attributes to be effective. For example, they need to be cross-functional, and capable of delivering a potentially useful product increment every Sprint. Without these abilities, we lose many of the benefits that Scrum has to offer, and take on significant risk.
Cross functional teams
“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” — Scrum Guide
A Potentially useful product should always be available
“Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.” — Scrum Guide
This is solid advice. If teams are set up with all the skills they need to accomplish something, and deliver incrementally every sprint, doesn’t that sound like they’ll be set up to deliver ever increasing value to customers… sprint on sprint?
This all sounds great! So… what’s the issue? Let’s just set up our teams for success, right from the start, right? How could we even think about getting this one wrong?
Well, one way to get this very wrong would be to set up teams as Groups of Specialists: a UI team and an API team, for example. Please please please, and please again: don’t do this if you are planning on adopting Scrum.
We need Incremental Deliveries of Done, not Task Completion
This team structure creates an environment of task orientation, where team members just complete parts of the job and say things like “my piece is done.” However, the product increment is not done, because dependent work has been neither done nor integrated. Where is the customer value in a piece of UI that mocks out necessary communication with the database? Or a wonderful pluggable API that isn’t actually plugged into anything yet…
Team structure like creates the need for an ‘integration phase’ downstream.
Doesn’t that feel a lot like Waterfall? Scrum Masters should be squirming in their seats reading this. With this team setup, we delay an opportunity for empiricism, we fail to acknowledge complexity, and we push risk downstream. These are all contrary to the objectives of Scrum.
In relation to team setup, this is one instance where the Scrum Guide can be applied quite directly. The advice offered by Sutherland and Schwaber is extremely practical, and has been consistent since the guide was first written. Check out the revision history, this point has been solid since day one: organize development teams so they can get work completely done.
If your Scrum Teams are made up of one type of specialist, and those guys are completing technical tasks that require integration in later Sprints, then you’re getting Scrum wrong. This is a Waterfall approach, and if your environment is complex with either difficulty of agreeing requirements, or challenges in how to build them, then you need to either:
- Change your team structures, or
- Accept the risk of a Waterfall approach in a complex environment.
Failure to see this risk could lead to real problems for your organisation downstream. This risk is a fundamental part of Dave Snowden’s Cynefin sense-making framework: the need to avoid an assumption of simplicity. We can take that risk, but we may end up with a chaotic result in future.
Teams of specialists like a UI team and an API team include a tacit assumption that “we’ll just have to integrate later, but it will be fine.” Well… we won’t know until later… are we happy to take that chance?
On the other hand, if your teams are structured to be cross-functional, and capable of delivering a potentially useful, done version of a product increment in every sprint, then they avoid that risk, learn earlier if there are issues with delivering the product to customers, and get the opportunity to inspect their work and adapt, early and often.
In other words, cross-functional development teams that are capable of delivering a potentially useful product increment every sprint will be set up for success with Scrum.
