The Agile Executive

Making Agile Work

Archive for the ‘Lean’ Category

Agile Enterprise Forum 2011

with 4 comments

Charles Handy, Chris Potts, Don Reinertsen, John Seddon and I are the featured speakers in the Agile Enterprise Forum 2011. The Forum will be held on March 10, 2011 in the Chandos House at the Royal Society of Medicine,  London. Attendance is limited to 30 CIOs.

The theme for the forum is Agility for Complex Organizations. The overarching message is nicely captured in the following summary by James Yoxall:

There are two strands of interest for a CIO: strategy and delivery.  The Agile/Lean message can be summarised as “merging” the two, so that delivery can start before strategy is complete, and delivery informs strategy through feedback loops. This leads to a faster/earlier delivery and a better end result.

My own workshop – Agile Governance: Tying Delivery to Value – builds on this message by describing a specific strategic initiative which is not achievable without the use of advanced delivery techniques. Here is the abstract for my workshop:

This workshop will explore mechanisms for unlocking the full potential of existing software through the combination of Agile/Lean methods with technical debt techniques. These mechanisms apply to complex organisations that rely on in-house development teams as well as to third party delivery partners. Israel’s approach emphasizes the need to continuously monitor and mitigate the decay of software that more often than not had been developed over many years. Most importantly, it shows how well-governed software can become the enabler for unleashing the synergistic power of cloud, mobile and social.

You can think of the workshop as linking past, present and future. The “sins” of the past require technical debt reduction initiatives today. These initiatives utilize the classical Agile/Lean techniques of continuous measurement and tight feedback loops. Without such initiative, the value of existing software cannot be unlocked in the future. In particular, competing in the hyper-segmented markets that cloud, mobile and social generate will be next to impossible for legacy software that has not been modernized.

Open-Sourcing the Inovis End-to-End Kanban System

leave a comment »



Source: Gat, Huddleson, Bodwell and Chin, “Reformulating the Product Delivery Process

Colleague and “partner in crime” Stephen Chin has published a post on the Inovis End-to-End Kanban System (aka Apropos) we presented at the LSSC10 conference on April 23.  As readers of this blog might recall, the system tracks features through their full life-cycle from proposal to validation, ensuring actionable feedback cycles. By so doing it firmly anchors the software method in the overall business context with special attention to operational aspects such as deployment, monitoring and support.

Stephen outlines details of the forthcoming open-sourcing of Apropos as follows:

The plan for this tool is to do the initial launch of a BSD-licensed open-source version on May 22nd.  This will include support for the Rally Community Edition, which is free for up to 10 users.  In future releases we plan to support other Agile Lifecycle Management tools, both commercial and open-source, but will need assistance from the community to do this.

If you are interested in helping out with this project, please contact me.  I will have limited bandwidth until after the initial launch, but after that would love to scale up this project with interested parties.

I really can’t wait till the 22nd. IMHO Apropos has the potential to become the leading Kanban system by the community for the community.

Apropos – The Inovis End-to-End Kanban System

with 4 comments



Figure 1:  End-to-end flow slide from Reformulating the Product Delivery Process

Erik HuddlestonWalter BodwellStephen Chin and I delivered a presentation at LSSC10 on the design and implementation of the end-to-end Kanban system Apropos at Inovis. The presentation highlights four key ingredients of the ‘secret sauce’ that makes Apropos so powerful:

  • Stakeholder Based Investment Themes
  • Business Case Management
  • Upstream and Downstream WIP Limits
  • Dynamic Allocations

You can read the slides here. A recording of the presentation will soon be posted by InfoQ. A commercial friendly open-source license of the code will be available on May 22, 2010.

Reformulating the Product Delivery Process

leave a comment »

LSSC ATLANTA 2010

Erik Huddleston, Walter Bodwell, Stephen Chin and I will  present and demo an end-to-end Kanban system that addresses the #1 challenge modern software methods pose – reformulation of the product delivery process. We will do so the coming Friday, April 23, 10:45AM at the Lean Software and Systems Conference. Here is the abstract for our presentation/demo:

Software methods can be viewed as the glue that holds the product development process together. With Kanban, the glue is melting on both sides of the process. Traditional portfolio management systems and organizations have difficulty coping with the granularity of Kanban. Likewise, today’s product release and delivery systems and the corresponding organizational constructs are ill-equipped to effectively handle the Kanban flow.

We present a field-tested system for implementing Kanban on an end-to-end basis – from product ideation through continuous delivery. This system reformulates the deconstructed product delivery process to strike an optimal balance between planning, development and operations.

Written by israelgat

April 21, 2010 at 3:25 am

Harnessing Economies of Scale in Cloud Computing to Realize a Greener Computing Option

with 2 comments

