Sunday, November 29, 2015

Strip Away the Inessentials!

I opened my last post by noting that Bruce Lee advised martial arts practitioners to “strip away the inessentials and retain what is useful” (The Tao of Jeet Kune Do). When it comes to agile development, how can you determine whether something is essential or inessential?

Before answering, let’s challenge ourselves a little more. Consider answering the question in the context of a larger organization comprised of many different departments, each with their own well-defined area of responsibility. Now we have a dynamic where one department’s inessential could very well be another department’s essential.

Applying Bruce Lee’s guidance is still valid, it’s just more complex than his perspective of single combat. However, today’s military thinking embraces this concept in order to achieve the same qualities of adaptiveness and responsiveness that we’re looking for with agile development. It begins with something called Commander’s Intent.

The Joint Publication 1-02, Department of Defense Dictionary of Military and Associated Terms, gives the following definition of Commander’s Intent:

A concise expression of the purpose of the operation and the desired end state. It may also include the commander's assessment of the adversary commander's intent and an assessment of where and how much risk is acceptable during the operation.

The Commander’s Intent acts like a compass, enabling those on the front lines to select the proper course of action as they encounter changing conditions in the heat of battle. In order for this to happen the Commander’s Intent must be both short and easily remembered.

What it should NOT do is attempt to anticipate every possible scenario or be overly detailed. If this occurs, the Commander’s Intent will risk becoming useless once the enemy is engaged. As Helmuth von Moltke once said, “No battle plan survives contact with the enemy.”

The Commander’s Intent defines the critical, strategic elements that everyone should understand, leaving the tactical planning and execution to those closest to the action. This mindset acknowledges that there will be both unforeseen obstacles to overcome and emergent opportunities to exploit, and that those on the front lines are in the best position to quickly recognize and respond to these situations.

Equally important, being able to quickly adapt and respond is a function of small teams of comprised of skilled personnel versus one large, centrally-directed team. Yes, many teams can be participating on larger effort, but they are coordinated very differently. There is an emphasis on lateral communication to achieve rapid alignment versus sending requests up the chain of command and waiting for instructions.

In summary, centralized control and conformance to a plan are replaced by a framework for guiding operations by clearly defining and communicating what is valued while giving autonomy to those on the front lines to rapidly adapt and respond to changing conditions. Stripping away the inessentials and retaining what is useful honor this principles of this approach while implementing another Bruce Lee maxim: “Simplicity is the shortest distance between two points.” (The Tao of Jeet Kune Do)

Tuesday, October 20, 2015

Adopting Agile: Entice and Invite

In his day Bruce Lee challenged the teaching and training approach of traditional martial arts by labeling the traditional approach a classical mess. Lee wanted to move past what he felt was too rigid and formal to be practical, asserting that practitioners need to "strip away the inessentials and retain what is useful" (The Tao of Jeet Kune Do).

I believe that Lee was sincere, that he was addressing a real problem that needed to be solved. From a marketing perspective he nailed it: publicly decreeing tradition to be a "classical mess" was polarizing. And people love controversy.

However, this did nothing to build support with his peers. This same dynamic can -- and has -- occurred with agile development. Some early adopters of agile were excited about agile and they wanted others to adopt it as well, but they didn't sell it. A common complaint about agile practitioners in the early days was, "Stop telling us that everything that we've been doing is wrong!"

I had an experience that kept me from exploring agile more deeply for a couple of years. In 2003 I bumped into some XP (eXtreme Programming) practitioners during lunch at a development conference, When they mentioned that they using XP, I asked what it was and what made it different. One of them straightened up a bit in her chair and rather arrogantly told me that, "It is the only way to develop software." The others nodded their heads in agreement while exchanging knowing glances between each other in way that suggested I was definitely NOT in their private little club.

I remained silent for a moment, hoping that someone would speak up to give me a little more to go on, but that didn't happen. And when I attempted to probe a little more, I was more or less rebuffed. Any answers that I did get were along the lines of, "Go and get yourself educated."

I finished my lunch and walked off as quickly as possible. Granted, I continued to read about agile in various publications, but the experience left me less motivated to learn more about this wonderful new approach, let alone actually try it. Is there a more constructive approach?

I favor sharing your experiences and inviting others to learn more and experiment for themselves. You can't ask people to change their beliefs, not just on your say-so. An opt-in approach works along the lines of, "Here's a real problem that we needed to overcome, this is what we did, and these are our results. Would you like to understand more?" Change thus becomes an informed choice.

