The Agile Executive

Making Agile Work

Posts Tagged ‘Learning Agile

Q2 Agile Success Tour

with 2 comments

Various posts in this blog (click, for example, here, here, and here) brought up noteworthy threads from the Rally Agile Success Tour events in Denver, Los Angeles and New York. The Rally team and I are gearing up now for the following events:

  • June 4, 2009 in Santa Clara, CA
  • June 25, 2009 in Atlanta, GA
  • July 23, 2009 in Washington, DC

I have started teleconferencing with the panelists in these three cities. It is clear even at this stage of the preparations we will have an eclectic mix of panelists and various intriguing topics that might not have been fully addressed during Q1. For example, Agile Support for Customer Support is a topic that will be discussed in the Washington, DC event.

 A I did during Q1, I will report here highlights from the events. Stay tuned…

Written by israelgat

May 10, 2009 at 6:08 pm

Posted in Events

Tagged with ,

Statement of Purpose for the “Ask an Expert” Program

with 2 comments

A recent post in this blog outlined Agile Austin‘s intent to start an “Ask an Expert” service. Plans for the program have been solidified now and it will be kicked off next week. The statement of purpose for the program is as follows:

The objective of the Ask an Expert program is to provide free consultation by experienced Agile Austin coaches to any Austinite that wrestles with issues related to promoting, planning and executing Agile methods. The program will address the needs of practitioners in companies that produce software, embed software, or use software as an integral part of their business processes. In addition to 1-1 consultation, coaches will gladly hold discussions with entire teams.

Ask an Expert sessions should be primarily regarded as a step toward addressing concrete Agile issues that manifest themselves in a specific environment. Coaches might not be able to complete a comprehensive analysis, but will make certain to suggest what the heart of the problem might be and point out Agile resources that practitioners could use on their own.

To ensure available access to experts, consultative session time will be divided between attendees. Team discussions with any Agilists attending the program will be encouraged to maximize the sharing of experience and draw out the wisdom of crowds. One-on-one sessions are available on request, but will be time-limited based on attendance (15 minutes typical).

The program will strive to balance utility with fun. Utility will primarily be delivered through actionable insights; fun will be had through passionate exploration of Agile topics in a friendly and collaborative manner.

Starting the coming Thursday (May 7), the program will be held every Thursday 6-8PM in the Chicago room at Mangia’s Pizza, 8012 Mesa Drive, Austin, TX.

Click here for the website for the program. Many thanks to Agile Austin volunteer Chandler Sweetser for constructing it. In a true Agile fashion, the site will evolve as we go along.

Written by israelgat

May 2, 2009 at 8:48 am

Posted in The Agile Life

Tagged with ,

Observations from Houston

leave a comment »

The Houston chapter of APLN arranged an Agile track in the April 30-May 1, 2009 PMI Houston Conference. I had the pleasure of participating during much of the the first day. Following are my major observations from the conference in chronological order:

General: Agile awareness was quite broad amongst participants irrespective of whether they do or do not do software. Just about every project/program manager I had the opportunity to speak with was aware of Agile and anxious to learn more. Many questions to the panel were about Agile. Some asked specifically about applying Agile beyond software. For example, one of the questions posed was:

What does Agile have to offer to a major oil company?

Metaphor for the Agile PMO: Jochen Krebs compares the functioning of the PMO to that of the information booth in Grand Central Terminal in NYC. Hundreds of thousands of people go through the station every day on their own – they are motivated to reach their train and they generally do find their way. If they need help they ask for it, trusting the information booth to give them pertinent and reliable data.

Motivation for adopting Agile: AOL’s transition from a single brand to multiple brands (e.g. AOL Food, AOL Music) was a major factor in their going Agile. Pretty much every brand has its own Agile project team now. (Click here for details on AOL’s branding strategy).

Going live: The product owner at AOL makes the final call whether to deploy (or to hold off on deploying) new functionality or contents.

