Tiger Team Survival Guide: Part I
Tiger Team Survival Guide: Part I
A tiger team is a group of experts brought together for a project. Chase Seibert provides further explanation and a sample schedule for working as a tiger team.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
A tiger team is a diversified group of experts brought together for a single project, need, or event. They are usually assigned to investigate, solve, build, or recommend possible solutions to unique situations or problems. They are almost always populated with mature experts who know what's at stake, what needs to be done, and how to work well with others. Their strengths are diversity of knowledge, a single focus or purpose, cross-functional communications, decision-making sovereignty, and organizational agility. Once their venture is completed, they cease to be a team and usually go back to their previous assignments.
Based on the time, I got three days notice that we need to ship two new mobile apps in five weeks.
Scope, Time, and Money
As an engineering manager, you can typically have some input on the scope, time, and resources allocated to a project. This is a variation of the pick two problem. When the project scope and timeline are largely dictated by business needs for a high priority project, resourcing may be the most flexible factor.
If possible, identify a short list of veteran engineers with specific skill sets who can make the project successful. Talk to their managers and get buy-in. Work to alleviate any concerns that the individuals may have about what you're asking from them and whether their existing projects will fall on the floor.
Some specific resources to think about are senior talent (whether it's back-end or front-end), making sure you look at planned vacation time, and DevOps in general. You should also consider outside experts and contractors who might be professional trainers in an area that you need help in on short notice, as well as what support you can get from project management. Are you planning on making a deep technical contribution yourself, or focusing on organizing and leading? Lastly, make sure you have 100% alignment on the KPI for the project.
The War Room Model
A natural instinct on a short schedule is to find a private space where the team can isolate themselves, have persistent wall space for collaborating, and cancel all other obligations within reason.
Try deputizing a specific person from workplace Ops and have them handle logistics such as:
- Find a room big enough for the team, with room to spare. Should have ample whiteboard space and a monitor. Nearby breakout spaces and or extra standing desks are ideal.
- Make sure people have badge access if needed.
- Increase lunch order size if you're moving offices.
- Plan on canceling all your own meetings except direct report one-on-ones, one-on-ones with your boss, and critical status meetings.
Potential IT requests:
- Extra monitors, keyboards, mice, and power strips in the war room.
- Any new hardware you might need (test devices).
- Ask recruiting to cancel all interviews for the team.
- Ask for support when engineers go to clear their calendars.
- Block off everyone calendars with individual all day appointments.
- Using one all day appointment that spans days or weeks is likely to be ignored by people booking conflicts.
- Create a Slack group.
- Create an email distribution list.
- Create a JIRA or Trello board.
- Create a Google Docs folder.
- Start compiling a list of important team links and put them on a Trello card, pinned to the Slack channel topic.
What dependencies do you have on other teams? For engineering dependencies, try to get a dedicated domain expert on the tiger team. Are the APIs you need to use publicly accessible? Do they require some specific authentication and scopes or do they return results that are too highly tailored to another use case?
Start thinking about what you need to do for security sign-off and start thinking about what you need to do for compliance sign-off.
Have design start with high-level mocks (not pixel perfect). Get the flow nailed down ASAP.
What kind of existing code will you be able to reuse? Does the re-use require another team to refactor something?
What is your analytics and data integration plan?
Sample Kick-Off Day Agenda
Here's a sample kick-off day agenda that you can use to help you plan your session and be done by 6 p.m.
- Start at 10 a.m. sharp.
- Intros (5 minutes).
- Business context and goals.
- Initial mocks share out.
- Have a large format print-out to can put on the wall and write on.
- Define milestones.
- What is everyone hoping to get out of this experience? Write it down as a list on a wall.
- Working agreement (whitelist of outside meetings to attend; brainstorm how to move fast and create a speed list; create a technical debt list; create a big decision list).
- Process: define how to work (working hours, daily stand-up, pairing, consider code reviews, multiple merges a day, daily demo).
- Pair assignments and component ownership.
- Lunch at 12 p.m.
- Code reuse strategy.
- Front-end architecture: how to break things into components.
- Back-end architecture: high-level system capabilities needed.
- Code layout and separation of concerns: write it down, eventually copy to README.
- Done at 6 p.m.
Make It Fun
Don't make it a death march. Plan to work reasonable hours and have some fun activities mixed in.
Stay tuned for Part II!
Published at DZone with permission of Chase Seibert , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.