Managing development in a 3-tier architecture

Hi Jill - A possible solution may be to reorganize the Scrum Teams, by working with the organization and other Scrum Teams to move from component teams to feature teams.  Is there a way to get all the Scrum Team members together and ask the Developers how they might self organize into cross functional teams that span the 3 tiers?  Of course the Scrum Masters may want to set some framework boundaries (e.g. optimal team size 3 to 9).  Ken Schwaber has written about Development Teams self organizing this way.  This would save a lot of integration work and remove a lot of dependencies.

Here is some background on the difference between component and feature teams: Feature based teams are cross-functional in nature and have the ability to deliver a "Done" Increment that spans the entire vertical technology stack for their given product's architecture (e.g web client, middleware, database layers), whereas component based teams are specialists that usually focus on one architectural layer of the technology stack (e.g. web).

The advantages for feature teams include being able to deliver a "Done" Increment of features which are potentially ready to be released each Sprint, have less dependencies and hand offs with other teams (fewer hand offs decrease cycle time), and have fewer integration challenges. Feature teams offer more transparency as there is no unknown or undone work left.

For disadvantages, feature teams may slow down if someone with a needed skill is in vacation or leaves the team. For component teams, the advantages are that the team may be able to solve more complex issues because they are comprised of specialists who focus on a limited set of technologies, and they can absorb vacation or an employee leaving. The disadvantages are that they usually have dependencies with other component teams and handoffs, deal with more integration issues, and have to rely on other teams to release an entire feature which results in unknown or undone work.

Don't forget, if your teams self organize into feature based teams, get together after a few Sprints to inspect and adapt, and make necessary changes.

And if you are only talking about 1 Scrum Team working on all three tiers and you are having these integration issues, you will want to look into vertical slicing the work (compared to horizontal slicing).  Delivering a small thin vertical slice of an Increment will help solve many of the integration issues.  That's why the Scrum Guide mentioned that the "Development Team is cross-functional, with all the skills as a team necessary to create a product Increment.".

Absolute guess here?

So, you have a Web\API team? What’s your Middleware platform? You said you have a Database team.

My 1st thought is you are not a cross functional team you just think you are at least today. Team members could be working in a void and not collaborating. You don’t sound like you are communicating enough. Maybe they do not understand the stories and just say yes to everything. Another thing in this instance sounds like you are missing testing upfront think TDD Test Driven Development. Do you have any kind of automated testing? Are you using CI\CD Continuous Automation Continuous Delivery?

Ae you a small organization?

I’d suggest if your teams are slacking on the testing talk to the team about that. Write test before you even code (TDD).

Check your DOD (Definition of Done)

You may have to mother them on collaboration and communication for a bit to get them talking.

What’s coming out of your retrospectives? This should not be blind siding you.

 My team of developers 

I guess you are only talking about 1 Scrum Team working on all three tiers. 

Before giving advice, I would like to know:

Have you ever attend their Daily Scrum and observed how they discussed the issue?

Have you ever attend their Daily Scrum and observed how they coordinate and assign the day's work?

Is the development team satisfied with the current mode of cooperation?

Sometimes it's the middle tier or database people that break the code.

I'm wondering what I can do to help them be more efficient.

If people are organized around tiers, then you can only reasonably expect them to care about tiers. To deliver integrated and working features, they would need to be organized that way instead. Each team would have to be able to build a feature-complete and working increment without external dependency. They’d need all the skills and resources to do so, and to integrate and test work continually with each change.

Thank you for all the feedback.  To clarify, we are a small start up scrum team. We are developing a brand new application.  My team has two front-end people (angular 6) - one of which is a full-stack developer.  We have two middle-tier (C# .Net) developers, and 2 database guys. 

The team has been working together since April.  We are still trying to figure out what works. 

Thanks again for taking the time to provide guidance.

Mhm, then it does sound like you need to communicate / coordinate more...

then it does sound like you need to communicate / coordinate more

+1

The shortest feedback loop to  inspect is the Daily Scrum.

Hi Jill,

Most important direction has already been mentioned. You should cut depencencies and move to feature teams instead of component teams in your organization. You replied that you are working on a new application with new technologies. Why don't you consider to cut dependencies by using services of cloud. You can spin up a database and application hosting platform within a couple of hours to host your application on. For example using Azure WebApps and Azure SQL DB (of which I am experienced with) or using AWS Elastic Bean Stalk (i think) and AWS RDS Postgress/Maria DB. 

When using a CI/CD setup (takes you some time) using for example VSTS or GitLabCI, you can focus on developing your application, and not worry about infrastructure.

From your story I cannot pinpoint what the real issue is here. Is it team related, outside team/organizational related or technology related? 

Next to technology suggestions, my most important advice to you and your team is, is to claim ownership of your product fully. This includes the hosting of your application. You want to be in control of how your angular code interacts with your database for example, you want to be in control of scaling of your frontend hosting etc etc. 

Happy to hear what your next steps are!

@Jill



The Sprint Planning is often separated into Planning 1 (Plan what to do) and Planning 2 (Plan how to do it). How to coordinate the work to be done, so the whole feature can be implemented on all tiers in a single sprint, should be part of planning the "how" as well. This is especially crucial when not having a team of full stack developers.

Questions you might consider asking here:



- What exactly breaks between the tiers?

- Is there a way to find out / define what will be broken before actually breaking it?

- How could this help reducing the risk of breaking stuff during actual development?

- Could it help to parallelize the work to be done on each tier?