Skip to main content

Developers want to organize in front-end and back-end team

Last post 05:22 am August 20, 2021 by Milan Claeys Bouuaert
5 replies
01:12 pm July 30, 2021

Hi there!

Our company is currently struggling to set up a proper structure. We're insisting that we want to work somewhat "scrum", however, our three teams are currently working on one and the same product and instead are splitting work in front-end, back-end and architectural work. As a product analyst, I define fully functional user stories. Very often however does a functional story require both front-end and back-end work to be considered an "increment" for the product. Even worse than that, they want the back-end work to happen first, which means the front-end work can only be picked up a sprint later. 

Does anyone have any experience working in a larger-scale agile company? How do you tackle this if there is no intent from the team to define separate "products" on which a single team can work independently?

Thanks!


04:03 pm July 30, 2021

Has anyone had a conversation with the team? I would expect the outcomes of this conversation would be to first understand why the teams wish to organize themselves in this manner, but also to explain the benefits of organizing into cross-functional teams.


05:21 pm July 30, 2021

What vision do these teams have of the Definition of Done for the product, either collectively or individually? How do they regard the commitment to providing Done work every Sprint?


03:59 am August 4, 2021

this is the problem that i faced during waterfall to agile transformation. tech leads and developers are not aligned to agile culture and insist that this is the only known/best way to complete delivery.  it was also complemented with very large user stories created by PO. a consistent coaching of sr. developers (the influencers) has helped bring some change. i showed them the errartic velocity chart where no story could be marked as done as testers couldnt test anything and some where too much got done. they could see the point then and are trying to get out of their waterfall mindset and rewriting stories agile way. i would say that it is still work in progress


08:11 am August 4, 2021

 tech leads and developers are not aligned to agile culture - Vidya Narayanan

Having phase gating and decentralised teams will lead to miss-understands of core requirements and will introduce bugs, errors and even wrong features to be delivered. It's impossible to get two teams to work as effectively as a single dedicated cross-functional team!

https://www.leadingagile.com/2018/02/applying-brooks-law/

The backend and frontend can be done at the same time but it takes practice. The team will get it wrong, learn, adapt and improve. In the end, they will be faster, stronger and happier as a team. Using IoC, Contracts and even old fashioned UML diagrams to draw out the solution as a team before they head to their keyboards.

As Vidya points out... moving from a waterfall process where a dev puts on their headset and code for 7 hours straight is not the Scrum way. Developers struggle with "meetings", reviewing and refining specifications and even working with other highly skilled developers. In most, developers will try to migrate back to the old model with stealth.

The team should develop a fulling working increment that "could be" used in production should the business choose.

Doing the Database Schema, then the Backend API then the UI, then Testing, then QA, then sign-off, then compliance, then security audit, then documentation, then Operations...... do you see the problem?

A single team can produce a fulling working increment that brings value to the business... "Done Done". The old approach of splitting teams into architecture silos introduces nothing but friction and in extreme cases can cause an "Us vs Them" culture.

Software is amazing, we can dig the foundations, build the walls and the roof at the same time, as long as we all agree on the blueprints. Mistakes are found and fix hourly by the development team's collaboration and the blueprint chanced without red tape. This may feel slower and harder at first, but everyone must put faith in Scrum. No Scrum buts or "somewhat "scrum" but 100% Scrum.

Would you be happy with your heart surgeon being a "somewhat surgeon"...

If the company wants 10X output, If the company wants 6 sigma quality and happier developers; do Scrum.


02:24 pm August 19, 2021

The problem they are facing with a true agile approach is that they cannot align larger architectural work with the small increment deliverable feature. A lot of our codebase requires a large-scale refactor, and adding feature upon feature on a poorly coded fundament ends up with so many bugs that our maintenance is starting to exceed our new development.

If our teams were cross-functional, this would be amplified even further, as both teams would be working on the same codebase constantly. There's no guarantee to the code quality if this is the case. Is there an agile way to maintain code quality of large scale projects?


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.