Developers want to organize in front-end and back-end team
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!
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.
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?
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
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.
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?