The hierarchy is at the very center of our lives. We have experienced it in our school years and later when working in organizations. It’s existence and function is tacit in our understanding of reality.
At the Agile Alliance Change Agents workshop in Chicago in November, it became clear to me that the existence of hierarchy was greatly influencing the sessions. I sensed that there were two broad themes that emerged from the sessions.
One theme was around exploring Agile in the Enterprise. In this context, hierarchy was assumed. And much of the attention and energy seemed to be about finding ways to rise above and minimize the constraints it imposed. For example, how to shift focus on end-to-end flow.
Perhaps, the most insidious aspect of this is that our default assumptions around the hierarchy – it’s existence and requirements form the context of our thoughts. Just like how people are constrained to perceive reality in the movie the Matrix: we do not see or question it.
A second theme that emerged was around considering ways to create workplaces of joy – environments that foster an Agile mindset rather than constrict it. Agile provides a clear compelling model for organizing work and people. It does not, however, address the problem of organizational design: how to hire, promote and fire. How responsibility and leadership is enacted and enabled. This is an open problem. Included in this theme are questions such as team self-selection vs. deploying known patterns (e.g. Scrum). We need to find solutions to this so we can escape the Matrix.
First and foremost, I would like to thank the Agile Alliance for sponsoring this workshop and Diana Larsen for inviting me. I would also like to thank the whole group since these themes were an emergent result of all our combined questions, sharing and curiosity.
As a caveat, I am not trying to summarize all that happened, but rather provide one perspective.
The following diagram is a powerful mental frame to help understand change efforts within organizations. It makes the discernment between tactical, strategic and cultural levels. One way to use the diagram is to position each change item or activity on the line to show what aspect it is focussed on.
More importantly, I use the diagram to engage with clients to explore what they want to achieve, why they want to achieve it, and how invested they are in the outcome.
Some typical benefits are listed above the line. Most importantly, break-through results only come from culture – not tactical or strategic approaches.
- Tactics – “How do we work?” is about day to day practices and process elements. These are things that a team or organization can adopt.
- Strategy – “What do we want to achieve” is about aligning the company around key goals and initiatives.
- Culture – “Who do we want to be?” is about clarifying the organizations reason for existing as well as it’s values and vision.
Relationship between the levels
Culture is the foundation that Strategy and Tactics sit on. But culture is like an iceberg – a powerful force that is underwater where you can’t see it. Sure it’s possible to work at the levels of tactics and strategy, but that is unlikely to make any lasting change or draw great benefits. Lasting change requires working at all three levels so that the tactics and strategy support the culture.
Relationship to Leadership Agility
Bill Joiner has identified a number of distinct mindsets that can be found with managers/leaders. and his work on Leadership Agility. The following are one to one mappings from types of leaders/mindsets:
- Experts focus on Tactics: problems and work execution.
- Achievers focus on Strategy: outcomes and the system.
- Catalysts focus on Culture: vision and break-through culture.
The deepest inspiration comes from Bill Joiner and his work on Leadership Agility and the different levels of focus. This served as the basis for my model.
I would like to thank a variety of sources for the notion of Culture being mostly hidden – I have seen or read this in a number of places but most vividly from the folks at Crucial Conversations and their book Influencer in particular.
I am grateful for Mike Cottemeyer for helping me understand the difference between Agile Adoption (Tactical) and Agile Transformation (Cultural).
Here is an infographic on “what is a team?”. I created it to help explain the concept in an upcoming workshop. Now I think it will be part of my basic Agile training.
- Shared Purpose or Goal
- Team Boundary – who is part of team and who is not.
- Shared responsibility to achieve the goal
- Shared work and shared results
- Maybe 5 or maximum 8 people on the team.
This was inspired by the discussion of a team at Value, Quality, Flow. They drawn on lot’s of influences, so hard to list them all here.
This post is about some important thoughts on working with organizations that I learned from Michael Spayd, co-founder of the Agile Coaching Institute, some time ago. A key part of my learning is about the value of acting as a mirror to a team or organization when working as a coach, influencer or internal change agent.
Systems are made of People
The infographic below summarizes key elements.
Act as a mirror
Michael expressed the effectiveness of a coach who acts as a mirror to reflect a system back to itself. This can help a system become more aware of itself and act with choice. He gives the example of asking – “Do you want to be a great team?” and noting that the choice is up to them.
A powerful exercise is to ask the team to visualize themselves as if the team were an entity. This can be used to guide the team to a powerful future state.
A final word of caution is not to try and “fix” the team. Any lasting change requires that they heal themselves: it is critical that we see them as resourceful and capable to facilitate this. The alternative is to leave the system in a “better” state, but less capable of learning and growing than when we started.
A variety of differences in perspective can be used to mirror what is happening to drive insights and learning: management perspective vs. staff, present vs. past or future, team vs. group.
Look at the larger system for solutions
The concept of a holon can be used to think about what level of the organizational we are considering: individual, team, group or company. The central idea is that problems can only be solved at the next level up. Wikipedia has this definition: “A holon is a system (or phenomenon) which is an evolving self-organizing dissipative structure, composed of other holons, whose structures exist at a balance point between chaos and order.”
I would like to thank Michael Spayd for increasing my awareness of what is possible and improving my dynamic range as a coach change agent. He has helped start a multi-year journey of learning and growth.
I want to share an infographic and related narrative that has really helped people emotionally connect with the importance and challenges of sustainable software development practices. I usually show the landscape in a quick introduction to Agile; in two day trainings, I go through an in-depth narrative and discussion.
Sustainable Engineering Practices
The diagram shows technical excellence at the peak of the mountain. The elevation indicates the level of challenge associated with the practices and a reasonable sequence of adoption.
Narrative to Connect at Emotional Level
Here’s an excerpt of the conversation I have when discussing this topic during training:
Michael: Let’s talk about technical practices. How important is version control?
Participants: It’s really important. We use <something>.
Michael: What do you think of someone not using version control?
Participants: High risk, wasteful, unprofessional
Michael: OK, so version control is part of the minimum standard for professional software development. Get a sense of how important it is for you to help someone not using version control.
Michael: Extreme Programming is a part of Agile that is about sustainable software development. This diagram (show diagram) shows the key practices. I am sad to inform you that the bar for what is considered the minimum for professional software development has moved. And this happened over ten years ago. (Dramatic Pause). Where does version control fit on this diagram?
Participants: Before coding standards.
Michael: (explain diagram/practices)
I almost always get questions about Pair-programming: “Why do we need it?” or “It seems like it would help earlier. Why is it later?”. My answer is as follows. Yes, it really helps to do pair-programming from the start. It is a great practice but it is tricky to get people to buy-in. Pair-programming is located before the sharp ascent required to scale the mountain. The practices here require intensive learning and are difficult to achieve without pairing.
This is a critical topic for anyone building software. See Inventor’s Dilemma and the Design-dead core for another perspective and motivation. For an in-depth simulation to help people experience this, Alistair McKinnell and I created the Sustaining Agility Game.
I am deeply appreciative of Alistair McKinnell for developing this infographic with me when building our TDD course.