The Agile Executive

Making Agile Work

Archive for the ‘Scaling Agile’ Category

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

Persona of the Agile Team

with 4 comments

Many of us encountered situations in which the spread of Agile in an organization came to a halt. It was quite successful at the project level, but did not spread to the product line; it worked well for the product line, but did not get accepted by the business unit; or, it proved itself in the business unit, but success did not lead to adoption at the enterprise level.

I recently read The Living Company by Arie de Geus. His perspective is that a company has a persona. To quote de Geus:

… as a living entity, a company is always insecure, never stable, always subject to shifting relationships between the company and the outside world.

Furthermore, de Geus suggests a company has its own ladder of personae: Individual –> Team –> Work Group –> Division –> Company –> Corporation –> Society. According to de Geus, the persona of an organizational entity satisfies the criteria (cited by William Stern) for a living persona. Like live human beings, organizational entities:

… must find their place in the world; they must develop a sense of relationship between their own persona’s ethical priorities and the values in the surrounding world…. The Persona has an influence on the world around it as an example, a “role model,” but it can never equalize the world’s view with its own.

If you accepted this premise, implications with respect to spreading Agile are intriguing.  A mismatch between the involved organizational personae might be the obstacle to broader acceptance of Agile. The mismatch might be related to Agile. Or, it could equally well be unrelated. For example, it might revolve around the need of one organizational entity or another to self-preserve itself.

I find it fascinating that Ken Schwaber has actually discussed Agile success and failure along somewhat similar lines, as follows:

I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it… The intention of Scrum is to make [their dysfunctions] transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them. [AgileCollab interview of February 19, 2008]

The corollary from the observations of Stern, de Geus and Schwaber might seem counter-intuitive. If the spread of Agile in your company has stalled, providing qualitative and quantitative data on the benefits of Agile might not be the best way to win over support for broader adoption. Instead of hard sell of Agile benefits, focus on cross-organizational dynamics, pathologies and development.

Written by israelgat

April 12, 2009 at 8:43 pm

“More Than One Way to Roll-Out Agile”

with one comment

Ryan posted part I of the debate between Erik Huddleston (Inovis), Jack Yang (Homeaway) and me on the subject of Agile roll-out strategies. The heart of the debate is team-by-team versus all-in. To paraphrase Robert Graves, the debate is true and the telling is frank. Highly recommended!

Part II and Part III have been  posted [IG; 4/11/2009]

Written by israelgat

March 11, 2009 at 8:37 pm

How to Viral-Spread Agile on a Large Scale

with one comment

In last week’s Agile Austin Distinguished Speaker Series, Sue Mckinney and Pollyanna Pixton presented the Agile/Lean work they carry out at IBM. Their approach to making Agile of interest to 25,000 employees in IBM’s Software Group stands in nice contrast to the classic quip “I am from Corporate; I am here to help you.” As a matter of fact, during her presentation Sue recounted how as a developer she disliked edicts that came from above when they did not suit context and reality in the trenches.

Sue’s presentation is available here. It deserves thorough reading by anyone who is concerned with scale and scope issues in Agile roll-outs. Here are some of the more interesting points:

  • The initial  impetus to go Agile was time-to-market imperatives
  • The Development Transformation program which Sue drives at IBM provides a menu of thirteen Agile/Lean best practices a development team can choose from.
  • The program puts an emphasis on adaptive planning
  • The program stresses the importance of sharing both code and best practices
  • An expanded community of 40,000 IBM’ers and >100 customers are part of the program
  • Geographically distributed teams are considered the norm at IBM (given the company’s M&A strategy); Agile practices must take this reality into account

Interestingly, in the series of workshops she delivered at IBM, Pollyanna did not even speak about Agile! Instead, she talked about the various aspects of collaboration and team dynamics. You can get a good sense of the themes Pollyanna covered at IBM  in her presentation on Collaboration and Collaborative Leadership in the Experience section of the Accelinnova web site.  See Jean Tabaka’s note and Michael Cote’s note for complementary opinions  on collaboration, organizational dysfunction and Agile.

 Sue and Pollyanna are continuing their Agile roll-out work at IBM. Stay tuned….

Written by israelgat

February 15, 2009 at 4:38 pm

Scaling Agility: From 0 to 1000

with one comment

Walter Bodwell delivered an excellent presentation on the subject in Agile Austin last night. The presentation is quite unique in seeing both the “forest” and the “trees”. Walter addresses the operational day-to-day aspects of Scrum in the trenches in parallel with providing insights on the roll-out at the executive level. Highly recommended!

Written by israelgat

February 4, 2009 at 9:25 am