Notes for the book Build - Elements of an Effective Software Organization by Rebecca Murphey and Otto Hilska, can be read online from the link.
Brief summary & thoughts
- Good collection of insights on effectiveness
- Quite much in common with the books
- Here only own notes on topic level, check the book for details on various topics
1. Introduction
- They approach effectiveness by breaking it down to three concepts
- Business outcomes (discussed further in Chapter 2)
- Developer productivity (discussed further in Chapter 3)
- Developer experience (discussed further in Chapter 4)
- Three essential principles
- Empowered teams - Teams able to make autonomous decisions about their work
- Rapid feedback
- Outcomes over outputs - Focus on value and impact (outcomes) of engineering over volume or efficiency of deliverables produced (outputs)
2. Business Outcomes
- The structure of an organization plays an integral role in how well the organization can deliver business outcomes.
- By dividing into teams, an organization can take on more complex problems and tasks while effectively delivering business outcomes
- A team should be substantively able to deliver value to the organization using only the resources of that team.
- (Discussion on team design, different teams for different purposes etc)
- High-performing teams require time to form, good leadership to remain motivated, and clear areas of ownership and autonomy.
- Balancing engineering investments
- Adaptation of Matt Eccleston's framework for balancing and budgeting engineering resourcing
- Organization's work is categorized into main new ares
- New things (creating new features or services)
- Improving things (enhancing current features, services and business processes)
- Keeping the lights on (KTLO, maintaining existing systems and services)
- Productivity work (making it easier to get work done)
- -> Creating a shared language to use across various organizational roles.
- A healthy blend tends to include at least 10% for productivity work and between 10% and 30% for KTLO work.
- (Discussion on balancing these areas etc)
- OKRs (The Objectives and Key Results) - A framework to communicate
priorities
- Described in John Doerr's book Measure What Matters
- A tool for communicating priorities across an organization and tracking progress on those priorities.
- Part of using OKRs responsibly is accepting and explicitly acknowledging that they will never cover the full scope of work that should be happening.
- OKRs must be a part of larger discussion involving investment balance and organizational design
3. Developer Productivity
Many things that slow down work are systemic, not individual.
- E.g. time wasted bouncing work between teams, shelving half-competed features etc.
In the book, developer productivity is considered in the context of how organizations can minimize the time and effort required in the software delivery process to create valuable business outcomes.
Productivity table stakes - three clear ways of working seen on any highly productive team
- Limited queue depth
- Small batch sizes
- Limited work-in-progress (WIP)
One of the best ways to achieve developer productivity involves improving the quality of the product through automated testing.
Frameworks for thinking about productivity
- DevOps Research and Assessment (DORA) framework (see also the book Accelerate)
- Note: The aim isn't to become obsessed with numbers but to continually evaluate whether you're satisfied with what the numbers are telling you.
- The DORA framework is not a diagnostic tool - it doesn't point out
bottlenecks in your processes.
- It's much like having a compass - It will tell you what direction you're heading in, but not what obstacles lie in the way or how to navigate around them
- SPACE
Framework - An attempt to create a more comprehensive tool
- Five critical dimensions: Satisfaction, Performance, Activity, Communication & collaboration, Efficiency & Flow
There is no definition of productivity that boils down to keeping an eye on a few simple metrics. Measuring productivity is actually pretty hard.
Even when the intent of measuring productivity is to improve team and organizational effectiveness, individual engineers can still be concerned that the data will be used against them.
- There’s a pervasive worry that these metrics could translate into some form of individual performance review, even when that’s not the intended use.
- This concern can contribute to a culture of apprehension, where engineers might be less willing to take risks, innovate, or openly discuss challenges.
- Any perception that the data will be weaponized for performance purposes can doom an effectiveness effort. Say that you won’t use the data to target individuals and mean it.
Cycle time
- The term comes from manufacturing processes, where cycle time is the time it takes to produce a unit of product and lead time is the time it takes to fulfill a delivery request.
- In the context of software development, we're talking about the time it takes for code to reach production through development, reviews, and other process steps.
- The most important flow metric
Some measures to avoid / be careful with
- Story points
- Originally meant as a way to help teams get better at splitting work and shipping value
- These units have been abused ever since as a way to directly compare teams and steer an organization toward output-based thinking.
- Often helpful to be more disciplined about limiting queue depth and WIP
- Utilization - Often there is aim to have engineers 100% occupied
- As utilization approaches 100%, cycle times shoot up and teams slow down.
- You’ll also lose the ability to handle any reactive work that comes along without causing major disruptions to your other plans.
- Story points
Tools and tactics
- Interruptions - Before you do anything else with developer productivity, ensure there’s general agreement on reducing interruptions.
NOTE: Especially in this chapter, quite much discussion close to Flow-Based Product Development
4. Developer Experience
- One of the critical concepts in productivity is flow.
- Uninterrupted time is the building block of flow
- Fighting back interruptions
- Eisenhower matrix can help to categorize interruptions and then devising a strategy to handle each category effectively
- Meetings
- The underlying cost of a meeting isn’t limited to its duration; it extends to the interruption of deep focus and to the trust that the meeting either creates or erodes.
- Time limits - Long meetings tend to hurt more than they help. Conversely, a series of shorter meetings, with time to reflect on each, is more likely to result in powerful outcomes.
- Asynchronous collaboration
- To be successful at working asynchronously on decisions, it’s useful to specifically define how you’ll handle them.
5. Putting It All Together
- Convenient fallacies to avoid
- "We aren’t doing enough up-front requirement-gathering."
- "What we really need is more people."
- "We just need to plan better."
- “It doesn’t work that way here.”
On Change management:
- BICEPS framework
by Lara Hogan - Everyone needs six things
- Belonging - The need to feel part of a community
- Improvement/progress - The desire for personal and professional growth
- Choice - The need for autonomy at work
- Equity/fairness - The importance of equitable treatment
- Predictability - The preference for stability and certainty
- Significance - The desire to do meaningful work.
- A few things you can do to earn trust around a change effort
- Offer social proof that this change has been valuable elsewhere
- Run a pilot or proof of concept with a small set of teams.
- Participate in the process you’re trying to improve and experience the difficulties first-hand.
- Celebrate successes widely and loudly, and incentivize the change you want to see.
No comments:
Post a Comment