Software engineering is complex. A team of software engineers increases the complexity through their interactions with one another and other components of the business. Through an understanding of the principles and a set of tools built using data from real world teams, we can begin to tackle this interesting problem.
Process
The Agile Manifesto
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto and the Twelve Principles behind the Agile Manifesto.
Team Topologies
- How Teams are Structured: Stream-aligned, Enabling, Complicated sub-system, and Platform teams.
- How Interaction Happens: Collaboration, X-as-a-Service, Facilitation interaction modes.
The Team Topologies framework.
ShapeUp
A team process toolbox that addresses the following:
- Team members feel like projects go on and on, with no end in sight.
- Product managers can’t find time to think strategically about the product.
- Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”
The ShapeUp framework.
Continuous Integration / Continuous Deployment (CI/CD)
One of the most effective ways for a software engineering team to work and ship code together.
Dave Farley's CI/CD channel is an excellent resource for learning CI/CD.
Behavior Driven Development (BDD)
- Connects Engineers to the Users of the Software.
- Reduces the size of feedback loops.
- Supports CI/CD.
- Unit of Isolation is the Use Case/Behavior, not the Class/Function.
Behavior Driven Development as described by the Agile Alliance.
Principles
Cognitive Load
Everyone has limited resources, from the software user to the software engineer, and even the software engineering team as a whole.
See the 'Laws of UX' for a deeper dive into what Cognitive Load means.
Metrics (AKA Key Performance Indicators, KPIs)
Individuals and Teams require a clear definition of how they are measured. These measurements must align with business goals and outcomes.
If either is unbalanced or unknown, it destabilizes the team and the product. Individuals and Teams will optimize the metrics you define, or they will optimize what they assume to be their metric if you don't define them.
The DORA metrics are a great starting place due to the behaviors they encourage in teams.
Quality & Velocity
Quality is required for velocity, and velocity is required for quality.
See Martin Fowler's article on whether Quality is worth the cost.
Feedback Loops
A team with a shorter, faster feedback loop will produce better results than a team with significant feedback loops in the same amount of time.
Workshops, not Meetings
Simply gathering individuals together into a meeting doesn't guarantee success.
I use the term Workshop because it means that the meeting has a clear purpose, goal, and structure.
For example, Pip Decks has a great Workshop deck that has informed how I setup structured collaboration.
The value of the 'meeting' must exceed the cost and be 'right' for the team.
Data
Data can be used to inform us what works and what doesn't, as opposed to anecdote or preference.
The DORA Accelerate State of DevOps Reports
A yearly survey of companies across the spectrum of software engineering.
DORA has been investigating the capabilities, practices, and measures of high-performing technology-driven teams and organizations for over a decade.