values

Beware Of Identity Theft During Agile Coaching

All Agile coaches eventually face the stiff headwinds of resistance to change. Counter-intuitively, coaches themselves can trigger some of that resistance by inadvertently performing wide-scale identity theft. It is something I have done, and you may have too. This article explains what identity theft is, provides some concrete examples, and looks at a few approaches to mitigate the issue.

What It Is

Coaches need to acknowledge that people derive their identity in part from what they do. A quick look at what LinkedIn and Twitter users put in their profile demonstrates the point: author, database administrator, director, entrepreneur, hacker, manager, programmer, statistician, etc. People put a lot of energy into creating their identity. Therefore, any change management initiative that threatens that identity, whether knowingly or not, will be met with resistance.

Concrete Examples

Here are some examples of identities that Agile coaches are susceptible to attack:

Coaches frequently form teams of people and urge them to swarm on issues. This is done for good reasons. Nonetheless, how might it come across to people who have spent the previous ten years becoming experts in a given technique? Take the developer who specializes on the Java stack, who attends advanced training, who eagerly awaits and learns the features of each new release of the language. How does that person view the suggestion that she should learn and fumble with front-end development or database schema optimization? What does it do to her self-image of being an expert?

Most Agile methods do away with big up-front planning for a more just-in-time (JIT) approach, which is very sensible in situations of high uncertainty. However, we shouldn’t be surprised that a JIT approach triggers an adverse reaction on the part of people who are professional planners. You may have met Lucy, the program manager, who is the go-to resource for any questions related to Microsoft Project. How will she feel about the idea of abandoning detailed planning?

Then there is Mark, the software architect, who can produce exquisitely detailed system functional documents for the team to implement. And there is Stephanie, the lead quality assurance engineer, who authors thick test plans for other people to execute. As a coach, you may have inadvertently devalued the activities with which they associated the most. A similar thought process applies to other roles such as the traditional manager, the financial planner, the requirement translating analyst, etc.

Modified Coaching

One way for the coach to avoid the identity theft land mine is to lead with principles and values, not solutions. Let’s hark back to the example where a coach might propose swarming. An alternative approach is to see if the team members prize speed. If they do, might they have ideas for how to increase it? Frequently someone will suggest swarming, but you may be surprised with other creative approaches. The point is that if the idea originates from the team, it will be more readily accepted, and the coach will no longer be the source of friction.

Lightweight Method

There are many Agile methods out there, each with their pros and cons. In environments where identity theft is a concern, a coach would be well advised to consider a method that can be rolled out with minimal disruption.

One method that is careful to reduce disruption is Kanban. Just look at the first step of deploying it: “visualize the current workflow”. No change required to getting started. David J Anderson, chair of LeanKanban, goes a step further and proposes “respecting existing roles, responsibilities and job titles” as a change management principle. In environments where the willingness to change is not a given, this seems like wise advice.

A Little Sensitivity

In summary, it is critical for Agile coaches to recognize that people identify with what they do and that change management efforts sometimes threaten that identity. A thorough Lean/Agile transformation affects many traditional roles and will thus have many opportunities to step on identity-based land mines. Coaches are therefore urged to exercise sensitivity and use a principle-based approach. In environments where the appetite for change is limited, coaches should consider using methods that minimize disruption. Doing so should make the path to enhanced business outcomes smoother. What other tips do you have to ease people into the notion that their role may evolve?

Works cited

“Id Card”, by Creative Stall, The Noun Project, Web. 4 Apr. 2016. Modified.

What Executive Support of Agile Means

Executive support is often touted as one of the most important, if not the most important pre-condition for a successful organizational transformation, be it Agile or otherwise. I agree. However, the nature of that support is not frequently defined. Worse still, I believe it is for most part misunderstood, especially by the executives themselves. In this post I cover some aspects of that support as I’ve encountered it in the wild.

What It’s Not

Let’s start with one thing executive support is not: a passive state. Support does not mean merely tolerating Agile (or Lean, or whatever; I’m not a stickler) in the organization, or just giving the green light for other people to change. It is not something to be exercised from a distance through intermediaries. I understand this may come to the great chagrin of some executives who were content to let things happen down there, way below them.

No, executive support is an activity, a role, a contact sport. The main reason is quite simple: organizations have a tendency to mirror their leaders. Thus, by definition, if an executive does not adopt Agile-compatible behaviors, neither will the organization.

For example, it is critical for the executive to decree new, Agile-compatible values for the organization, and articulate the reasons why they are being adopted. If a senior leader cannot explain the sought-after benefits of the transformation, it will be difficult for employees to see the transformation as anything other than a passing fad. One caution: the leader should stop shy of instituting a specific Agile method. This is for the rest of the organization to figure out. Not only is the executive not in the best position to know which method is called for, but also the organization would then be even more susceptible to blind mechanical adoption (i.e. Cargo Cult).

Active Support

