The Agile Executive

Making Agile Work

Posts Tagged ‘Lean Agile

Punching Above Your Weight Class

leave a comment »

Authors Hagel, Brown and Davison use an interesting metaphor in a recent Harvard Business Review article on strategy in time of constant change:

Today’s new Digital infrastructure in fact gives relatively small actions and investments an impact disproportionate to their size. To use a boxing metaphor, companies can now punch above their weight class.

Compare the Digital infrastructure with traditional infrastructures such as water canals, railroads or highways. Unlike these classical means of communication and transportation, Software is unique in being integral part of the Digital infrastructure as well as being a major piece of what gets transported over the  infrastructure.  Best I know no other entity ever played such a dual role in as meaningful a manner.

The metaphorical punch Hagel, Brown and Davison use as an illustration for the leverage provided by the Digital infrastructure is particularly intriguing due to to the malleability of software. Delivery methods for products and services over the Digital infrastructure could evolve the way product feature and functions do. If the product continues to evolve after initial delivery, the opportunity presents itself to do Agile in the deep sense recently proposed in The Lean Startup: iterative customer development alongside Agile product development that includes iterating on the delivery method.

Written by israelgat

April 21, 2009 at 8:40 pm

A Note on the Kanban & Retrospectives Post by David Andreson

with 3 comments

David Anderson wrote an interesting post on Kanban & Retrospectives. David observes that some seasoned Kanban teams ceased doing “official” retrospectives. To quote David:

Some mature Kanban teams did drop the use of retrospectives. No one told them to do it. They just did. Retrospectives were not adding value in their lives and hence were seen as a wasteful activity that could be eliminated.

David carefully examines retrospectives in the Kanban context. His concluding recommendation is as follows:

Kanban can enable a team to reach a level of maturity where they may choose to eliminate retrospectives (or not.) It’s a choice! Every situation will be unique. The important thing is not to see elimination of retrospectives as wrong or bad or “not agile.” Equally, don’t rush in and eliminate retrospectives. Don’t proscribe retrospectives. Let the team make its own decision when it is ready and embrace the evolution of process that comes with continuous improvement.

I certainly understand where David is coming from and the sound logic of his reasoning. However, the question on my mind is whether core Scrum practices could be reduced without jeopardizing the method. The following excerpt from a recent Cutter Consortium post entitled Breaking the Facade of Truth: An Introspective View into and a Case Study About the “Apparent Truths” of Agile by David Spann nicely summarizes how minimalistic Scrum is:

Scrum, as a management methodology, is elegant in its design, requiring only three roles (i.e., product owner, ScrumMaster, and self-organized team), three ceremonies (sprint/iteration planning, daily Scrum/debrief, and sprint review meetings), and three artifacts (product and sprint backlogs and the burndown chart) — just-enough practical advice so agile teams do not overcomplicate the development lifecycle with too much ceremony and documentation

Can one meaningfully drop a core practice of a just-enough method?

Opinions please!

Written by israelgat

March 21, 2009 at 2:07 pm

The Mindset

with 5 comments

In her recent post Stop Drinking the Kool-aid – Eat the Cereal!, colleague and friend Jean Tabaka gives an interesting metaphor for iteracting with executives about Agile:

Talking about Agile to executives can be like feeding turkey to your family on Thanksgiving; it puts everyone into a sleepy stupor.

Jean goes on to recommend Lean as a way to get the message across. To quote her:

Through Lean, I am able to tap into discussions about waste versus value. I can engage the executive team into looking at their entire organization. And, these “seeing the whole” discussions help them then understand why they should care about an engineering groups adoption of Agile.

Working the Lean angle the way Jean recommends could most certainly open the discussion and enrich it. Success, however, depends on a certain kind of mindset of the executive you are talking to.  This mindset is nicely described in H. Thomas Johnson‘s article Manage a Living System, Not a Ledger:

…a business organization cannot improve its long-run financial results by working to improve its financial results. But the only way to ensure satisfactory and stable long-term financial results is to work on improving the system from which those results emerge.

If you accept the premise expressed by Johnson, you need to consider two kinds of possible dialogs to get your Agile message across:

  • Agile focused dialog about the what, why, how and when of Agile. You do this kind of dialog when your counterpart is already at the point of looking for sustainable value generation, not for a magic bullet.
  • Recipe for success dialog. This kind of dialog establishes the foundation required for the first dialog when the executive is not quite ready yet for Agile. Give the executive the opportunity to think deeply on his algorithm for success. It may take a few conversations until the algorithm is spelled out. Once it is, you can start working with the executive on what Agile is and how it might fit into his algorithm for success.

An extremely important point to keep in mind is that mindsets evolve. The set of business circumstances under which an executive is operating can lead to a certain mindset. The mindset can be quite different at another point in time due to change in strategy, priorities and constraints. A good fit for Agile may not exist today, but it might exist tomorrow.

Written by israelgat

January 26, 2009 at 9:51 pm

The Core Principle Behind Agile

with 2 comments

Hyper-productive Agile teams, reaching twice, thrice and even higher level of productivity compared to industry average, have been reported by various consultants and practitioners, including Jeff Sutherland, Michael Mah and me. I run into a lot of questions about the reported case studies. Often times I sense that the executives quizzing me about the accomplishments of BMC Software are wishing at some level to find something extraordinary that would explain how my project teams accomplished hyper-productivity. In other words, the reported productivity figures are sometimes considered too good to be true in general.

IMHO Agile hyper-productivity stems from a very simple universal principle: everyone on the team does only the most important things at any point in time. Effectiveness and efficiency are the results of systemic elimination of less important features, functions and tasks.

Various executives ask me the question “Should I adopt Lean Agile or should I do Scrum ?” The answer I invariably give is “To my way of thinking, the two apply the same principle: Lean Agile focuses on eliminating waste; Scrum focuses on the elimination of “waste” in form of the less important.”

I will cover the “secret sauce” of BMC Software’s sucess with Agile methods in forthcoming posts. Before doing so, I would like the reader to come to terms with the following view: the secret sauce we used at BMC was “just” creating the environment within which the less important was eliminated.  What we did was a successful implementation of the core principle: “Do only the most important things at any point in time”.

In a way, our secret sauce was grasping this fundamental principle and developing a whole socio-technical system to free the principle from the metaphorical chains of archaic methods.

Written by israelgat

January 15, 2009 at 5:53 pm

Posted in Starting Agile

Tagged with , ,