Fundamentally, there must be a dissatisfaction with the status quo. Bruce Lee and the XP practitioners I encountered had complaints about established practices along with strong convictions about what needed to change, coupled with practical experience to inform others how change could benefit them. What was lacking was an explanation about what was different.

In contrast, the authors of the Manifesto for Agile Software Development (also known as the Agile Manifesto) were articulating their dissatisfaction with the status quo and what they felt needed to be done about it. They got together to talk about what common to their various approaches (all of which existing before the term "agile" was coined), each one "...sympathetic to the need for an alternative to documentation driven, heavyweight software development processes". (History: The Agile Manifesto).

As I noted in my post, What does agile mastery look like?, these original signatories returned to a Shu level -- a beginner's mindset -- to deeply understand and articulate what the essence of a lightweight, or agile, approach to software development was all about. The term agile resonated with the market and provided a class of frameworks with a common reference point to inform others what was different so that they could make an informed decision about change. As a term, it provides the marketing hook that enables us to entice and invite others to change.

Have you already made an informed choice and started down the agile path? If so, are your results meeting your initial expectations?

If you haven't started down the agile path yet, what is holding you back?

Sunday, June 28, 2015

Will Agile Frameworks Converge?

I fully expect that at some point we won't need to label work as agile. It will simply be the way that we approach our work. Granted, the Agile Manifesto will continue to exist, it's just that we won't need to differentiate agile from other approaches because it will be the norm.

But what about agile frameworks? Will there be some form of convergence into one method of practicing agile? Let's take a look at the breakdown of today's use, courtesy of VersionOne's latest State of Agile Survey :

Scrum: 56%
Scrum/XP hybrid: 10%
Custom Hybrid (multiple methodologies): 8%
Scrumban: 6%
Kanban: 5%

(This list is limited to those in the 5% or higher usage range.)

While Scrum is the clear winner, use of hybrids accounts for 24% (I include Scrumban as a hybrid). Based on the current usage today, can we expect that a "Big 3" of Scrum, XP and Kanban will converge into one framework at some point in the future?

A case can be made that this will occur. As the use of agile expands, we're going to encounter increasingly complex scenarios where the use of hybrids is advantageous for a variety of reasons, and it is completely reasonable to leverage and apply all available knowledge and experience to the problem at hand, no matter what the source.

This line of thinking led me to believe that it is completely natural for frameworks to converge. After all, this would provide a very rich, comprehensive approach, one capable of handling a diverse range of scenarios. Upon further reflection, I came to the conclusion that it is more advantageous if various frameworks and practices remain separate. Why?

There is a comparison we can make to the martial arts. While mixed martial arts (MMA) integrates striking and grappling in no-holds barred competition, all the various styles of martial have not been supplanted by a single, comprehensive system. What MMA competitors do is draw from various styles and incorporate them into their own approach to fighting.

This is Ha-level learning, where practitioners are learning from additional frameworks and practices an integrating them into their own practice. It is actually advantageous to keep styles separate because in many cases (not all), a style will emphasize either striking, throwing, or grappling. This emphasis develops deep understanding and mastery in specific areas.

For example, mixed martial arts practitioners understand the need for grappling skills because of the success the Gracie family from Brazil had with their brand of jui-jitsu in no-holds barred fights and competitions. Brazilian Jiu-Jitsu practitioners have a long history of continually evolving their style, but they maintain a sharp focus on ground fighting.

They also teach and train others to effectively apply those ground-fighting techniques. Limiting the focus is a constraint that leads to continual improvement and advancement that most likely would not occur if everyone was a generalist.

When it comes to agile, convergence of frameworks in day-to-day practice -- when necessary and properly applied -- is a good thing. But let's keep in mind that not every scenario will require the application what we call a hybrid solution today. The lesson we can apply from the martial arts world is that keeping frameworks separate is essential because that is what allows us to continually refine and advance those frameworks in ways that everyone benefits.

Tuesday, June 16, 2015

Ha-Level Agile: Don't Break from the Wrong Tradition

Agile Shu Ha Ri differs from martial arts Shu Ha Ri because even at the Shu level of learning, the use of agile practices and frameworks should be interwoven with a Ha level understanding of agile values and principles. Traditional Shu Ha Ri, on the other hand, was developed in response to a harsh reality: the cost of experimenting with proven techniques and getting things wrong was potentially fatal because practitioners engaged in actual combat.

Agile Shu-level practitioners don't have this concern. Granted, a sprint or iteration may not go as well as it could have, but that should be the extent of the damage. Applying practices in conjunction with agile values and principles guides behavior, accelerates learning and allows practitioners to realize the full benefits of agile.

What does it mean to break from tradition in an agile sense?

