Please enable JavaScript.
Coggle requires JavaScript to display documents.
Reorganization of development teams - Coggle Diagram
Reorganization of development teams
4.1. Have BSIs solved by BSI teams
BSI often requires deep knowledge and context or they will continue to require external help and/or block the process
Frontend and Mobile do not require full-time BSI team
Maybe we should have a full-time "Fire person" in Backend
BSI teams should be autonomous and independent
Have gamification/rewarding for Fire team
Change the Backend "Fire team" each Sprint
Developers who have finished the Sprint work can give a hand to BSI
Developers who created the bugs should be the ones solving them
We did it in the past with good results
4.5. Assign tasks to developers according to their skills and know-how
Make sure there is always know-how transfer
Yes, the SDR should mark the skills and know-how necessary
The QA tests should also always be a part of the SDR
It's better to have "pair programming" which helps unblocking situations and transfer know-how
This is done already, but the more skilled person is not always available to assist
Some tasks require skills and know-how that always fall on the same persons
It's better to divide teams by functional area
4.2. Assign BSIs to Sprints, as Refactoring
Separate Long term from Short term
SDR and Technical analysis mandatory
Sometimes SDRs are just bureaucracy because it's hard to define and quantify what needs to be done until the bug is found
Only complex BSIs should be worked on as a new feature (SDR, Sprint)
Separate BSIs which become refactors from BSIs which we do not promise to solve in the foreseeable future.
We need to be careful not to create Refactors from BSIs which are then never developed. It's better to say we will not do it.
If possible BSIs should be solved in the current Sprint as long as there is a related feature being changed
Release notes should include information about the solved bugs
We already do that today
Difficult to estimate the time needed to correct a bug, can vary significantly
4.3. Have smaller Scrum teams created around each feature to be delivered
Only for the Backend team which is the biggest one; and divide by functional areas, not by features.
Yes, if the segmentation uses the functional areas as basis for segmentation; it would improve the productivity of the developers and the quality of the sw
Very difficult to manage teams grouped by feature
There should be one high ranked person responsible for the delivery of each feature in the Sprint
May require a framework other than Scrum
Yes as long as several features are distributed throughout Sprints to have a fixed Sprint duration for everybody
Yes because we have often cases of BSIs created in a Sprint which require work in the following Sprints
Yes because the current retrospectives do not help inside individual features
We should have individual Slack channels for each feature
We should use a pivotal person to synchronize with the whole team
QA team members should be included in the feature teams
We can have kick offs per feature
4.4. Consider Fastlane no longer a team, but the right to prioritize a backlog feature
Yes, there should be grooming sessions with the whole team
However Fastlane estimates hours, Backlog estimates SPs
Already today Fastlane is not an autonomous team
Improves the identity of teams (not us and them)
4.6. Have Backend team members dedicated to Frontend, Mobile and Devices
Yes, but rotate those backend team members between Sprints
Rotate them every 3 months
Better to have team members allocated to features
This person would require a very wide know-how about Frotcom
Requires significant support by the Team Leader
4.7. Appoint a Team Subleader in Backend
Maybe just start having experts by functional area, not subleaders
Have squads and squad leads, divided by functional areas
Have each squad behave as a single unit, including ceremonies
Difficult to know if this will work before trying
Compatible with a larger Backend team
Already happening with Marco Agostinho
4.8. Revisit policy for classifying bugs
Redefinition of BSI workflow and SLA commitments
Not all BSI tickets are bugs
Support team needs to be more precise when it comes to classifying bugs
Some bugs reported as Major have been in the system for years
It is paramount to have automatic QA implemented
4.9. Moving from Scrum to other frameworks
No, keep improving what we have
ITMark training during onboarding was lost
Scrum attracts developers
We do not have pure Scrum anyway
We could try Kanban in a single team and see if it works