Indeed, the identification and decision about which specific Agile method the teams will use should be pushed down to the lowest possible level. Ideally, it’s a determination best left to the teams themselves, after they’ve received a modicum of education on Agile values, principles, and methods. By pushing that decision down, the executive shows support by starting to demonstrate attributes of servant leadership, a mindset that will have to be internalized by many people in the organization if it is to maximize its potential. (We touched on servant leadership in this article.)

Another critical area where an executive demonstrates support for the transformation is on new and evolving job roles. For example, the Scrum method calls for new titles, like Product Owner and Scrum Master. Those roles will have to be defined in their scope and career progression, and proven “safe” for the first few employees who raise their hands for these roles. Correspondingly, some historical roles will evolve, sometimes a lot. For example, the traditional project manager who does a lot of intermediation may now be deemed counterproductive. Similarly the micro-manager and the lone wolf engineer may no longer be viewed as assets. Indeed, if an executive tolerates historical behaviors that are now harmful to the new culture, employees will deem this a lack of commitment. They will note the irony when their commitment is then sought. Moreover, the executive has to make sure that the good people, whom the rest of the organization knows better than the exec, have their fears and questions answered through this time of change. It can be a difficult balancing act.

Resolve

Finally, an executive must maintain a firm hand on the culture change tiller when the waters inevitably get rough. I strongly agree with the old saying that the main promise of Agile is to shine a light on the problems the organization already suffers from. Some of those challenges will be big, and this may be discouraging to the people of the organization. At that point, there is frequently a tendency to ignore the inconvenient Agile principles and to implement workarounds instead of confronting the difficulties head-on. Executive support requires that one maintain the pressure to change.

I think there can be little doubt that executive support is much more than a mere agreement to go ahead with the transformation. It involves signaling and modeling the change from the front, while ensuring that the others actually follow. It is a key transformational success factor. Besides the aforementioned examples, what other major actions should an executive take?

Works cited

“Support”, by Gregor Črešnar, The Noun Project, Web. 30 Jan. 2016. Modified.

Similarities Between Lean and Agile

It is said that the difference between theory and practice is greater in practice than in theory. Although I believe this is true of a lot of things, one area that eludes this old saying is the practice of Lean and Agile.

Practicality

The theoretical differences between Lean and Agile are the frequent subject of heated debates, even though their practical implementations often solve many of the same problems. I think those differences aren’t nearly as pronounced as they are often thought to be, and that far too much energy is expended on their account. I suggest we focus instead on getting to the business outcomes we all crave by cherry-picking the best arguments and techniques from each. Let me elaborate:

Origins

Of all the differences I hear about, the most prevalent seems to be that Lean seeks to reduce variability in the work so that the system can be optimized, whereas Agile accepts that variability as inevitable and attempts to adapt for it. This description is not without merit from a historical standpoint. Lean was first popular in traditional large scale manufacturing environments, and Agile sprouted in software development where each unit of work is unique. Though this analysis may be historically accurate, it is also far too shallow for us to conclude that Lean and Agile are fundamentally different.

Practices

The similarities strike me as far more numerous. Both Lean and Agile seek to deliver value to the customer through building the right thing. Both promote a culture of continuous improvement: Lean has kaizen, and Agile has the retrospective. Furthermore, Lean has poka-yoke to mistake-proof problem areas, and Agile similarly promotes the management of technical debt. Both focus on reducing delays. Lean most frequently uses the value stream map as the main tool, while Agile methods often use short iterations for much of the same purpose. Both emphasize the importance of quality. Lean has quality standards, and Agile frequently has a “definition of done.” Both promote resolving blocking issues quickly through all-hands-on-deck approaches. Lean has its andon cord, and Agile often has an impediment identification and removal process. Both promote a reduction of Work In Progress (WIP) for the purpose of accelerating flow. Lean emphasizes single-piece flow; Agile urges people to swarm on a common work increments. The list goes on and on.

Values

The parallels between Lean and Agile are actually not surprising. Indeed, a quick examination of the fundamentals reveals similar values. If one compares the principles that underpin the well-known Agile manifesto with the expression of Lean found in the Shingo Model, one notices a common philosophy.

I think the Shingo Model cornerstones of respect and humility are just a highly condensed expression of the Agile manifesto. What I mean by this is simply that the Agile values (and principles) can be traced back to respect, humility or both. For example, humility is implied in the desire to replace planning with a discovery approach. To arrive at that desire, we must first humbly admit the limits of our knowledge and prediction abilities. Similarly, respect is implied in the belief that people are intrinsically motivated, trustworthy and able of self-organization.

Put another way, Shingo’s respect and humility are to Agile what the Maxwell equation is to the inner workings of electric car propulsion systems. All the information is there, but it has to be unpacked.

Fig. 1. “Maxwell-Faraday equation”

Bottom Line

In summary, I believe Lean and Agile are rooted in many of the same principles and values. The challenge of articulating the differences is probably best left to the academics. The doers should focus on taking action instead, because while the differences may be smaller in practice than in theory, practice still makes perfect. I’d love to hear from you if you think this is an oversimplification that obscures some important practical differences.

Works cited

“Maxwell-Faraday equation”, Maxwell’s equations, Wikimedia, 24 Nov. 2015. Web. 1 Dec. 2015.