This chapter is from the book
This chapter is from the book
This chapter is from the book
Coaching & Community
Try...Central coaching group
In some of the enterprise-wide adoptions that we have seen, an internal agile or lean coaching group was established, consisting of hands-on agile experts who go and work with directly with teams. Try that.
Form a cross-functional coaching group to learn the diversity of perspectives and issues and to build support for change in more diverse areas. For example, include product management, software development, hardware development, field service, sales, manufacturing, marketing, and more. That said, in the early days of adoption, the focus is typically within R&D and product management, so the original scope of coaches is usually limited to these areas.
Caution—Avoid a group that has formal authority to mandate practices, policies, and processes. Rather, create a group that focuses on coaching people interested in adopting agile or lean development.
Try...Concentrate the coaching on a few products
Genuine learning and change of behavior within a product group takes a lot of coaching and time. Plus, misunderstandings are easily created without sufficient coaching. We have seen product groups flounder because they received only a smattering of occasional education. It is better to concentrate the attention of the internal coaching group—supplemented with external coaches—on a few products. Only move on to new groups after solid mastery in old groups.
Try...External agile coaches
Good external agile or lean coaches are worthwhile because they bring fresh perspectives and ideas, sometimes have more credibility than internal coaches (even if not justified) and can therefore make a quicker change-impact, and they can "speak the unspeakable." Also, ...
Try...Pair external agile coaches with internal ones
When external coaches visit, pair them with internal coaches. There are several advantages, including
- learning from each other—for example, the external coach will learn things about the enterprise—policies, politics, and so forth—that would otherwise be difficult or slow to grasp
- increased learning in the broader coaching network—the two coaches connect each other to broader networks (internal and external) which share and learn from one another
Avoid...Advisors/consultants who are not hands-on coaches
Big companies often have a centralized process or improvement group. The people working in this area sometimes drift away from doing hands-on development and become PowerPoint process consultants. Avoid people like that in an agile or lean adoption initiative. Similarly, watch out for consultants or coaches who may not have read the foreword to the four agile values:
- We are uncovering better ways of developing software by doing it and helping others do it. (emphasis added)
Some 'agile' consultants do not directly develop software with the teams—coaching agility and lean thinking at gemba. Rather than doing it with hands-on developers and practicing Go See, they sit in rooms presenting or reviewing process diagrams that may have little to do with what is really happening, or they write emails speculating about problems and their solutions. Managers and consultants may be pleased with the agile PowerPoint process, but the reality on the ground is different.
Instead, develop a cadre of internal and external agile/lean coaches who apply Go See and who are masters of the real value work (programming, testing, ...). These coaches and consultants spend most time with engineers while coaching, and only occasionally leave gemba to meet with senior management—bringing their insight of what is really happening at gemba.
Try...Structured intensive curriculum for all teams
For example: At one of our clients the focus is on lean development plus agile engineering practices. In collaboration with management, we set up (and coached) the following curriculum for development people (organized by team). There are intervals of several weeks to several months between each step:
- Short warm-up e-learning (web-based) courses that focus on basic concepts and terminology related to lean thinking.
- Lean development-1 (LD-1): Five days in classroom with class projects, with an emphasis on hands-on doing.
- LD-2: Five days in a structured workshop with teams, applying the skills from LD-1 to their real products, and learning some new skills. A coach mentors. The workshop is in a separate location from their normal work environment.
- LD-3: For five days, a coach visits the team at their normal work area, reinforcing LD-1 and LD-2 skills in the context of their day-to-day work, doing pair work, and facilitating workshops (such as Sprint Planning).
- LD-4: Same as LD-3.
Thousands of people are involved in this multiyear coaching endeavor, and the leadership's commitment to in-depth meaningful lean and agile coaching is an illustration of the foundation of the Toyota Way: manager-teachers who have long-term constancy of purpose with lean thinking.
Avoid...Internal agile/lean cookbooks
"Let's write an internal agile cookbook so that all the people can better adopt agile development in our company." It sounds like a good idea: more efficient, more harmonized, ... But we have seen—through Go See with the teams—the subtler dynamics at play...
- It reduces critical thinking—people assume that if something is written in a corporate-sanctioned guide, then it is good.
- It reduces challenging the status quo—people assume that what is written in corporate guides should be accepted or followed, rather than challenged.
- It reduces learning, especially good agile/lean learning—high-quality agile, lean, and Scrum teachings have been written in books by founding thought leaders; but rather than study these original sources for good learning, people assume that secondary corporate guides contain reliable insight.
- (Related to prior point) it increases misrepresentation—in the interest of 'harmonization,' internal process writers revise these systems... "let's remove self-organizing teams from our agile description—people won't like that."
- It reinforces the corporate illusion that system problems can be solved with processes and process documentation.
- If there is an internal group that only writes documentation, and the people in this group do not do hands-on agile coaching, then (1) what is written is undesirable because it is not based on experience, and (2) it perpetuates more overhead work away from gemba.
A group at Toyota described their early documentation effort, and what Taiichi Ohno thought of that:
- So we went to work on preparing a systematic description of our [Toyota] production methodology. ... Ohno, of course, hated that kind of deskwork. If he saw people poring over written work like that, he'd tell them to get out onto the plant floor. So the team couldn't do its work within his sight... [SF09]