A dream team is one in which all of your colleagues are extraordinary at what they do and are highly effective collaborators. The value and satisfaction of being on a dream team is tremendous. Our version of the great workplace is being on a team that you learn the most, perform your best work, improve the fastest, and have the most fun.
Within a dream team, collaboration and trust work well because your colleagues are both exceptionally skilled at what they do, and at working well with others. In describing selflessness we say “You make time to help colleagues. You share information openly and proactively.” We want new colleagues to feel very welcome and get all the support they need to be effective.
Value is software customers are using.
Software is available to the customer. Owned by Engineering.
Software is valuable to the customer. Owned by Product.
Maximize value. Value is software available to customers.
Minimize not value. Everything else is wasteful.
Things that are Done are Value
Things that are In Progress are cost
Productivity is focusing on one task.
Minimize interruptions and context switching.
One prioritized backlog per team.
A team works on one project at a time to enable focus.
Each sprint, select a buddy.
Every task should have at least two people. Two people working on the task ensures the task gets to Done quickly. There's no single point of failure. Cross training is another valuable aspect of the buddy system. Code reviews will be faster as the buddy doesn't have to context switch to review the code. Having a buddy working on a task provides emotional support and psychological safety as there's two people responsible for completing the work.
Work on one task at a time.
Stop starting, start finishing. WIP limits encourage us to finish work that’s already in process before introducing more work into the system. The more work teams try to juggle at once, the harder it is for them to take work to the finish line.
Buddies are empowered to determine how to best collaborate on each task. Ideas:
- One writes code, the other reviews.
- One writes the business logic, the other writes tests
- Pair programming. One writes code, the other observes and guides. Roles can be switched anytime.
- One designs the APIs, the other implements
We believe that people thrive on being trusted, on freedom, and on being able to make a difference. So we foster freedom and empowerment wherever we can.
Tasks are pulled from the prioritized backlog.
Tasks are not assigned before being started. Any task can be worked on by anyone.
After a task is finished, ask if there's anything you can do to help an in progress task. For example coding, reviewing, or testing.
The goal is to maximize completed tasks. Code reviews have priority over writing code.
Speed of Code Reviews
At Google, we optimize for the speed at which a team of developers can produce a product together, as opposed to optimizing for the speed at which an individual developer can write code. The speed of individual development is important, it’s just not as important as the velocity of the entire team.
https://google.github.io/eng-practices/review/reviewer/speed.html
Optimize the sprint process methodically using retrospectives.
- What went well? (Celebrate / Continue)
- What could have gone better? (Learn / Stop)
- What are we going to improve for next time? (Try)
- What did you do today?
- What do you plan on doing tomorrow?
- Okay, any obstacles?
Link to supporting documentation, GitHub tickets, etc.
- The Tyranny of Metrics
- Netflix culture
- The Machine That Changed the World: The Story of Lean Production-- Toyota's Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry
- The Goal: A Process of Ongoing Improvement
- The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity