Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Managing development in a 3-tier architecture

Last post 01:25 pm August 14, 2018 by Steven Busse
10 replies
08:49 pm August 7, 2018

I'm the scrum master of the an IT project using a 3-tier architecture.  My team of developers are having trouble completing the work scheduled because as one tier, say the front-end, makes a change, it breaks another tier (e.g. the middle tier).  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 you've experienced this problem, how did you fix it?

 


11:21 pm August 7, 2018

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.


11:29 pm August 7, 2018

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.".

 


11:35 pm August 7, 2018

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.


12:16 am August 8, 2018

 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?


05:44 am August 8, 2018

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.


12:36 pm August 8, 2018

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.


03:17 pm August 10, 2018

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


10:24 pm August 11, 2018

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

+1

The shortest feedback loop to  inspect is the Daily Scrum.


01:34 am August 12, 2018

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!


01:25 pm August 14, 2018

@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?
 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.