Agile training: AOL invests 5 days of training/consulting/coaching in each team converting from waterfall to Agile. Training is given in the organic project teams (as distinct from open courses to which anyone can enroll). Newly converted teams are expected to operate on their own (i.e. without consultants) after three iterations.

View from the panel on primary reasons for project failure:

  • Lack of alignment.
  • Folks do no tell the truth. To succeed, one must be brutally honest.
  • Poor expectation management.

View from the panel on ingredients in the ‘secret sauce’ for project success:

  • The project/program manager has to be both humble and willful.
  • Acting on insights gained in the retrospectives is critical.
  • Must know the real status at any point in time. For example, what do the employees think on the subject? What do customers say?

Visualization: Deemed absolutely critical to requirements management in any project of scale. It is the antidote to explosion of requirements data and confusion about requirements (Tony Chen, Seilevel).

Reconfiguring the Business: Readers of this blog are already familiar with many threads in the Reconfiguring the Business presentation I delivered. Click here to read it in entirety. Needless to say, comments on the presentation will be much appreciated.

Written by israelgat

April 30, 2009 at 10:35 pm

Timing and Duration of the Agile Roll-out

leave a comment »

A measure frequently considered by executives these days is the introduction of Agile as part of cost reduction initiatives. To succeed in attaining cost benefits through the higher productivity of Agile, the plan for introducing it needs to take into account the slippery slope that repeated cost cutting measures tend to lead to. In particular, the timing of rolling out Agile and the duration of the roll-out need to be carefully considered to avoid a possible cart-before-horse situations.

A cart-before-horse situation is likely to arise as a result of the following pattern:

  1. An executive’s budget is under pressure.
  2. Headcount reduction is carried out. Remaining employees are expected to somehow cope with the load.
  3. Agile, with its promise of higher productivity and possibly hyper-productivity, is introduced as a counter-measure to the reduced headcount.
  4. The remaining development resources are expected to acquire a new set of skills, to master the art of Agile.
  5. The need to acquire Agile skills flies at the teeth of remaining employees needing to regain expertise that was lost by reduction in headcount. In many cases, the remaining development resources are already stretched too thin.
  6. Staring at the choice between acquiring specific domain expertise in a critical area versus developing less concrete expertise in software methods, more often than not the remaining employees and the system around them will opt to concentrate on acquiring domain expertise. For example, if a product fails to satisfy a new security benchmark introduced by key customers, the need to respond to the security benchmark is likely to take precedence over studying estimation techniques for Agile.
  7. Goto #1 above.

To preempt such cart-before-horse situation, the following principles need to be adhered to:

  1. Don’t introduce Agile before “the system” adequately adjusted to a round of headcount reduction.
  2. Do not carry out layoffs during the assimilation phase of Agile. In addition to cart-before-horse situation as described above, headcount reduction could jeopardize two critical pillars of Agile: empowerment and collaboration.
  3. Establish a quantified baseline of productivity before starting an Agile roll-out. Measure Agile progress against the baseline.
  4. Do not bet the Agile roll-out on linear improvement in productivity. A good Agile implementation is likely to improve productivity, but it is quite tricky to predict the shape of the Agile learning curve.

In practical terms, your organization needs to take a strong “medicine” up-front to break the vicious cycle that repeated staff reductions amidst an Agile roll-out are likely to create. The medicine should be strong enough to last through the period of time required for a meaningful assimilation of Agile. A good way to assess how long the period might be is to consider Agile as apprenticeship – one learns by “Agiling” with the masters.

You need to ask yourself the question “Can We Afford the Software We are Developing?” if business circumstances do not allow for reasonable adherence to the principles cited above.

Startups should be Built to Learn

with 3 comments

Eric Ries has published a few great posts (click here, here, and here) on his April 1st lean startup presentation at Web 2.0 Expo. The title of this post is actually borrowed from his response to a comment made by one of his readers. According to Eric:

