DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

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.

Chase Seibert user avatar by
Chase Seibert
·
Nov. 07, 16 · Opinion
Like (4)
Save
Tweet
Share
9.97K Views

Join the DZone community and get the full member experience.

Join For Free

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).

Other stuff:

  • 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.

Communication tools:

  • 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.

Reducing Risk

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.
  • Break-outs.
    • 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.
  • Hacking.
  • Demo.
  • 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!

teams

Published at DZone with permission of Chase Seibert, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Key Considerations When Implementing Virtual Kubernetes Clusters
  • Remote Debugging Dangers and Pitfalls
  • Why It Is Important To Have an Ownership as a DevOps Engineer
  • Mind Map Reuse in Software Groups

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: