This week is the Keep Austin Agile conference, which has been one of my favorites for the last four years. Cherie Silas and I are presenting a new session called Power Coaching. As professional coaches, Cherie and I incorporate coaching skills into our work as agilists, and we want to help others to do the same. Hope to see you there!
It goes without saying that I love coaching. I am involved in user groups, I attend conferences and camps regularly, and I deepened my skills through intentional practice by becoming a Certified Professional Co-Active Coaches.
There's an energy that is created when coaches come together and share ideas. A buzz, a liveliness. It's exciting and reinvigorating!
I've been fortunate to work with some incredibly talented coaches, and I had a big realization a few months ago: we coaches talk funny. We have our own language. And it can be alienating to those around us.
Working with a pragmatic technical coach, an integral agile wizard, and a Deming-influenced management consultant at a client organization was an exciting and a rich learning opportunity for me. If you listened in on our conversations, you would hear things like:
"How do we design alliances with the teams we are coaching?"
"What's going on from the IT perspective? WE perspective?"
"How do we encourage teams to enhance testing within the sprint to improve quality?"
"What would a statistical quality control implementation look like here?"
Conversations were lively, future-focused, and included constructive disagreements. And then I realized that one person was often quiet: the internal coach we were mentoring. The language we were using was full of jargon and difficult for him to understand at times. And he didn't always feel comfortable asking us to slow down and explain.
Someone we wanted to support very much was being left out.
Reflecting on this, I realized that the coaches I admired the most used words to connect to others. They understood ideas well enough to translate them into natural language. As we learn new concepts, we often get hung up on the terminology and use it often to integrate the learning for ourselves. Once integrated, it's easier for us to ask, "How would help us work together effectively?" and "What practices are supporting us? How is culture helping or hurting?"
Let's be aware of the language we're using and the impact it's having on those around us. A wise coach once told me, "I'm ok with changing the words to help someone else get onboard with an idea. I'm already sold on the idea myself, so it doesn't change it for me."
In any organization, there exist a multitude of processes and activities, and it’s not always clear how the work groups are connected to one another. Each group can optimize its processes, but how does that impact the overall organization?
In helping organizations become more agile, I get to learn about the various ways that people inside and outside of the technology group do their work and how that work fits together. How does value flow through the organization to customers? In order to be more aligned, efficient, and able to pivot, a clear understanding of current processes and activities is needed.
That’s where value stream mapping helps.
I recently facilitated a value stream mapping exercise with representatives from all parts of an organization, IT and non-IT. After explaining the concept and goals of value stream mapping, the group started outlining at the whiteboard how they work today. The first version was high-level and showed how work flowed from one group to another before reaching the customer. A more detailed version highlighted the variety of tools used to manage work at various stages and the complexity of the system. Processes existed for many different workflows, and it was difficult for the group to create a clear visual of how value flowed through the organization. Realizing how difficult it was to see the full system was a powerful discovery on its own. And even without a perfect visual, potential problems and gaps became apparent that could be addressed.
Inevitably in any organization, there are handoffs between groups, redundant activities, and complicated processes. The ability to recognize those potential areas of waste can be difficult. In introducing techniques like value stream mapping, we are enabling transparency across work groups and the ability to make decisions that optimize the whole system rather than component areas. An entire organization can increase its agility when its employees understand how their work fits into the big picture and are able to adapt their work to better achieve the organization’s goals. That’s incredible.
So if you want to help your organization be more agile, consider facilitating a value stream mapping workshop. Invite representatives from the respective work groups, introduce the concepts and goals, walk through an example value stream map, and watch what emerges from the group.
How often do we put ourselves in the hands of experts and trust their judgment to help us?
I've been seeing the same hair stylist for over 10 years. She knows my hair, she knows my lifestyle, and she knows that I'm not going to spend much time styling my own hair. Each visit, I sit down in the chair and let her do whatever she wants. She's not going to give me blue hair or a really edgy style because she knows that won't work in my role as a coach/consultant and with who I am. I don't have to learn what to ask for or suffer the same style year after year. My stylist knows better than me what will work and what the trends are.
When I am picking out new glasses each year, I rely on the employee in the shop to tell me what styles look good and which don't. If she doesn't think a pair works on me, I don't bother to look in the mirror. Styles that I might not have tried otherwise make their way into the pool of options. I feel safer to explore new looks because I have someone who will give me honest feedback. Picking out a different style each year is exciting rather than nerve-wracking or mundane. She knows better than me what will work and what the trends are.
Shopping for clothes and accessories became easier when I started working with a stylist. She knows my lifestyle (work and non-work), she knows my body type, and she knows my budget. I show up to a dressing room full of items for me to try on and consider, and inevitably, there are a few pieces to push me outside of my comfort zone. Not every piece is a winner, and that's great--I tried something and decided if it was me or not. Sometimes the style is flattering and the item just isn't me, and sometimes the idea is great and the fit isn't. I end up with a wardrobe that works for me without the frustration of searching. It's hard to know what will work or not work when you see it on a hanger. Once again, my stylist knows better than me what will work and what the trends are.
It takes effort to become a trusted partner for your expertise. There's deep knowledge and passion for your area and continual learning. Building relationships and a willingness to tell the truth when something just doesn't work. And a focus on the other person over yourself. Those are the experts who experience the joy of a trusted partnership, and it's great when it is achieved.
In working at various companies, I've come across a common concern from managers when we start talking about their teams learning something new:
"How long will we be in the Dip?"
"When will be out of the Dip?"
"How can we avoid the Dip?"
It seems that we've come to understand that learning something new involves an initial dip in productivity or results, and now managers are trying to decide when is the right time for the learning to happen.
THE TIME IS NOW.
In my experience, delaying learning is a bad choice. Clearly the status quo is not sufficient, which is why the subject came up at all. Typically it's around the technical practices learning needed to become a two-star team. It's often not as bad as we imagine it to be, and empirical methods help us evaluate progress along the way.
Promote learning when there is interest or need. Support it when it's difficult. The Dip was not meant to deter us from trying new things. It's about the journey to mastery.
Mike Rieser and I recently co-presented at Houston TechFest, and a recording of our presentation is now available. We talk about why technical excellence matters and some of the things we did as coaches to help an organization avoid technical bankruptcy.
The folks at Agile Velocity were kind enough to interview me about technical craftsmanship and post it online. I feel like I'm occupying a special role as an advocate for technical excellence here. Those who know me realize that I don't consider myself a "technical coach," and I am not the person to look to for hands-on mentoring in technical practices. However, I find it impossible to work in the software development sphere and not pay attention to the technical practices of the teams and organizations that I work with. That's the craft. Whether you know how to write code or not, be in the conversations about the technical practices used where you work and find out how you can support improvement.
I had a realization earlier that struck me as funny.
I've been holding myself back.
Ok, that wasn't the funny part. It was my immediate next thought:
Of course I've been holding myself back--no one else can!
Who else would stop us from our dreams? If it's important to us, we'll find a way. And yet we stop ourselves, hinder ourselves, make things more complicated for ourselves.
I've had this notion that telling people what I want will cheapen "it" if I get it. Like because I had to ask or say something about it, it's less thoughtful or deserved when I receive it. Whatever "it" is. This isn't the same as not saying what you wished for when you blow out birthday candles. This adult version of not sharing what I wish for is holding me back in life!
Where are you holding yourself back?
I've presented a number of different topics at various conferences with different co-presenters, and I thought it would be fun to stretch my skills by trying something new. I've submitted a 7-minute Pecha Kucha on Communities Support Transformation and a 3-minute lightning talk called Coaches Say the Darndest Things. Both formats are outside of my comfort zone, and I'm hoping at least one will be selected for the Agile 2016 conference. If you are attending the conference, please vote for my topics at the links above. I'd love to have a deadline to create and refine the talks by--external accountability helps!
Sometimes I learn new things at conferences and training classes. And sometimes I am reminded of things that I already know.
Two events caused me to see something I knew but had lost sight of:
- Craig Larman mentioned in LeSS class that software developers are trained in computer science programs to gather requirements, design, code, and test, so doing these activities within a self-organizing team is not a big stretch for them.
- Diana Larsen pointed out during the Organization Design Forum that “knowledge worker” is a misnomer for software developers—a better name would be “learning worker” because we are continually learning more about our customers, our business, technology, etc.
Software development is all about learning! That sounds obvious, and in some ways, it is. It is the foundation of our work. Learning is the bottleneck in delivering software. And yet I see organizations try to optimize teams and processes based on knowledge rather than learning. Teams are often designed based on people’s roles, assumed skills, and existing domain knowledge instead of allowing cross-functional teams to self-design based on their understanding of people’s skill sets and social preferences.
I also remembered a few facts about adult learners that further amplified for me why scrum teams can be great learning vehicles:
- Groups learn faster than individuals
- An individual’s commitment is proportionate to personal investment in design
- Highly cohesive groups influence each other more than non-cohesive groups
- People have to see practical connection
How is your organization design supporting learning rather than knowledge? How is it not?