Breaking from tradition is an opportunity for an agile practitioner is to branch out and expand his or her repertoire. A Scrum team may, for example, may begin incorporating elements of Kanban with the objective of achieving one-piece flow with their work. That is precisely what we want.

This is not always what happens. Consider a Scrum team "breaking from tradition" in ways that move them back to -- or preserve -- old ways of doing things. I have seen Scrum teams shift to Kanban or develop their own custom Scrum/Kanban hybrid as a mechanism to stay with what is known and comfortable.

This isn't breaking from "traditional" Scrum; it is using new vocabulary to preserve an existing tradition. While this sounds easily avoidable, in practice it takes discipline and concentrated effort to apply new concepts and break old habits. And more often than not we need time to learn and practice in order to fully benefit from applying new approaches.

The goal with agile Ha-level learning: Continue to learn and explore the underlying principles and learn from additional frameworks and practices, integrating them into your own practice.

I'll add one caveat that comes from none other than Bruce Lee. In his day, Bruce Lee advocated that every martial arts practitioner was different, and that individuals should interpret and evaluate techniques for themselves, based on their own unique circumstances. Does this sound familiar? Have you ever heard someone say, "Agile is different for every organization"?

Bruce Lee's stipulation was that any decision about which techniques to use should have a strong basis in reality. The same goes for agile adoptions. We need situational awareness and the discipline to look deeply at what will provide meaningful change, keeping in mind that the full benefit might not be immediate because we need to put some effort into learning and practicing new techniques in order to become proficient.

Sunday, June 7, 2015

What does agile mastery look like?

Can agile be mastered? If so, what does it look like? Put another way: how do you recognize someone as a master?

Let's begin by taking a look at the Manifesto for Agile Software Development, also known as the Agile Manifesto. How much attention have you paid to the preamble just above the four values?
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value..."
The creators of the Agile Manifesto are letting you in on an important point: they aren't claiming that they have THE answer to all of the woes facing software development, only that they are striving to uncover better ways of doing it. Does this mean that agile mastery is an elusive concept, and perhaps doesn't really exist?

Not at all. What we need to acknowledge is that mastery is not an all-knowing, all-seeing destination. Agile Shu Ha Ri isn't a linear progression from novice to master. There are degrees of understanding and capabilities, and we all should be seeking to continually expand and deepen our understanding of agile thinking, behaviors and practices. This begs the question: What does true mastery look like?

The creators of the Agile Manifesto are practitioners who possessed a great deal of knowledge and experience prior to creating the Agile Manifesto, including creating new approaches designed specifically to overcome "...the need for an alternative to documentation driven, heavyweight software development processes." What are known today as agile frameworks and practices actually came first, before the term agile was coined. And these were developed by very experienced and capable individuals.

My first observation is that original signatories of the Agile Manifesto are experts -- masters -- who are engaged in Ri-level learning, which is the ability to transcend, where a practitioner isn’t learning from others but learning and adapting based on his or her own experience and practice. The key takeaways in all of this are:
  1. The Agile Manifesto is written from a Ri perspective.
  2. Agile frameworks and practices aren't expected to fixed for all time. 
The values and principles that they developed and articulated in the Agile Manifesto, however, will likely stand the test of time (I predict). I believe this because values and principles of the Agile Manifesto are stated in such a way that they guide behaviors without being specific. 

The only way that these values and principles fail to stand the test of time is if we reject the very beliefs that they flow from. In fact, this is why some people reject agile development in the first place -- because it conflicts with their beliefs on what it takes to be successful.

Today, we begin our quest towards agile mastery leveraging the Agile Manifesto as our foundation. To be genuinely agile, we need to act in ways that support the values and principles of the Agile Manifesto; this is why Shu-level practicing of techniques should be interwoven with a Ha-level understanding of the underlying agile values and principles.

Without this understanding we risk doing agile in ways that may not be agile. Executing Scrum Sprints as mini-waterfall projects is one example that comes to mind. Agile frameworks themselves are lightweight in nature, but they were developed with the intent of following the values and principles articulated in the Agile Manifesto. Don't disconnect the guidance of the Agile Manifesto from any framework!

Agile Shu Ha Ri is a never-ending series of learning loops that begin with Shu-level practicing of techniques interwoven with a Ha-level understanding of the underlying principles (if you have a coach or training that enlightens you beyond the basic mechanics). You can can reach a Ri level in some aspects of agile while being a Shu-level beginner at others.

And always keep in mind that even the masters return back to a Shu level as they learn by coaching others or reflecting on their own experiences. This is what the creators of the Agile Manifesto did when they got together to reflect on what was common with a variety of approaches to software development that they had developed.

