(This is Part 2 in a 5-part series.)
In our last post we explored these ideas:
- When the organization and the teams explicitly limit their work
- Maintain continuous improvement
- Visualize and focus on the work (not any person)
- And use the board to reflect the actual way the team works (instead of a fictitious process)
When teams use those ideas, they can succeed more often.
We are not just discussing a feature or product team. We’re also using “team” in these posts to refer to the project portfolio team, or a senior leadership team, or any other workgroup or team that needs to collaborate to finish the work.
In this post, we’ll address how we can optimize for the variety most teams and organizations need.
Conscious Local Variations
One of the names considered for the approach that is now called Agile was “adaptive” – a name that was turned down mostly because of name clashes with an existing method.
Does that name make a difference? Maybe not. However, adaptation helps us realize that processes change all the time, according to local circumstances.
This adaptation is at least two dimensional. Even if we start out with the same ideas about the process it will have to be adapted to local circumstances. And then there is the time dimension. If we don’t adapt the process over time that tends to become a problem in itself. Remember: Often yesterday’s solutions are today’s problems.
When we think about adaptation, we realize that processes change all the time according to local circumstances. Each team consists of humans. People have various preferences and needs:
- They might like to start their day earlier or later.
- They might choose to learn new challenges or focus to increase their current knowledge.
- The team might be collocated, distributed (some people together, some apart), or dispersed.
And this is just a small number of the many local variations that might occur. In conclusions this implies that each team needs to discover its own optimal ways of working.
And over time, things change even more. As the team learns about its domain, and how to work together, the team will change how they approach the work. And it’s more probable than not, that this will differ from team to team.
That’s what this “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly,” from the principles behind the Manifesto for Agile Software Development means.
In effect the practice to try one-size-fits-all agile implementations and the effort to compare teams’ performance against each other which we see all too often is the complete antithesis to this ideal.
Standups
Standups have two purposes: they expose various challenges to other people. And, they help the team recreate their micro-commitments to the work.
For example, if a team member encounters an organizational obstacle, the team member can wait until the standup to address this problem. Or, if a team member needs help or support from another team member, the team can decide what to do at the standup.
We find most standups a waste of time. If the team performs daily kaizens, the team often doesn’t need a standup for work or team problems. And, if the team limits their WIP, especially if they swarm or mob, they don’t need standups.
When people work alone, they need standups. When people collaborate on the work, they don’t. It really is that simple.
That said, having standups, especially on a coordination level often proves beneficial if, and that’s a big if, they are conducted as a means to identify weaknesses in the flow and generate insights on the organizational level that couldn’t be found on the team level. This kind of standup usually takes way less than 15 minutes for groups as big as 120 people. This standup is a board-walk, focusing on blockers and exceptions.
Coaching
Today we see the term “coach” almost everywhere in the agile realm. Especially the term agile coach is used quite a lot with a lot of ambiguous meanings. More and more of these agile coaches put a heavy focus on the development of interpersonal change.
Many of those coaches understand coaching as the guidance the coach provides to the client with the intent of them finding their own solution, following the basic stance that “the client is the expert for their problem” and the coach is only the owner of the process. And by this, they mean the coaching process, not any underlying processes within the organisation or team.
Now there are a lot of situations in personal coaching where this stance is the most appropriate one, there are many where it is not.
Johanna once had a coach who said, “The answer is inside of you.” After a frustrating ten-minute conversation, she fired the coach. Her reasoning? “If I knew the answers, I wouldn’t need a coach.”
Even though we feel a lot of sympathy for this kind of coaching, we think it is important to look at how the term came into the agile world and where the analogy came from. The first coach mentioned in the agile literature seems to have been the XP-coach from 1998. And there the analogy was that of a sports coach.
And that kind of coach coaches in quite a different way. Their job is to:
- Intervene when people break the rules or just apply bad practices that could lead to people getting hurt.
- Educate –on the rules, on theory, and on good practices.
- Find the technical strengths and deficiencies of people and devise measures to strengthen the strengths and mitigate the weaknesses.
- And only to a very small part is their job to counsel or to mediate a conflict.
One of the maxims of lean management is “genchi genbutsu”, the “real location.” This is often translated to “go and see” and closely related to the “gemba walk”, walking the shop floor. This requires managers (in lean managers are also coaches) to actually look at the real work that is happening and to understand it. And to reflect upon the real work with the teams.
We see that part often is—understandably—often missing with coaches who focus solely on the interpersonal aspect of coaching and try to avoid anything that seems directive or displays their own knowledge of the problem domain.
But only very few teams come to pair programming, continuous integration or behaviour-driven development just by interpersonal coaching. And you could wonder whether the coach really was open to any solution in these cases. These are things that have to be learned. And trained.
But most of the time even learning them isn’t enough, because without feedback many teams drift off into cargo cult agile. And this is where the coach should come in. Just like a sports coach, the real added value lies in the lean (and agile) experience and product and organizational expertise of the coach. They can spot cargo cult behaviour, point out the consequences, offer education or even devise training plans.
This is true for the whole value stream, from the first inception of an idea through the evaluation of its feasibility all the way to requirements engineering and implementation.
At this point, we discussed flow-based thinking, and how we can use adaptability to create a better team system.
Please return for Part 3, where we’ll discuss how looking at systems can enhance outcomes.
Part 1: How Much Lean is in Today’s Agile?
Part 2: Adaptability Enhances How We Work
Part 3: Looking at Systems to Enhance Outcomes.
Part 4: Explain dates to anyone with forecasts based on your historical data
Part 5: A Little Lean Can Create a Whole Lot of Positive Change