Economies of Scale have been much discussed in The Agile Executive since the recent OpsCamp in Austin, TX. The significant savings on system administration costs  in very large data centers have been called out as a major advantage of Internet-scale Clouds. Unlike various short-lived advantages, the benefits to the Cloud operator, and to the Cloud user when the savings are passed on to him/her, are sustainable.

In this guest post, colleague and friend Annie Shum analyzes the various sources of waste in operations in traditional data centers. Like an Agilist with Lean inclinations who confronts an inefficient Waterfall process, Annie explains how economies of scale apply to the various kinds of waste that are prevalent in today’s small and medium data centers. Furthermore, she connects the dots that lead toward a Green IT option.

Here is Annie:

Harnessing Economies of Scale in Cloud Computing to Realize a Greener Computing Option

Scale Matters: “Over time, however, competitive advantage within categories shifts inexorably toward volume operations architecture.” – Geoffrey Moore, “Dealing with Darwin”

It is a truism that today’s datacenters are systemically inefficient. This is not intended as an indictment of all conventional datacenters. Nor does it imply that today’s datacenters cannot be made more efficient (incrementally) through right sizing and other initiatives, notably consolidation by deploying virtualization technologies and governance by enforcing energy conservation/recycling policies. There are a myriad of inefficiencies, however, that are prevalent in datacenters today.

Many industry observers lament the “staggering complexity” that permeates on-premises datacenters. Over time, most, if not all, enterprise IT datacenters have become amalgamations of disparate heterogeneous resources. Generally, they can be described as incohesive, perhaps even haphazard, accumulations. The datacenter components and configurations often reflect the intersections of organizational politics (LOB reporting structures leading to highly customized/organizational asset acquisitions and configurations), business needs of the moment (shifting corporate strategies and changing business imperatives to gain competitive edge or meet regulatory compliances) and technology limitations (commercial tools available in the marketplace). It should come as no surprise that human interactions and errors are considered a major contributor to the inefficiencies of datacenters: IBM reported that human errors account for seventy percent of the datacenter problems.

The challenge of maximizing energy efficiency begins fundamentally with the historical capital-intensive ownership model for computing assets to enable each organization to operate its own datacenter and to provide “24×7 availability” to its own users.  The enterprise IT staff has been required to support unpredictable future growth, accommodate situational demands and unscheduled but deadline-critical events, meet performance levels within SLAs and comply with regulatory and auditing requirements. Hence, datacenters generally are over-configured and over-provisioned. In addition to highly skewed under-utilization of distributed platform servers, ninety percent of corporate datacenters have excess cooling capacity. Worst of all, according to IBM, about seventy-two percent of cooling bypassed the computing equipment entirely. Further compounding these problems for a typical enterprise datacenter, is the lack of transparency and the inability to control energy consumption properly due to inadequate and often inaccurate instrumentation to quantify energy consumption and waste due to energy lost.

The economics of Cloud Computing can offer a compelling option for more efficient IT: by lowering power consumption for individual organizations and by improving the efficiency of a large number of discrete datacenters. Although the electricity consumption of Cloud Computing is projected to be one to two percent of today’s global electricity use, Cloud service providers can still cultivate sustainable Green I.T. effectively at lower costs by leveraging state-of-the-art super energy efficient massive datacenters, proximity to power generation thereby reducing transmission costs and, above all, harnessing enormous economies of scale. To better understand how Cloud Computing can offer greener computing in the Cloud and how will it help moderate power consumption by datacenters and rein in run-away costs, a good starting place is James Hamilton’s September 2008 study on Internet-Scale Service Efficiency” as summarized in the table below.

Resource Cost in

Medium DC

Cost in

Very Large DC

Ratio
Network $95 / Mbps / month $13 / Mbps / month 7.1x
Storage $2.20 / GB / month $0.40 / GB / month 5.7x
Administration ≈140 servers/admin >1000 servers/admin 7.1x

Table 1: Internet-Scale Service Efficiency [Source: James Hamilton]

This study concludes that hosted services by Cloud providers with super large datacenters (at least tens of thousands of servers) can achieve enormous economies of scale of five to seven times over smaller scale (thousands of servers) medium deployments.  The significant cost savings is driven primarily by scale. Other key factors include location (low cost real estate and electricity rate, abundant water supply and readily available fiber-optic connectivity), proximity to electricity and power generators, load diversity, and virtualization technologies.

Will this mark the beginning of the end for traditional on-premises datacenters? Can enterprise IT continue to justify new business cases for expanding today’s non-renewable energy powered datacenters? According to the McKinsey article, the costs to launch a large enterprise datacenter have risen sharply from $150M to over $500M over the past five years. The facility operating costs are also increasing at about twenty percent per year. How long will the status quo last for enterprise IT considering the recent trend of Cloud service providers? Major players such as Google, Microsoft as well as the U.S. government itself have invested in or are planning ultra energy-efficient mega-size datacenters (also known as “container hotels”) with massive commoditized containerization and proximity both to power source and less expensive power rates. Bottom line: will the tide turn if the economics (radical cost savings) due to enormous economies of scale become too significant to ignore?