Agile Shu Ha Ri is a system of concentric circles of growth that occurs over time and not a linear path towards a destination. As a practitioner implementing and evaluating techniques, you will find yourself cycling back at the Shu level as you implement new techniques or instruct/coach new practitioners. But this is also how you deepen your understanding and grow over time.

Saturday, May 30, 2015

The First Step in Overcoming Shu-Level Challenges

"We can't be agile because..."

"We have to do 'x' first, then we can be agile..."

"We already tried agile once, and it didn't work..."

These are a few of the comments that I've heard early on in agile adoptions. I've encountered teams that were struggling when I first started coaching them, citing that, "This isn't working" before I had even started coaching them. "This" of course, being agile.

If you are championing and coaching agile and you are hearing comments along these lines, what can you do?

Ask for commitment.

Imagine a new martial arts practitioner entering into a dialog with an instructor that goes something like this:

"How can I fend off an attack where I'm grabbed from behind?"

"Good question! Start by dropping your hips and spreading your arms like so..."

"No, I don't like that. Show me something else."

You don't walk into a martial arts school and begin asking for specific techniques to solve specific problems like you are ordering from a menu! And you certainly shouldn't reject recommendations from experienced practitioners without investing time and effort -- training -- to become at least moderately proficient yourself. If a martial arts practitioner continued utilizing a menu approach, it's a sure bet the he or she wouldn't learn what they signed up for in the first place. 

A Shu-level martial arts practitioner isn’t dabbling. The same should apply to agile adoptions. And yes, good coaches will entertain discussions on the specific context and challenges that a team is facing. After all, adopting agile is like fixing the engine while the plane is in flight. Agile coaches help teams change and improve while they execute real work.

However, it takes time and effort to learn new concepts, to change old habits and behaviors and apply new approaches. The delicate balancing act for agile coaches is to introduce change mindfully in order to prevent change from diverting too much attention away from the work at hand. Thus is where commitment comes in.

A commitment is a genuine desire to follow a path for a period of time. Without this commitment, individuals and teams may simply be playing along, and that doesn't accomplish anything.

Saturday, May 23, 2015

Welcome to Agile Shu Ha Ri

The intent of this blog is to explore all things agile. Since this is my first post on this blog, let's begin by exploring an obvious question: What is Agile Shu Ha Ri?

Alistair Cockburn popularized the martial arts concept of Shu-Ha-Ri as a means of explaining the progressive learning process involved with agile adoptions:

Shu-level learning is all about learning from tradition by following practices precisely. A Shu-level practitioner is a beginner, and his or her mind should be focused primarily on how to do a given task without worrying about the underlying theory or on any variations.

Ha-level learning assumes that a practitioner can demonstrate competence with the basic practices, and is now ready to break from a single tradition by examining the underlying principles and theory along with incorporating variations and other techniques learned from other masters into his or her practice.

Ri-level learning is to transcend, where the practitioner isn’t learning from others but learning and adapting based on his or her own experience and practice.

Should we copy the traditional martial arts path with agile adoptions?

Not precisely. At least not using the traditional path of some martial arts where information is deliberately withheld from practitioners. In these cases, the inner workings are revealed only to those deemed worthy by the master – requiring a long period of dedicated practice and various demonstrations of character.

Good agile coaches, on the other hand, always want you to understand both what to do and why you are doing it. The simple rationale is that in order fully succeed, the application of agile practices must incorporate the thinking and behaviors that flow from the values and principles found in the Agile Manifesto. Imitating the practices alone will yield only a marginal improvement, if any.

Without this deeper understanding, agile could be mistakenly perceived as just another process. A process lacking in sufficient detail because it does not prescribe every step. This in turn could lead to the adding of prescriptive practices to address every possible scenario, unnecessarily bloating agile frameworks.

It is better that agile frameworks remain lightweight, allowing for any number of techniques to be incorporated into the mix that best match the specific circumstances of each team and/or organization. This also creates a challenge.

The vast amount of information and agile experience available today makes it possible to overload people with information. I’ve learned – the hard way – that the best way to teach someone nothing at all is to teach them everything (all at once). Which brings us back to the topic at hand: Agile Shu Ha Ri.

This blog is intended to focus on putting agile theory into practice and exploring the path from beginner to agile mastery. My intent is to weave in comparisons of martial arts concepts and experiences to provide a unique (I hope) perspective on the subject.

I welcome your feedback, and I encourage others to join me as contributors as well! If you would like to contribute, email me and I’ll add you as a guest blogger.