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 - topic covered here.
- Reduce and limit batch size - covered here.
- 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 re-organize.
- Set a clear, attainable and small goal for the team, and focus on it
- Finish what you started
- Measure - reporting needs to be tied to the team’s goal, and 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.)
- Accept imperfection, shipping code that is not perfect.
Set product management practices
- Manage priorities based on economic framework. 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 important being that it’s a product (because ROI is a product) 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. If it’s not the case, tune the framework to set the priorities straight instead. 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), or bad organization (which means improvement is needed).
- Question the function of meetings, systems and processes. 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 also contributing).
- Enforce high code coverage expectations
- Enforce code reviews
- Pair programming
- Profess engineering practices - SOLID principles, OOP, SoC, etc.
- March 28th - decision framework. Delivery pipeline