Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
Scrum by definition eliminates multiple swim lanes of input and output, and values individuals and interactions over process and tools.
Is there a danger in having multiple teams within a single team, each having their own requirements before they will work on something? Saving Changes...
Scrum is a team-based delivery approach where ideally work items are completed by any subset of the team. If you have a team of specialists, then additional columns in a work board make sense and you could go further by leveraging the principle of making policies explicit by adding entry/exit conditions for each of those columns.
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
As far as I remember there is nothing on the Scrum definition about to eliminate swim lines of input and output, except that you could you can infer that from the recommendation he makes about the number of team members, but is just an interpretation people can do. On the other side, if you are talking about something Kanban boards remember there is no line inside the Scrum Guide about the tools you have to use, is up to you. Saving Changes...
Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
@Kiron, @Sergio, many thanks for the replies. Most definitely pertinent information.
Marcus Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
I'm a little confused by the question, but certainly, we want the Scrum team focused on their efforts together. Scrum encourages teams to work together toward a common goal, eliminating silos, roles, and hand-offs. How the team forms together to accomplish that can be unique to the given team, and most likely will look different from earlier sprints to later ones as the team matures in their work style, story writing, and ability to delivery incremental batches of value. Saving Changes...
You can have input and output but the thing that concerns me is your part about having multiple teams within a single team that need a lot of requirements before they work on something.
First off, per the Scrum Guide - the ideal team size is 3 to 9 people. and they should have all the capabilities to do the project within the team (meaning, that they should be able to program and test and not have to farm it out to another group)
You can definitely have plans in scrum but the emphasis isn't on plans but rather to start developing and test and learn by doing, which is why sprints shouldn't be more than a month max and ideally 1 - 2 weeks.
There's ways to scale scrum if you have a large team (ie, having mutiple scrum teams all working on different parts of a product) but that's not what I'm seeing from your post. Saving Changes...
Elimination of parallel work is an ideal rather than a rule. It's the same concept as On Piece Flow. When there are multiple concurrent activities occurring, and some type of change is required due to an error or some other reason, rework due to the change is significantly greater.
Eliminating all parallel activity isn't scalable however. In many projects, we simply don't have the time to do everything in a purely linear way. Factories set up parallel assembly lines, computers have parallel processors, and large project teams can consist of smaller project teams that must solve their individual technical problems before assembling the work of multiple teams into a viable project.
We can still focus on the goal of minimizing parallel work due to the risks involved, but when large numbers of people are involved, everyone else can't just stop and wait every time some group of specialists must address a detail level obstacle. Saving Changes...
Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
@Andrew, @Susan, @Keith, very good points mentioned. Many thanks for the input.
