One of the 12 principles behind the Manifesto for Agile Software Develop is: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This adjustment of behavior can take many forms: from stopping a practice that is not fruitful to simply doing more or less of something already in the system. And sometimes it means starting something new, an experiment to test a falsifiable hypothesis, for example: if we always had a minimum of a dozen donuts in the team room….(See Kaizen).
Regardless of what changes, it is up to a team that embraces agility to figure things out themselves. No external “boss” is barking orders. So this 12th principle leads to the idea that a self-organizing team also needs to be a self-learning team.
Not only are there plenty of ways to go about learning, but there’s also no shortage of topics that a team could seek to gain or acquire knowledge of or skill in by study, experience, or being taught. This led me to the following question:
- What is the scrum master’s role in all of this? How can/should the SM facilitate the team in figuring out what they should consider learning about?
I came across the M3.0 practice of a team competency matrix which seemed to fit the bill nicely. And as an added bonus, the matrix concept scales from individual to team, and all the way to enterprise and provides not only a snapshot of now but is conducive to building a roadmap to the future.
A self-organizing team also needs to be a self-learning team. Click To Tweet
Step One: Build An Inventory
To get started, the SM can crowdsource an inventory. Using any brainstorming tool she likes, ask the team the following questions:
- What do you already know?
- What do you want to learn?
- What skills/competencies do you think the team needs to be most successful, now and in the foreseeable future…
To help keep things somewhat organized, as well as to jump-start folk’s thinking, I suggest setting up three buckets to collect information:
- Languages / Technologies (e.g.: Cucumber, Java, Go, Python, IDE’s, Docker, Chef )
- Processes / Practices (e.g.: TDD, pair programming, Scrum) (Design Patterns, UX, Agile)
- Soft Skills (e.g.: creativity, communication, public speaking, mentoring, coaching, facilitating, networking)
(I’ve used GroupMap.com but just about any survey tool will do.)
Step Two: Build a Team Level Matrix
Once the inventory is “good enough for now” move on and invite the team to cross-reference all those skills and competencies by the individual team members – and include the element of time. Have individual indicate their current level of knowledge as well as their “future vision” using some sort of indicator. A simple model would be:
- Apprentice (heard of it, dabbled once or twice)
- Journeyman (can do it)
- Master (can teach it)
Another labeling system you might consider would be the Dreyfus model of skills development:
- Advanced beginner
Finally, have the team add one additional bit of information to the matrix: the priority of each line item to the team based on what’s on their product roadmap, as well as in their technical debt backlog.
A good ScrumMaster helps every member of the team grow. A great ScrumMaster fosters the team’s growth.
Watts, Geoff. Scrum Mastery (Kindle Locations 1888-1889). Inspect & Adapt.
Step Three: Create Priorities, Slack, and Flow for Self Learning Teams
Using the prioritized matrix the SM can now help the team easily identify any gaps in their bench strength, and from that develop a plan to close those gaps. Perhaps distill things down to a prioritized kanban.
For example, if only one individual on the team has a journeyman or master-level understanding of a prioritized skill, there are opportunities for pairing, and/or knowledge sharing sessions. Additional learning opportunities would be things like external conferences/training programs.
In any event, with the SM’s help, both individual and team prioritized needs have been made visible. And then all the SM needs to do is make sure the following are available to the team:
- Time and place for learning. (See Playtime as well as Sharpening the Saw)
- Necessary resources (books, funding for conferences, software, online subscriptions)
The team then has the environment they need to get going with their self-learning.
Mind you, none of this is intended to be “training” in the traditional sense of HR/PeopleOps. If by chance the team heads in that direction – “Hey, coach, we need us some HR training…” – the SM can offer some experiential learning, run some serious play exercises, set up a lean coffee. etc. Anything but freaking PowerPoint. Please.Provide the team with the environment they need for self-learning. Click To Tweet
Step Four: Get Your Guilds Going
Got more than a team or two? Awesome, now there’s an opportunity for another scale of learning: enterprise level. This sharing of knowledge, skills, and capabilities goes by many names:
- Special Interest Groups (SIGs)
- Centers of Excellence (CoE)
- Communities of Practice (CoP)
- Birds of a Feather (CoF)
Things can be organized around roles, technologies, interests, any common or potentially common ground. By crossing the boundaries of a single team, you’ll increase the possibility of diversity of thought. That alone may not be sufficient, so add to the recipe: good facilitation. Voila: you get to tap into talent and ideas that might otherwise have been unavailable.
What binds these cross-boundary people together will be a sense of passion, a shared knowledge, or desire for knowledge in a domain, and an emerging identity.
Seely Brown, in The Interaction of Complexity and Management, wrote:
When people work this way, barriers and boundaries between people and what they do are often insubstantial or irrelevant, since a collective endeavor holds people together.
Harmonize, Don’t Standardize
Keep in mind that the people in these cross-boundary groups should work towards harmonizing – not standardizing – across the various terrains of the enterprise. The distinction may be subtle, but it is important. While standardization is not out of the question, it should not be the goal.
And however long the group stays together will be as long as it proves valuable to the members.Barriers and boundaries between people and what they do are often insubstantial or irrelevant. Click To Tweet
Dive in deeper to the topic of guilds and huddles:
Visualizing the Complex Emergent System
There are a couple of fantastic tools for visualizing and enabling these interactions at the enterprise level.
Weave The People
Check out this weave that pools people by specific talents.
Imagine using “weave” for strength discovery, to match apprentices with masters across an organization! To do as Esther Derby advises: help teams have each member to be doing one thing, learning another, and be teaching a third.
Unpacking Team Diversity
Another fascinating look comes from Harvard University, Unpacking Team Diversity: An Integrative Multi-Level Model of Cross-Boundary Teaming. This model provides a framework for exploring the complex emergent system of cross-boundary teams. While diving into this topic is beyond the scope of this post, I encourage you to take the time to read the article and in particular drill into “Figure 1” which provides an extremely important lens for a coach/facilitator to look through when supporting these kinds of cross-boundary learning teams.
Step Five: Measure
How can you tell if these experiments have aligned things with the strategic goals of the organization? How can one tell if anything has improved? Simple: Measure…
There are many ways to measure the outcomes of the experiments explored in this post, from individuals to team, to enterprise learning. Some starting points could be:
- Happiness and engagement
- Employee retention
- Quality of value delivered
For more on measurement, see: Team Metrics and Agile Team Happiness
Step Six: Make Self Learning Teams VisibleInstead of protecting ideas, open-sourcing allows for fluid exchange and evolution... Click To Tweet
Visibility and transparency at all levels – individual, team, and organization – will do many things:
- Enable collaboration across boundaries
- Build momentum
- Drive interest
- Enable constraints
Knowledge sharing, lean coffee, open space are all wonderful ways to start.
What might happen if we took this visibility yet another layer wider? Across organizations? Too radical? The open, public, and free exchange of ideas and technologies speeds innovation. Open platforms like wikis, social media, and open-source hubs allow for sharing across disciplines, use cases, and organizations.
Instead of protecting ideas, open-sourcing allows for fluid exchange and evolution – and building upon existing platforms. For more, see: Where Good Ideas Come From)
Nice post! It emphasize the essential steps to develop an organization towards agile teams in a learning environment. Still, it requires a person willing to lead the teams to explore their possibilities rather than dictating the teams what to do 😉