[This] point is the one that seems to have had the biggest impact from the talk as a whole: that startups should be built to learn. That’s the essence of so many of the lean startup techniques I’ve evangelized: customer development, the Ideas/Code/Data feedback loop, and the adaptation of agile development to the startup experience.

As learning and learning through experimentation are central themes in Agile, I encourage readers of this blog to take a good look at what Eric writes.  I would also like to add a few quick reflections:

  1. It does not really matter whether you are part of a tiny startup or working for a $100B company. Eric’s heart seems to be in startups, but his insights are broadly applicable.
  2. Jean discusses the “goal of improving my notion of learning” in a recent blog post and accompanying dialog. Her thinking as well as many of the references she cites nicely complement Eric’s ideas.
  3. In The Living Company, author Arie de Geus strongly emphasizes institutional learning as a critical capability. Learning to de Geus is about sensitivity to the surrounding environment and willingness to change to be in harmony with it.

All these threads about learning indicate a company is more likely to survive for the long haul if it has the capacity to learn. The threads are linked in a fascinating manner to Jared Diamond’s book Collapse: How Societies Choose to Fail or Succeed. It seems that learning as a survival imperative applies equally well to the individual, the team, the corporation and society.

Written by israelgat

April 16, 2009 at 9:30 pm

Companies make shoes!

with 2 comments

Peter Drucker made an astute observation which is quite relevant to the current business situation during a September 1998 interview with Fortune:

Securities analysts believe that companies make money. Companies make shoes!

Readers of this blog might have said “software” instead of “shoes.” The point would have been similar to Drucker’s. Good financial management is no doubt  important for your company’s success. It is no substitute, however, to focusing on the business you are in, the technology(ies) that drives the business and the effectiveness of the underlying systems and processes.

The current macro-economic situation gives you an opportunity to soberly assess the viability of your business design (as distinct from doing a lot of financial engineering). With asset inflation corrected, measuring the effectiveness of your business model in terms of the ratio Market Value/Revenues is much more meaningful now then it used to be prior to September 2008. As pointed out by Slywotzky in Value Migration, a market value to revenues ratio lower than 0.8  indicates value outflow for your company and possibly for your industry.

For software companies, the impact of “good enough” Open Source Software should be assessed in conjunction with close examination of the market value to revenues ratio. Twitting from the recent OSBC conference in San Francisco, colleague Andrew Dailey of MGI Research reported “… ERP/CRM are viewed as least susceptible to open source disruption… due to high transaction volumes and high integration needs.” Conversely, Andrew considers office productivity software as ripe [for the picking by Open Source Software]. I am personally of the opinion numerous Application Life-cycle Management tools could be massacred by Open Source Software.

The confluence of the threads highlighted above poses a fairly unique opportunity for the Agilist to convey a major premise of Agile to his/her executives. Like a thriving Open Source Software community, a hyper-productive Agile team can pick a ripe market faster and cheaper than an old fashioned software company could. Moreover, if a company is in one of the markets that are susceptible to an Open Source Software onslaught, Agile can (up to a point) provide defense against such onslaught. Whether you choose to attack or defend, Agile software gives you the advantages of proprietary software at a fraction of the traditional cost.

The House Jim Built

with 10 comments

Colleague Jim Highsmith uses an interesting metaphor in a Cutter Advisory published a few days ago:

Visualize a house structure with a roof, a foundation, and three pillars… The roof is business goals — the rationale for implementing agile methods and scaling to larger agile projects. The foundation is agile values or principles — principles that need careful interpretation as to how to apply them to larger teams. And finally, the three pillars: organization, product backlog, and process/practice.

The simplicity of the metaphor makes it quite effective in communicating what Agile is in a concise manner. The need to do a better job conveying the concepts (as distinct from the practices) of Agile was highlighted during Rally’s recent event in Los Angeles. Numerous participants in the event felt they have not managed to get the Agile premise across to their executives.

