My set of reference points and practices to make teams faster
Work in progress alert: this is an ever evolving list.
What we’re looking for is:
- restore the productivity of the process
- increase happiness of team and stakeholders, ever so slightly
- decrease the cycle time to a level that helps keeping focus
- form habits, around simple principles
- target for team self-sufficiency
- Reduce and limit work in process.
- Reduce and limit batch size.
- Delivery pipeline needs to be automated and ran with total confidence, which means often.
- Limit interruptions - create a human interface to the team (yourself / the product manager / the manager / etc.) that prevents (or at least reduces) context switching for the productive team members
- Prevent scope creep - create the habit of iterating rather than inflating current scope
- Reduce overhead - reduce the number of meetings, the complexity of the process, the number of items, etc.
- Leave room for the team to self organize.
- Drive the team from crazy to calm.
- Define the team’s overarching goal as something measurable and focused on value-creation. This is the most effective way I have found to help a team enhance.
- Explain the measurement as a clear and attainable intent for the team, and focus on it.
- Measure accomplishment
- reporting needs to be tied to the team’s goal, and needs to be exciting.
- This needs to be organic, and link daily work with business results (e.g. subscriptions go up, money comes in, response time goes down, etc.)
- As such, target needs to be a lead indicator or success, as opposed to a lag metric. (e.g. measure accessory attachment rate or cart conversion-rate, which are calculable on short duration, rather than monthly/quarterly revenue, which happen on longer term and might be influenced by external factors such as seasonality or marketing campaigns). Validate at least correlation between lead and lag metrics periodically to ensure lead metric relevance.
- Finish what you started, or abandon quickly and consciously.
- Iterate with the smallest increments possible.
- Accept imperfection, ship code and features that are not perfect but improve understanding.
Set product management practices
- Manage priorities based on economic framework targeted at the team’s goal.
- e.g. Use a simple formula like where is a log scale based on an order of magnitude of cost (10 = it’s gonna take minutes, 4 = it’s gonna take hours, 3 = days, 2 = weeks, 1 = months) and is a fibo-like number from 1 to 10 depending on your business, it can be something like the time it saves for customers (for a SaaS) or how much money you plan to make out of a feature (for an eCommerce platform).
- The formula should be a factor (because ROI is a factor) and that it drives the discussion to what’s the value of things rather than what’s the priority.
- Prevent exceptions to the economic framework.
- One frequent concern with economic framework is that it doesn’t take small items such as bugs, tech debt or small features into account. But the cost log scale is there for that reason. Small items that bring some value bubble up to the top of the queue.
- Tune the framework to set the priorities straight instead of bypassing the framework. Small items that don’t bring any value stay at the end of the queue and should die out.
- Ensure sufficient functional decomposition of features so they guarantee small batches and low WIP. Economic framework also help with natural selection, features too big are staying far low in the queue. The way to prioritize them is decompose.
- Be courageous and close items that won’t get done - features that don’t bring value, bugs that you will likely never get important enough to be fixed.
- Keep short backlogs. Long queues have a high processing cost, and drive frustration. They’re the result of procrastination and delaying of conversations about value.
- Resort to cost of delay for prioritization if value is not easy to observe. Cost of delay is the periodic money you will loose (or theoretical money you won’t make) if the work item is not done.
- Deadlines are for justified reasons only (contractual obligations, communicated release date).
- Estimated dates are noncommittal and called “forecasts”.
- Forecasts can be wrong.
- Missed forecasts can mean bad estimation (which is not important), unforeseen circumstances or bad organization (which means improvement is needed).
- Question the function of meetings, systems and processes. Ask:
- why estimating?
- Why doing standup?
- What is the value we get from it?
- Is it useful?
- Set liberation rules: optional attendance to meetings, 2 feet rule, work from home, flex hours, remove stupid policies and formalities, etc.
- Measure process efficiency with time in process.
- Practice right-to-left Kanban standup. Question is “how do we move that right”. Decide next action for each item in the board (this also enforces low WIP).
- Set up team-wide testing and team-wide code review to help with moving items right.
- A decision framework helps decentralizing the decision process and increases team autonomy. Discuss how you determine priorities rather than giving them (economic FW).
- Enforce high code coverage expectations
- Enforce code reviews
- Push for trying pair programming
- Enforce a branching model that works (e.g. atomic change flow)
- Profess engineering practices - SOLID principles, OOP, SoC, etc.
- March 28th - decision framework. Delivery pipeline
- July 2019 - clarity.