Despite the potential for significant cost savings, it is premature to declare the demise of traditional IT or the end of enterprise datacenters. After all, the rationale for today’s enterprise IT extends well beyond simplistic bottom-line economics – at least for now. To most industry observers, enterprise datacenters are unlikely to disappear although the traditional roles of enterprise IT will be changing. A likely scenario may involve redistributing IT personnel from operating low-level system operational tasks to addressing higher-level functions involving governance, energy management, security and business processes. Such change not only would become more apparent but will likely be precipitated by the rise of hybrid Clouds and the growing interconnection linking SOA, BPM and social computing. Another likely scenario is the rise of the mega datacenters or “container hotels” for Cloud Utility Computing providers. Although the global economic outlook will undoubtedly play a key role in shaping the development plans/timelines of the mega datacenters, they are here to stay. Case in point: by 2012, Intel estimates that it will design and ship about a quarter of the server chips (it sells) to such mega-data centers.


Connecting the Dots: Operational Excellence, Strategic Freedom and the Pursuit of Passion

leave a comment »

My recent post The Headlong Pursuit of Growth, and Its Aftermath applied insights from Toyota Motor Corporation to Agile methods. Among various lessons to be learned, the post highlighted the relationship between mechanism and policy: 

Just like the Toyota Production System, your software method is a “vehicle” which is subject to policy decisions from above. It cannot, however, compensate for policy failures.

In other words, operational excellence in Agile methods is not a substitute for strategy/policy. It does not confer strategic freedom.

In another recent post – I Found My Voice; I did not Find My Tribe – the vicious cycle that leads to loss of passionate Agile talent was described as follows:

This “1.5” phenomenon is at the root of a vicious cycle that dilutes companies, particularly these days:

  1. A round of layoffs is implemented.
  2. Just about everyone takes notice and tries to exhibit the “proper behavior/values.”
  3. Folks in the “private tribe” don’t dare come out of the closet.
  4. The passionate person who found his/her voice in Agile is like a fish out of the water. Sooner or later he/she looks for a tribe elsewhere.
  5. The company becomes more diluted on folks who are willing to try new things and have the drive to make them happen.
  6. The products and the supporting processes continue to be mediocre.
  7. Goto step 1.

Reading the article Getting Toyota Out of Reverse, published in the December 18 issue of BusinessWeek, I found a fascinating linkage between the two posts:

“They say that young people are moving away from cars,” Toyoda said. “But surely it is us—the automakers—who have abandoned our passion for cars.”

One had better take notice when the president of Toyota speaks of the effects of loss of passion using phrases like “irrelevance or death” and “grasping for salvation”.

You need go no further than John Hagel‘s recent post Pursuing Passion for a resounding second opinion on the subject.

The Headlong Pursuit of Growth, and Its Aftermath

with 4 comments

The December 12-18, 2009 issues of The Economist features a couple of fascinating articles on Toyota Motor Corporation. According to The Economist, Toyota’s President  reached the following dire conclusion on the situation Toyota is facing:

Mr Toyoda’s alarm call last month appears partly to have been prompted by reading “How the Mighty Fall”, a book by Jim Collins, an American management writer, which identifies five stages of corporate decline. Mr Toyoda reckons that Toyota may already be at the fourth stage. Companies at this point, says Mr Collins, frequently still have their destinies in their own hands, but often flit from one supposed “silver bullet” strategy to another, thus accelerating towards the fate they are trying to avoid.

In the litany of things that went wrong, an interesting point is made about the Toyota Production System:

… the recalls continued and Toyota started slipping in consumer-quality surveys. A year later Consumer Reports, an influential magazine, dropped three Toyota models from its recommended list. The magazine added that it would “no longer recommend any new or redesigned Toyota-built models without reliability data on a specific design”. People within the company believe these quality problems were caused by the strain put on the fabled Toyota Production System by the headlong pursuit of growth.

Whatever Agile method you practice – Scrum, Lean, Kanban, Crystal, etc. – you need to be cognizant of three touch points with the Toyota experience reported above:

  • Just like the Toyota Production System, your software method is a “vehicle” which is subject to policy decisions from above. It cannot, however, compensate for policy failures.
  • If your company relentlessly pursues growth, the quality/technical debt liability it is likely to incur coud easily outweigh the benefits of growth. Consider the upside potential of growth vis-a-vis the downside of the resultant technical debt. When appropriate, monetize technical debt using the technique described in Technical Debt on Your Balance Sheet.
  • In addition to monetizing the technical debt, evaluate the various kinds of risks indicated in The View From The Executive Suite. A sense of how devastating those might be is given by Toyota’s own experience:

Just as Cadillac used to be synonymous with luxury and BMW with sportiness, Toyota was a byword for quality and reliability… The danger in all of this for Toyota is that its loyal (and mostly satisfied) customers in America have long believed that the firm was different from others and thus hold it to a higher standard. The moment that Toyota is seen as just another big carmaker, a vital part of the mystique that has surrounded the brand will have been rubbed away.

Please remember – unless you work for Toyota Motor Corporation, chances are your company would not be able to take the kind of risk Toyota can.

Socializing Kanban with Your Executives

leave a comment »

The topic Socializing Agile with Your Executives has been a major thread in this blog. A convenient to browse compilation of posts on the subject can be found in the Starting Agile category. In particular, two recent posts – The Business Value of Agile Software Methods and It Won’t Work Here – are quite specific on the data to use and the line of reasoning to follow in such discussions.

When it comes to socializing Kanban with your executives, you might choose to start the conversation by looking at the defect tracking system your company is using. Chances are your executive will “discover” the all important aspect of flow simply by examining the system with respect to some natural questions such as:

  • Have more defects been closed than opened over the past month?
  • What is the average time to close a reported defect?
  • How many defects have been open (in one stage or another) in the system for more than a year?
  • When a defect moves from one stage in the system to another, how does it get aligned with the various activities that need to take place in the release management system?
  • If development and QA were to stop everything they do and just work exclusively on closing defects that have already been captured, could they clean slate in six months?

The power of this straightforward approach lies in the ease of making the mental jump from defect to Kanban in the context of the tracking system. The breaking down of an epic or a story to granular components that can be pushed to members of the Agile team is not always an easy concept to grasp (and often times a technique teams struggle with in the initial phases of an Agile roll-out). In contrast, one can simply visualize defects entered into the tracking system as inputs to a de-facto Kanban system. Obviously, the defect/Kanban maintains its identity as it “flows” through the system all the way from being reported by a customer to communication of its resolution to the customer. 

If your defect tracking system does not easily lend itself to answering the questions listed above, you might try one of the public domain data sets from Mining Software Archives. The specific data, of course is not likely to be applicable to your company. The criticality of flow, however, could probably be demonstrated by making a few fairly straightforward assumptions on the operating environment behind the data.

Written by israelgat

December 8, 2009 at 5:35 am

Between Agile and ITIL

with 4 comments

You do not need to be an expert in Value Stream Mapping to appreciate the power of speeding up deployment to match the pace of Agile development. By aligning development with deployment, you streamline “production” with “consumption.” The rationale for so doing is aptly captured in the first bullet of the Declaration of Interdependence:

We increase return on investment by making continuous flow of value our focus.

As pointed out in previous posts in this blog, Flickr and IMVU seem to be doing an exceptionally fine job streamlining the flow of value: every thirty minutes and every nine minutes respectively. A recent presentation in Velocity 2009 by John Allpsaw and John Hammond adds color how development and operations at Flickr cooperate to accomplish “10+ deploys per day.”

What does such fast pace mean to the business? In a nutshell, much of the guess work as to what features are really needed is eliminated when you develop, deploy and collect customer feedback in ultra fast manner. Consequently, the company’s business design is likely to be transformed. Click here, here, and here for more detailed discussions how the business design gets transformed.

Michael Cote, Andrew Shafer and I have been pondering  about aligning development and operations for quite sometime. On the one hand, we are painfully aware of the traditional desire to minimize change in IT operations. On the other hand, we are of the opinion Agile principles are quite applicable to operations. We often wonder whether the obstacles between Agile and ITIL are real or imaginary. We actually believe the {development –> operations} theme is an important instantiation of Dean Leffingwell‘s recent thoughts about applying Agile/Lean principles to other knowledge work.

The three of us – Michael, Andrew and I – decided to do a few podcasts to explore what stands between Agile and ITIL. The first of these podcasts will be published this month (July 2009).

Stay tuned…

Written by israelgat

July 7, 2009 at 7:19 am

Continuous Improvement is Always the Glue

leave a comment »

Corey Ladas makes an interesting observation in Scrumban, pp. 73:

Continuous improvement is always the glue that binds the social contract of the lean organization. Everybody is expected to improve, at all times.

Corey’s observation is quite relevant to the commitment proposed in the posts A Social Contract for Agile and Addition to the Social Contract:

Commit to invest in Agile training ; apply the training to employees who  might be affected by forthcoming layoffs just as you apply it to those likely to be kept with the company. 

The commitment discussed in these posts is an ingredient of the glue Corey writes about.

Written by israelgat

July 1, 2009 at 9:39 pm