Jim’s metaphor is nicely supplemented by the following short characterization of Scrum by Cutter Consultant David Spann in a recent Report:

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.

Between Jim and David, you should have no problem carrying the day in discussing Agile methods with an uninitiated executive.

[David’s Report is available in entirety here. You will need to subscribe to the Cutter service in order to get a copy of Jim’s Advisory. The excerpt cited above, taken from the public summary of the Advisory, is largely self-contained and should suffice for delivering the core message].

Written by israelgat

April 15, 2009 at 7:04 pm

When an Agile Project does not Seem to be Working

leave a comment »

Colleague and friend Paul Beavers suggested writing a post on this topic. To quote Paul:

… it is clear the [Agile] methodology often gets blamed for poor quality and poor general execution.  The root cause of these problems is not methodology but more the mere implementation of it.  It would  be valuable to read ideas on how to recognize things are not performing and how to keep leading an organization through the tough times. 

Recognizing when things are not working

The post Early Warning Signs highlighted various specific indicators one could use to foresee problems. Examining the same subject from a somewhat different perspective, Jean wrote about Twelve Top Agile Adoption Failure ModesChristophe Louvion has recently conducted a session on the topic 101 Things Leaders do that Kill Team Productivity.  It should be fairly easy to sense that something is not right by consulting theses three sources in conjunction with your own intuition.

A good practice to follow is establishing a base line with respect to the state of your software engineering practices before starting an Agile implementation. Collect and record the data for a metric or two. For example, number of bugs per thousand lines of code is a useful metric for quite a few purposes. When you suspect the Agile implementation might not be working, compare the historical data you collected with current data. You will be able to assess your progress (or lack thereof) on a relative scale instead of an absolute one.

What to do about it

IMHO self-awareness is more than 50% of the solution. It comes in two “flavors”:

  1. If the things that do not work are under your control, start addressing them with realistic expectations in mind. For example, it might take a few months to get an inadequate build process to the point is satisfies the requirements of your Agile process.
  2. When the things that do not work are beyond your control, your task is to make the right folks fully aware of the obstacles. It is a minute of truth for you as an Agile champion: you might need to convey some hard facts to various senior folks in your eco system. It is not too hard to do if you are wholeheartedly convinced Agile is the right thing to do. It is next to impossible to do if you are ambivalent about Agile.

One other thing to do is assess whether Agile is indeed a good fit for your business imperatives and corporate culture. Chances are you had already made this assessment prior to starting Agile. Reassess in view of the actual experience of the Agile initiative.

Written by israelgat

April 15, 2009 at 11:07 am

Pains from Los Angeles

with 14 comments

Click here, here and here for stroke-by-stroke coverage of the March 26 Rally event in Los Angeles by Zach. From my own interactions with participants during the event, I compiled the following  list of the most painful issues between an Agilist and his/her executive(s):

  1. The “sausage syndrome”: “Don’t bother me with details how you do the software – just get it done” seems to be the attitude of numerous “business executives.”  I must admit I still don’t get it. Software is becoming pervasive on an unprecedented scale. And, software is becoming bigger and bigger component of just about any product in which it is embedded. Ditto for software as part of the business process. What is your recipe for success if you (as an executive) don’t get down and dirty on such a major component of your business?!
  2. Agile as part of the overall software engineering fabric: This issue is a close cousin of the “sausage syndrome”. Expectations of Agile are unrealistic as it is not grasped holistically as one layer in the overall context of  the art of programming. We direly need a construct like the OSI Reference Model for software engineering.
  3. Agile and the real customer: Much of the emphasis is still on Agile in R&D. The real customer is not iteratively integrated  in the development process. In spite of a ton of data to the contrary, we often drive the iterative development process under the fallacy that the customer problem is well understood.
  4. Agile in the business context: Discussion are usually focused on $$. Most Agilists do not seem to be well equipped to discuss Agile in the contexts of  risk mitigation and compliance.
  5. Assimilating Agile: Little understanding that apprenticeship is a wonderful way to learn Agile. Precious few invest sufficiently in on-going Agile consulting and coaching.

