Teams vs Tiger-team

Get Started. It's Free
or sign up with your email address
Teams vs Tiger-team by Mind Map: Teams vs Tiger-team

1. Remaining in our teams

1.1. What?

1.1.1. Keeping our team together provides many benefits that will help the altogether deliveries be better and quicker.

1.2. Why?

1.2.1. The value of the product is higher at cost of harder communication and more work coordinating.

1.2.1.1. I don't feel we need to change the way things are done because a project wasn't carried out or communicated correctly.

1.3. Considerations

1.3.1. Conways Law

1.4. Pros

1.4.1. An engineer is amongst engineers that study and do what he does, they grow together in their skills

1.4.2. Team is constructed in a way that if they need help with what they are doing they are surrounded by people who can help.

1.4.3. Quickly add or remove resources on a specific project based on project needs.

1.4.4. By working in same code assures same code standards are being practiced.

1.4.5. Group decisions to change how the portal functions are discussed as a group with input from all who would be affected.

1.4.6. In a pinch or time crunch it is really easy to swarm around something, break it into parts and divide the work.

1.5. Cons

1.5.1. More coordination from management on what team is doing what and when.

1.5.2. Harder to track project statuses

1.5.3. Harder to sync communications amongst those working on the same projects

1.5.4. More siloed knowledge of the product and less ability to work with other teams when designing solution. No new ideas since you are working with like minded inviduals

2. Creating a Tiger-team

2.1. What?

2.1.1. We create a permanent team of engineers who are to be given projects that include all teams so they can more quickly communicate and release.

2.2. Considerations

2.2.1. The outcome of Speaker Talk Down

2.2.2. End of the day you still report to same manager, that wont change

2.2.3. We are still able to reach out to "home team" and get help where needed

2.3. Why?

2.3.1. By having colocated resources we reduce communication issues and the outcome is quicker releases

2.4. Pros

2.4.1. Communication between parts is improved due to daily meetings and a team with no other distractions.

2.4.2. Ability to Account for Contributions of all cross functional disciplines and their unique needs/considerations

2.4.2.1. Tiger team got credit for speaker talk down while most of the work was done outside that team

2.4.2.2. Getting credit is a continual motivator for the team.

2.4.3. A smaller team will be able to pivot and work on different things quickly without needing collective planning across teams

2.4.4. The ability of one team to see a project from start to finish with all of its parts

2.4.5. Teams ability to focus on single task/project

2.5. Cons

2.5.1. You're creating Frankenstein code where the tiger team individual is doing their own thing.

2.5.1.1. If each piece of the web portal can be manipulated by a single person on another team, the outcome could break the efforts of the webdev team, so they would have to make sure communication is there.

2.5.1.1.1. This defeats the advantage of creating a team to improve communication. So now instead of each team communicating with each team, each member of tiger team has to make sure they communicate everything they do to the respective teams.

2.5.1.2. We need to have coding standards and documentation

2.5.1.3. Every point here to be scrutinized under the lenses of

2.5.1.3.1. Speed to Market

2.5.1.3.2. Quality at Release

2.5.1.3.3. Uniformity of Code

2.5.1.3.4. Meeting all Criteria of End-User

2.5.1.3.5. Ability to Account for Contributions of all cross functional disciplines and their unique needs/considerations

2.5.2. Having multiple people in different teams working within the same areas of code could cause unknown merge conflicts.

2.5.2.1. Every point here to be scrutinized under the lenses of

2.5.2.1.1. Speed to Market

2.5.2.1.2. Quality at Release

2.5.2.1.3. Uniformity of Code

2.5.2.1.4. Meeting all Criteria of End-User

2.5.2.1.5. Ability to Account for Contributions of all cross functional disciplines and their unique needs/considerations

2.5.3. Who handles errors on the site? We would need extra level of discernment to decide if bug was introduced by tiger team or main team, this spans all aspects of the company and every team.

2.5.3.1. Each product is owned by a tiger team, if team is dissolved then the product team over that area would handle, the engineer who did that work would be part of that product team

2.5.3.2. Every point here to be scrutinized under the lenses of

2.5.3.2.1. Speed to Market

2.5.3.2.2. Quality at Release

2.5.3.2.3. Uniformity of Code

2.5.3.2.4. Meeting all Criteria of End-User

