Since I've been at Focused, we've evolved in a number of ways: we've expanded our footprint into new cities, zhuzhed up our brand and design to better represent what we do, and we embrace new technologies as they arise. However, there are some elements of our culture that have remained constant throughout my time here. Many of these cultural touch points relate to Extreme Programming (XP) practices.
If you're not familiar, Extreme Programming is an approach to software development that focuses on three concepts: values, principles and practices. Values are aspirational. They are ideals that represent what we collectively like or don't like, for example: open communication, simplicity, or responsibility. Principles are the tether between our ideals and our grounded day-to-day actions. An ideal of communication may find its way into principles like readability, consistency, or self-documentation in software. Finally, practices are what you do: you write your code with clear, descriptive language, you adhere to shared patterns, and you write tests that document behavior. Practices also include certain structured meetings, and at Focused, we have a few of these "rituals" that facilitate getting our teams to work collaboratively right from the beginning.
The First Ritual: The Working Agreement
In her book, The Creative Habit, Twyla Tharp describes the importance of rituals as follows: "It's vital to establish rituals — automatic but decisive patterns of behavior — at the beginning of the creative process, when you are most at peril of turning back, chickening out giving up or going the wrong way." By having a set of common questions that arise on nearly every project, you have a reminder that you've started projects before, you've learned from them, and can deftly get ahead of common sticking points.
Prepare Yourself
The Working Agreement ritual involves brainstorming, discussion and review stages. We find that an hour is the sweet spot, enough to allow discussion and decision-making without fatigue. Rather than one open conversation about anything a team might encounter, we prefer multiple time-boxed and topical conversations because they tend to draw out deeper, more detailed responses.
Since we're brainstorming, of course we're making a big sticky note board (virtual or physical). We divide our board up into the following sections, but feel free to adjust this list as needed: Communication, Collaboration, Team Rituals, Pairing, Backlog/Project Management, Engineering Practices, along with a separate section for follow up actions. Come prepared with a good template or whiteboard supplies, so that your time is spent effectively. If you can, ask a colleague from another team to facilitate, so that every member of the team can focus on contributing.
Get down to business
Once everyone's settled in, we get to work.
Brainstorm- The facilitator sets a timer for ten minutes, and each person adds suggestions on sticky notes in each section (the number of suggestions may need to be capped for larger teams).
Sort the Results - When the time is up, the facilitator will group similar items together. This makes it easier to focus the discussion, and consolidate votes in the next step.
Democracy in Action - The team then discusses the merits of each suggestion within a topic, and votes on the preferred choices for that topic.
Repeat - Review and vote for the remaining topics.
Following the meeting, the facilitator will summarize the primary takeaways based on the voting results. It helps to have the essentials near the top, so that everyone knows the core hours and how to connect with one another, then you can get into the nitty-gritty choices about git strategy or linter configurations. This summary document should be stored in a memorable and shared place, preferably a place that folks voted for in the Agreement.
Make sure the Agreement keeps working
Working Agreements are an essential tool for aligning a team at the start of a project. But as with most agreements, Working Agreements are most useful when periodically updated to reflect the ongoing reality of how the team works. Look for opportunities to re-read and revise the document to keep it current. Great opportunities for revision include:
- New additions to the team - At a minimum, share the existing document with new team members. Updating the document as a team ensures that new folks are considered, and feel a sense of ownership, in the ground rules;
- Policy changes - Sometimes organizational change can include changes to existing processes or tools that your team has agreed to use in a particular way. Discussing the impacts of the change, particularly places where the change might impact communication;
- Drift - Sometimes, plans change once they meet reality, if the team starts to notice a discrepancy between the agreed upon choices and how things work in practice.
The biggest problem I encounter in what people “just know” about software development is that they are focused on individual action. What actually matters is not how any given person behaves as much as how the individuals behave as part of a team and as part of an organization.” - Kent Beck and Cynthia Andres, Extreme Programming Explained
Kicking off a new project is exciting, because there's so much potential. It can also be intimidating: you're meeting new people, in a new context, with new deadlines. By investing an hour to learn about your team's experience and preferences at the project's start, you can ease those new project jitters. You know that your team can effectively communicate, share ownership of the development process, and move forward with the information they need to work together effectively.
Back to Explore Focused Lab