I started the event stating that I feel like one foot in cold water, the other in hot water: we accomplished so much over the past few years, yet much more could and should still be accomplished. I finished the event with precisely the same feeling: a ton of enthusiasm for Agile in the trenches; the immense opportunity to harness this enthusiasm at the enterprise level is not quite happening yet.

Early Warning Signs

with 3 comments

Colleague Michael Mah describes comparing time-to-market, productivity and quality of a project team against industry averages as being outside the elevator. With the focus on iteration and release, it feels like being in an elevator – precious little contact with the outside world. For example, you do not know where other elevators are headed and what their speed is until you step out of the elevator. As long as you are in your “elevator”, it is quite difficult to objectively assess whether your Agile roll-out is or is not going well.

Until you collect  the data and acquire the analytics to compare your team to other project teams in the industry, here are a few early warning signs for Agile implementations  that might be heading toward trouble. Like everything in Agile, they give you the opportunity to take the input as call to action and apply the necessary measures to improve your process.

Time spent with Agile teams in the trenches

This is the simplest yet the most reliable warning sign. If you are the executive in charge of the Agile roll-out, examine your calendar over a certain period of time with respect to two questions:

  1.  Do I spend enough quality time with the Agile teams to be able to notice the rest of the early warning signs listed below?
  2. Am I involved in a manner that clearly demonstrates my support of and commitment to the Agile roll-out?

The data you collect from your calendar is simple. For example:

You do not need to say much in any of these forums. You might even choose to be completely silent through a stand-up meeting . However, you must spend quality time with the teams that are getting into Agile. Allocating 20-25% of your time to being with the Agile teams in the trenches is quite appropriate, particularly in the initial roll-out phases.

Failure to prioritize

The great advantage of this warning sign is that it can be spotted fairly early. In its implicit form, this sign manifests itself as multiple backlogs when one backlog should have sufficed from a product perspective. In its explicit form it manifests itself as everything is important statements and pressures. In severe cases you might even notice that the Product Owner is not really part of the team, that an us versus them attitude prevails.

Chronic reductions in scope

Flexibility is very different from mushiness around the minimum credible line of a release. Repeated reductions in scope, as distinct from substituting one requirement for another, is a certifiable sign of trouble. Something is wrong if reductions in scope happen one iteration after another. Something is terribly wrong if team members believe the Agile philosophy is supportive of scope reductions in an unconstrained manner.

In some cases the heart of the matter might be as simple as inadequate estimation techniques, not inadequate execution. However, until estimation accuracy improves, relationships between R&D and marketing and sales are likely to be strained.

This warning sign tends to manifest itself later rather than earlier in the Agile release. However, it is quite easy to spot.

Weak focus on outcome

This warning sign is a close cousin of chronic reduction in scope. It usually manifests itself as misplaced focus. For example:

  • The focus is on the team progress rather than overall project progress
  • Output numbers become more important than outcomes
  • Managers and directors bicker about which team was “behind”
  • Product marketing changes the backlog frequently under the “Agile flexibility” banner

Not keeping up

Keeping up with all facets of Agile practices amidst short iterations can be quite demanding. Watch out for repeated  failures to keep up with:

  • Builds
  • Continuous integration
  • Defects/testing
  • Completing stories within the iteration
  • Resolution of blocking issues
  • Regular bi-weekly demos
  • On-going release-ability
  • Technical debt

This warning sign is best used in the aggregate rather than in a discrete manner. To properly use this sign, watch for cumulative effects rather than a single failure.

 Acknowledgements: Many thanks to Igor Bergman, Walter Bodwell, Mike Lunt and Roy Ritthaler for sharing their warning signs with me and with the readers of this blog.

Written by israelgat

February 21, 2009 at 9:24 am