The Agile Executive

Making Agile Work

Archive for the ‘Scaling Agile’ Category

Tools, Behavior, Culture

with 2 comments

Colleague Annie Shum sent me her thoughts on the e-discussion that evolved around The Tool is the Method and Four Priciples, Four Cultures, One Mirror. As always, her thoughts connect a lot of dots. Here is Annie:

“Change versus shifts.  For me, I like to focus today’s discussion on the latter and let me just define a shift as large scale changes; notably transformative cultural changes.  Historically, cultural shifts are not top-down engineered by master planners; instead self-organizing emergence is the process by which all shifts happen on this planet. Similar to an ant colony where each ant works individually without pre-planned central orchestrations, our individual actions on a local level can collectively impact the emergence process. Positive as well as negative Feedback Loops are the fuel of the emergence process. Emergence can result in shifts that can both benefit (e.g. WWW, Information Age) as well as harm our society (e.g. wars, riots).

In thinking about tools in the context of impacting large scale cultural changes, one can’t help but immediately think about the computer/digital computing.  By all definitions, a computer is a tool – in fact, I would venture to characterize a computer as a “universal tool” that can, in theory, perform almost any task.  Moreover, I can’t think of any other tool that can surpass the computer and digital computing as the most disruptive transformation agents of our society and cultural shifts in the 21st Century.  According to James Moor, the computer revolution is occurring in two stages.  We are now at the cusp of the 2nd stage – “one that the industrialized world has only recently entered — is that of “technological permeation” in which technology gets integrated into everyday human activities and into social institutions, fundamentally  changing and transforming society at its very core.”  http://plato.stanford.edu/entries/ethics-computer

Advertisements

Written by israelgat

July 12, 2009 at 9:47 am

Live Recording of Four Principles, Four Cultures, One Mirror

with 2 comments

The live recording of my Agile Roots keynote presentation is available here. In addition to threading the slides together, the recording captures the Q&A session that followed. Various questions and observations were brought up by Diana Larsen, Jeff Patton, Andrew Shafer as well as other participants in the conference. In particular, linkages were made during the Q&A session to Appreciative Inquiry and to Serious Games.

Needless to say, comments on the presentation will be much appreciated.

Written by israelgat

July 11, 2009 at 8:59 am

The Tool is the Method

with 18 comments

In a recent post in dev2ops, Damon Edwards examines the role tools often play in the context of a desired cultural change. To quote Damon:

Did you ever notice that our first inclination is to reach for a tool when we want to change something? What we always seem to forget is that web operations, as a discipline, is only partially about technology.

Damon’s states the following view on the right balance to be struck:

The success of your web operations depends more on the processes and culture your people work within than it does on any specific tooling choices… We see this repeatedly in our consulting business. Time after time we are called in to do a specific automation project and wind up spending the bulk of the effort as counselors and coaches helping the organization make the cultural shift that was the real intention of the automation project.

While I am in full agreement with Damon on the phenomenon, I would like to highlight two nuances that in many cases make the tool is the method an effective approach to rolling Agile:

  1. The rise of professional procurers in Global 2000 companies (see Selling is Dead) changes transactional aspects of Agile engagements. Professional procurers typically focus on negotiating the best possible deal for the tool(s). Moreover, they tend to determine the preferred tool(s) in the early stages of negotiating the engagement.
  2. Tools might not change culture, but they can and often do change behavior. Think, for example,  about the way numerous folks use Twitter. What starts as “having a little bit of fun” often leads to major changes in the way one collects, stores, analyzes and assimilates information. The changes happen not due to an explicit intention to change, but as part of “playing” with Twitter.

Between these two nuances, a typical progression for an enterprise level Agile initiative tends to be as follows:

  • A tool is chosen
  • Teams start using the tool
  • The tool induces behavioral changes
  • These behavioral changes prevail, overshadowing cultural change initiatives

Hence, in many circumstances the tool indeed is the method. The chosen tool becomes a factor of the first order in determining not “only” how Agile (or any other software method) will be practiced, but what mindset will evolve in the course of the rollout.

See the presentation entitled  Four Principles, Four Cultures, One Mirror for additional details on the subject. A short summary of the presentation is given here. Related views are summarized by InfoQ here.

Written by israelgat

July 8, 2009 at 5:56 am

Software Capitalization in Atlanta

with 12 comments

Yesterday’s Agile Success Tour event in Atlanta was characterized by quite a strong interest of various participants in software capitalization. While the topic came up in previous success tour events, it was more pronounced in Atlanta. A subtle shift seems to be taking place: from technical aspects of rolling out Agile to business aspects the Agile champion needs to be aware of and prepared to address.

In the course of exploring software capitalization, participants in the Atlanta event brought up related questions about “the business of Agile.” For example:

  • Cost accounting for Agile
  • Return on the Agile investment
  • Agile Portfolio Management
  • Governance of the Agile project/initiative

Some of the participants were quite thoughtful about the dividing line between project-level Agile implementation and Enterprise-level implementation. They grasp that scaling Agile changes the nature of the questions one wrestles with. A few of them are actually considering  top-down approaches to implementing Agile. They do not necessrily subscribe to rolling Agile in a bottom-up manner. They devote quality time to wrestling with Agile scaling issues prior to starting the first Agile project.

