Self-Organising teams
Hi All,
One if not the objective of Agile and Scrum is to produce an efficient self organising team.
But something struck me when considering this. If you have say a team of 5 and within that there are 2 coders, 1 tester, 1 UX and 1 BA. If there are 3 stories going in to a sprint then is there not a possibility that there will be waste during the sprint regarding each developer's time? All 3 stories require the input of all team members.
Lets say we have to create a widget for a website. When UX guy starts mocking up how this may look what do the coders and testers do? And again with the other 2 stories there could be a wait while for each role within the team as.the UX guy needs to do their thing?
I know I am oversimplifying the complexities of the relationships between team members but it highlights that in theory the team may not be as efficient as we may think?
It sounds like you're trying to do your BA first, then all your UX, then development, then test everything. Is that Agile or is that Waterfall?
You missed one key part of the definition, as specified in the Scrum Guide:
Scrum Teams are self-organizing and cross-functional.
While all developers have their specialties (testing, coding, UX, BA) they are still all developers under the umbrella of Scrum. Sure, you might not want your testers changing mission-critical code, but that doesn't mean they can't create test cases for current and upcoming stories, or that your UX guy can't help review code or improve test cases.
You might also consider breaking up stories further. Rather than creating a full web page mock up, then developing it and then testing it, create a mock up for the navigation bar, then while that's being coded, work on mocking up the footer or page content. While you run a risk of breaking up your stories too far to be useful, breaking up the tasks into smaller pieces can help reduce downtime.
And if that doesn't work, what else is on the Product Backlog that can be tackled in this sprint? If there's really this much down time, it sounds like you might be able to accomplish more stories during that downtime.
I know I am oversimplifying the complexities of the relationships between team members but it highlights that in theory the team may not be as efficient as we may think?
Coming back to this, you're right. Scrum, as it's written, is pretty and paints a perfect picture. Scrum in practice is much dirtier. Scrum requires a very big shift in business culture and traditional structure to work as intended. Try telling a Project Manager "Scrum says there's no need for Project Managers" and see how well that goes over. In practice you need to adapt to a variety of skill sets, changing teams, and oversight and respond accordingly.
Scrum is efficient. The organization implementing "sort-of Scrum" may not be doing so efficiently.
What do you think a self-organizing team ought to do, if they observed that skill-silos like these resulted in waste?
Remember that in Scrum the Development Team role has no sub-roles - members are simply "developers".