Adaptability Enhances How We Work

Added to Process

(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.

Who coaches what in an agile organization?

Here’s a situation we see too often: The coach—external to the team—has significant information about how to work in a lean or agile agile way. The coach coaches the people as individuals and as part of a team. No one coaches the managers to understand how an agile approach changes what the manager can look for, and what the manager can and should measure.

That external coach might coach the manager, too. Although we don’t see that occur often enough.

What might lean thinking offer us with coaching? Why wouldn’t the manager coach the people on the team to learn how to think about their problems? Why wouldn’t the people coach each other? Why wouldn’t individuals and the team coach the managers?

When we move coaching from either part of the hierarchy or external to the team, we can create a more congruent approach to the whole coaching problem. And, we support managers who learn about the team’s problems, and how the team can solve those problems. We also support teams who can learn about the manager’s problems and how the manager can solve those problems.

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

About the Authors


These days Michael spends most of his time supporting clients in their quest for more effective ways to work, mostly by applying lean and agile concepts.

He has been running his own company since the mid-80s and moved his focus from implementation to organization in the mid-90s. Working in a all kinds of industries from pure software development companies to public administration, he has not yet seen a project where architecture and processes where not of crucial importance.

He organized several conferences around organizational aspects with regard to software development, plays active roles in community efforts (Limited WIP-Society, iSAQB-Commuinty), is a published Author, a previous editor in chief and a frequent speaker at European conferences.


Johanna Rothman, known as the “Pragmatic Manager,” offers frank advice for your tough problems. She helps leaders and teams do reasonable things that work. Equipped with that knowledge, they can decide how to adapt their product development.

With her trademark practicality and humor, Johanna is the author of 18 books about many aspects of product development. Her most recent books are the Modern Management Made Easy series, From Chaos to Successful Distributed Agile Teams, and Create Your Successful Agile Project. Find the Pragmatic Manager, a monthly email newsletter, and her blogs at jrothman.com and createadaptablelife.com.

 


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.

Agile Connect

Agile Alliance Learn

Agile Alliance Share

Stay Up-to-Date!

Get updates on Agile events, programs, and more by subscribing to the Agile Alliance Newsletter.

Recent Posts

Agile Coaching Network Signup