I am hesitant to draw general conclusions based on a single event in a particular city. For example, I wonder whether the emphasis on capitalization might be related to the concentration of Supply Chain Management firms in Atlanta.

As the Success Tour “train” continues its journey (next stop: Washington, DC on July 23) we will soon have additional data points. Stay tuned…

Written by israelgat

June 26, 2009 at 8:59 am

Four Principles, Four Cultures, One Mirror

with 8 comments

Click here for the slides of my keynote presentation today in Agile Roots. The following key points are made in the presentation:

  • The Agile Manifesto principles are considered timeless.
  • Application of Agile can create cultural duality/conflict. The core culture of the organization that rolls out Agile is not necessarily aligned with the Agile culture.
  • Successful application of the Manifesto principles needs to build on the strength of the specific core culture – Control, Competence, Cultivation or Collaboration – in the organization rolling out Agile .
  • Schwaber’s 75% failure rate estimate corresponds to attempts to change the core culture of an organization as part of the Agile rollout.
  • Success does not necessarily beget success in Agile rollouts. The interplay between scale and culture poses serious challenges to scaling Agile successfully.
  • The Agile infrastructure places a practical limit on the scope of the Agile rollout. Constituencies that are not able to use a joint Agile infrastructure are not likely to collaborate.
  • The fine points of one Agile method versus another are far less important to the success of an Agile implementation than cultural subtleties of the target environment in which Agile is applied.
  • Good Agile tools are likely to induce behavioral changes without necessitating major cultural pushes.

A Single Point of Accountability

leave a comment »

Lack of executive support is often flagged as a major problem for Agile adoption. Jean discusses “checkbook commitments” from executive management in a recent post. Christophe Louvion has highlighted the issue during the Rally event in Los Angeles. I certainly have for quites some time been (and still am) of the opinion that executive support is critical for Agile success.

In the course of working on my forthcoming presentation at the Agile Roots conference, I took a fresh look at quite a few of the convictions I hold, including lack of executive support. Having such support, of course, is awesome. However, is the difficulty in securing executive support the fundamental problem or is it a symptom of an underlying problem?

A couple of years ago my colleague and friend Yechiam Yemini made a very astute observation on accountability in system management. Yechiam observed that system management applications of the “You got a problem on your hands” variety generally don’t get endorsed by IT executives if they do not indicate clear accountability. The last thing in the world an IT executive wants is finger pointing between his/her network management folks, the storage management team and the help desk expert. A lot of time and effort is wasted in resolving such situations. IT executives hate them with a passion.

I am starting to think a similar phenomenon might be manifesting itself with respect to  Agile adoption. For example, if things do not go well for a Scrum project, is it a matter for the Scrum Master, the Product Owner or the self-organized team? From an enlightened Agile perspective, the whole thing is about the wisdom and commitment of teams. It might however be seen in quite a different light by the executive who has not had the opportunity to immerse himself/herself  in Agile.

“We are all in it together” is a quip frequently used by executives in time of crisis. When the quip is sincere, it can provide the underpinnings on which to develop a deeper understanding of accountability in the Agile context. Part of being in it together is the executive’s accountability to follow Agile values and principles. The house metaphor Jim Highsmith proposed can be used very effectively in the context we are discussing . One starts building a house by laying the foundations – Agile values and principles in Jim’s metaphor. Pillars and roof come later.

Written by israelgat

April 27, 2009 at 12:54 pm

Don’t agile the Agile

with one comment

I have been known to frequently say say don’t agile the Agile. I use this quip in two ways:

  1. To demonstrate the importance of patience in rolling out Agile. I consider patience a critical ingredient in the ‘secret sauce’ required to properly introduce Agile in a company that is new to Agile methods.
  2. To set expectations realistically for executive who wonder about the payoff period for an Agile roll-out.  It is particularly important to do so when an executive has a view of Agile as a silver bullet.

During the Rally Agile Success Tour I realized many Agile champions are under pressure in their companies to promise quick results. No doubt, Agile gives you good forums to demonstrate what has been accomplished -bi-weekly demos and frequent releases. But, Agile also introduces a lot of change:

  • The software changes. You are doing new software, evolving software or fixing software.
  • The software process changes. You are introducing Agile methods.
  • The organization changes. New organizational entities such as Scrum teams get formed and evolve.

These three dimensions of change take place simultaneously. You and your teams need time to assimilate the changes. In particular, techniques to manage inter-dependencies between the three could require a fair amount of time  to master.

Jim Highsmith told me he asks the executive with whom he discusses Agile roll-out to recount an example how his/her organization has recently managed change. I borrowed this good question from Jim and I use it often. The typical response to the question is a minute of silence followed by something like “this is a very good question”. In most cases, the executive “fails” to provide an example that has as many dimension of change as an Agile roll-out would have. When this point is reached, the message don’t agile the Agile is heard.

(Note: Agile roll-out can and often will introduce additional dimensions of change. For example, you might need to revise your customer support policy as well as the way your Support organization functions. I do not mention such secondary changes in this post as the three primary dimensions indicated above are more than plenty).

Written by israelgat

April 14, 2009 at 11:43 am