In Practice: How a Team Found the Power of Purpose
In this story, Diana Larsen illustrates how a small group of information systems employees was transformed through an understanding of its true purpose. The group maintained the operations, hardware, and systems support for the primary website and delivery system of a nonprofit organization.
Diana worked with the engineering department of Bright Future (not its real name), a nonprofit organization that supports and encourages the work of other nonprofits and activists around the world. The department had invested in agile team chartering for its five development teams and its help/support desk group. The operations group had patiently waited its turn for the same attention.
Today was the day! Sven, the director of technology (DT) and leader of the engineering eepartment, had crafted a preliminary purpose statement for the team. The team would see his work for the first time in its chartering meeting. The participants could only spare a half day, so Diana had planned to facilitate a purpose chartering session, along with some alignment activities. They would finish the rest of their first charter at a later time.
Let’s Go!
Diana, the group, and Sven gathered in a conference room. She laid out pipe cleaners, sticky notes, and other meeting supplies, and briefly described their agenda. Next, the DT presented his preliminary purpose in a wiki document on the large display screen used for video conferencing.
First, the group discussed the product vision with Sven. Diana reminded them of the light-switch analogy from What Does Your Product Do?. In the group’s view, Sven’s preliminary vision seemed more like a description of the work of the team, rather than an inspiring picture of the world they were helping to create. Diana offered examples of other teams’ purpose statements. As they read through the other charters, Jim said, “Reliability stands out to me in this one. It’s important to us too.” Li chimed in, “It’s probably the most important thing we do. Wouldn’t it be good to highlight our intentions for website accessibility?” Juan added, “I read about an IS group that changed their job titles to site reliability engineers. Isn’t that just what we do? Make sure our site is reliably available? That would be cool.”
New Titles, a New Team, and a New Purpose
Sven jumped in, “You could have that as your job titles if you like. What if you became the Site Reliability Engineering Team?” The three team members looked at each other and grinned. They liked that idea.
Diana turned their attention back to describing their product vision. They quickly shifted to talking about their product as an always available website and tools. In short order, they rewrote their vision to say, “Bright Future’s website and online services are constantly available for anyone in the world who wants to do good work for others.” Diana felt goosebumps. Team members smiled even more broadly. They sat up a little taller in their chairs.
“What’s next?” they wondered out loud. Diana asked Sven if he could support changing his product vision to the one the team liked. He agreed readily.
Next up was working on the team mission. Looking at what Sven had written and what they wanted to incorporate from the former vision, the team used sticky notes to write phrases that fit and assembled them like puzzle pieces into a mission statement that described all aspects of their work. They massaged the mission until everyone could say it was good enough to begin working with. The mission they described included work like “We guarantee availability of our online products now and into the future by proactively surfacing and resolving security issues, infrastructural bottlenecks and inefficiencies.” and “We provide the development infrastructure that allows engineers to develop, QA, demonstrate and validate their productionbound work, as well as support, tools and guidance for automated, continuous regression testing.”
Their work on team mission flowed into a discussion of mission tests. After describing the features of mission tests, Diana asked them to work in two pairs to propose tests. They wrote eight tests on sticky notes, then dot-voted on the three to five tests they wanted to adopt. In the end, they accepted four tests, including “By Pi Day we have defined a clear technical path to cloudify a bucket of stuff to achieve a clear external outcome.” The team had a lot of fun with choosing dates for their tests.
At this point, Diana asked the team and Sven, “Is this your initial draft purpose?” She showed them how to test their agreement with the proposal. Li said she still had questions and wasn’t ready to agree yet. Everyone else was enthusiastic, including Sven. Diana asked Li about her questions. “How rigid is this?” Li asked, “What if we find out it’s not right? Do we have to stick with it anyway?”
Diana explained the process that other Bright Future teams had used for revising their purpose statements. She emphasized the importance of the purpose reflecting new information whenever things changed. Li changed her vote to enthusiatic support!
Working Agreements
A half hour remained for creating a set of initial working agreements. Again, Diana described what working agreements would do for the team and how to use the sticky notes for proposing them. Each sticky-note proposal would finish the phrase: “We work together best when…”
The team had five minutes for individual thinking and writing, then posted the notes on the whiteboard. Two ideas were very similar, and the writers agreed to put them together. The team proposed six working agreements in all. Once again, they dot-voted for their favorites. Only four working agreements received votes. Another round of voting and the whole team accepted all four agreements.
During the discussion and voting, Sven was adding their new purpose and working agreements to the wiki document on display. Everyone could see it growing.
Wrapping Up and Moving Forward
Time was up. Diana asked the team members to take a sticky note or two and give written feedback on the session. She posted a flip chart page with Do Again and Stop Doing at the top. On their way out of the room team members stuck their feedback notes to the chart. One note said, “This was fun and so helpful. When do we get to do it again?”
A year later, the team had lost and gained members. Along the way it had updated working agreements, passed and failed mission tests, and taken on new ones. The original remaining member advocated with Sven for another round of chartering: “It’s the best way to bring new team members up to speed. We need to incorporate their new thinking.”