2.5.3.2.5. Ability to Account for Contributions of all cross functional disciplines and their unique needs/considerations

2.5.4. If Webdev team member gets his part of the project done, he would have nothing to work on.

2.5.4.1. The engineer without work to do would return scrum team

2.5.4.1.1. could throw off velocity with people coming and going

2.5.4.2. Grab points from a scrum team to bring into the tiger team to be worked on

2.5.5. If the needs of webdev are the equivelent of say 80 points, that would take the webdev team 2 sprints, that would take a single member, now part of tiger team, about 10 sprints

2.5.5.1. code is no longer released quicker since you only have one resource per element. Would work if every piece of every project was small enough for one person to carry out in the allotted time.

2.5.5.2. Team built based on needs so extra engineers would be brought in

2.5.6. Webdev doesn't have a volunteer, we would be forcing an engineer to leave a team they like to do something they didn't want to do.

2.5.6.1. Every point here to be scrutinized under the lenses of

2.5.6.1.1. Ability to Account for Contributions of all cross functional disciplines and their unique needs/considerations

2.5.6.2. From Tom's experience, they didn't want to go, but then didn't want to leave once there. they liked getting the credit for their efforts

2.5.7. If a senior member of a team were to leave the team to join the tiger team, their skills and abilities to help junior members, of the team they were on, are gone.

2.5.7.1. Every point here to be scrutinized under the lenses of

2.5.7.1.1. Speed to Market

2.5.7.1.2. Quality at Release

2.5.7.1.3. Uniformity of Code

2.5.7.1.4. Meeting all Criteria of End-User

2.5.7.1.5. Ability to Account for Contributions of all cross functional disciplines and their unique needs/considerations

2.5.7.2. You could bring jr with sr to do pair programming

2.5.7.2.1. you also now have 2 engineers who could troubleshoot and work on product they finished

2.5.7.3. If this is an issue with Tiger teams, it would also be a huge issue with scrum teams that if that engineer changed jobs we'd be in trouble

2.5.8. The work we do on webdev is tested by our offshore help in a coordinated effort. We would somehow need to assign work to the qa's of the different teams to test that part of the functionality

2.5.8.1. QA needs to be reevaluated no matter what

2.5.8.1.1. no end to end testing is happening in scrum teams method

2.5.8.2. Assign a single qa to the tiger team that would know and be able to test all parts

3. Other considerations

3.1. How we got here

3.1.1. Cross team collaboration is lacking

3.1.2. Prioritizations change daily

3.1.3. Poor communication of changes in priorities going to everyone affected

3.1.4. Accountability for dependencies fall on other product owners and sometimes their needs aren't enough to influence teams to change

3.2. Speaker talk down

3.2.1. Tiger Team saved the project

3.2.1.1. Because all the resources were on the same team and met daily, the project was a success

3.2.2. Tiger team wasn't necessary if we had the right focus and attention to the weak spots.

3.2.2.1. Daily we would have scrum of scrum meetings in which we would ask about speaker talk down and the response was always "they are working on it" but that was as far as it went.

3.2.2.1.1. A new board was created to monitor cross dependencies opening up communication as to the actual deliveries and where the stories are at.

3.2.2.2. Maybe Steve L. was involved in the tiger team daily stand up. That provided motivation, if he participated in that person's team stand ups before tiger team, the same motivation would have applied.

3.2.3. Testing wasn't carried out on certain elements of the project

3.2.4. Priorities changed for certain people and they worked on other things instead of speaker talk down

3.2.4.1. If product owner had kept those resources focused they wouldn't need to be on a tiger team

4. My conclusion

4.1. The problems we are trying to solve aren't going to go away by adding another team. Coordination between that team and the parts it will affect will still have to happen. Growth amongst tiger team members in their own areas halts. Changes in the areas they come from will happen without them knowing and the final result is chaotic code with added work in managing and maintaining the different sections.

4.1.1. We have solutions in the works and they should resolve a lot of these items.

4.1.2. With maybe the need of a single person over projects each time. A project manager to help coordinate the efforts between teams.

5. Steve's Needs

5.1. Every point here to be scrutinized under the lenses of

5.1.1. Speed to Market

5.1.2. Quality at Release

5.1.3. Uniformity of Code

5.1.4. Meeting all Criteria of End-User

5.1.5. Ability to Account for Contributions of all cross functional disciplines and their unique needs/considerations