Archive for April 2009
Observations from Houston
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.
Agile 2009
I will be doing two sessions in Agile 2009 – a presentation and a panel.
A Main Stage presentation entitled The Role of the Agile Leader in Reconfiguring the Business. The abstract is as follows:
This presentation applies Agile thinking to critical aspects of strategy and execution at a time of uncertainty and disruption. The essential point is simple and logical: Agile values and principles are indivisible. To succeed, they must be applied not just to R&D, but also to customer and company, simultaneously. This requires reconfiguration of customer relationships, employee policy, software development, and the relationship that binds the three. The resulting paradigm shift could lower the cost of software and produce prosperity similar to the one induced by ultra-cheap oil in the 50’s.
An Agile & Organizational Culture panel, in collaboration with Laureen Knudsen, Stephen Williams and Scott Killen (moderator) entitled Agile in the Enterprise Corporation. Here is the abstract:
We know why engineers use agile but should Executives fund it? Through this panel discussion learn the benefits of Agile for those that hold the checkbooks:
*Why Executives should see Agile as a necessary change
*Benefits of Agile to an enterprise business, including non-engineers
*Justify funding for training, tools, etc
*Link Agile metrics to the balanced scorecard without compromising the principles of AgileIndustry leaders Stephen Williams (HP), Laureen Knudsen (Qualcomm), and Israel Gat (BMC) tell how they use Agile to positively impact all areas of large, global, corporations.
Stay tuned…
A Single Point of Accountability
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.
Timing and Duration of the Agile Roll-out
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:
- An executive’s budget is under pressure.
- Headcount reduction is carried out. Remaining employees are expected to somehow cope with the load.
- Agile, with its promise of higher productivity and possibly hyper-productivity, is introduced as a counter-measure to the reduced headcount.
- The remaining development resources are expected to acquire a new set of skills, to master the art of Agile.
- 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.
- 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.
- Goto #1 above.
To preempt such cart-before-horse situation, the following principles need to be adhered to:
- Don’t introduce Agile before “the system” adequately adjusted to a round of headcount reduction.
- 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.
- Establish a quantified baseline of productivity before starting an Agile roll-out. Measure Agile progress against the baseline.
- 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.
A Note on Transparency
InfoQ posted the London 2008 QCon panel on the topic Transparency: A Great Leap Forward or Exposed Artery? The question addressed by this panel is summarized as follows:
Agile propagandists make great claims about the advantages of being transparent about the state of their projects. They claim that this how mature relationships work and that “Honesty is the best policy”. But is this true? Many of us work in dysfunctional organisations where honesty is the best way to get cheated. Surely Transparency is just not pragmatic?
Quite a few interesting facets are highlighted in the discourse between the audience and panelists Kent Beck, Keith Braithwaite, Steve Freeman, Chris Matts and John Nolan. For example:
- The power of the simple statement “It is what it is.”
- Is the issue deeper than “just” transparency? For example, is it a matter of values?
- The harsh reality in the trenches that revolves around transparency. Meaningless statements like “I need it for SOX compliance” have been known to be made.
- How does one induce organizational change to improve transparency? In particular, how does one do so amidst organizational dysfunction?
I would add one observation to the numerous good points made by the panelists. Ultimately, the most critical form of transparency is with respect to the user. There is no substitute to his/her feedback on an on-going basis. If you need to address transparency as part of your Agile roll-out or evolution, start with transparency to the user. It can be as simple as making the arrangements for some real customers to attend your release planning and bi-weekly demos.
Punching Above Your Weight Class
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.
Startups should be Built to Learn
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:
- 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.
- 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.
- 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.
Companies make shoes!
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
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].
The Agile Executive 