The Agile Executive

Making Agile Work

Posts Tagged ‘BMC Software

Active Releases

with one comment

A Continuum

The traditional way of examining software from a life-cycle perspective is phase-by-phase. The software is developed; deployed; monitored; maintained; changed; and, eventually retired.

True though this description is, more and more executives these days actually view it all as one continuum. An application is developed, and  then deployed and maintained as part of some business process. At a certain level it might not really matter to a business executive what the software life-cycle is and which party carries out what phase. The thing that matters is that some service is performed to customer satisfaction. One could actually do complete  Business Process Outsourcing, chartering  a third party to take care of all the “headaches” in the continuum – from coding a critical software component to repairing a delivery truck to answering calls like, “My shipment has not arrived on the promised date.”

This post looks inside the continuum to comments on the implications of increasing the number of releases. Aspects related to, IT operationsIT service management and the customer as a strategic partner will be discussed in subsequent posts.

Number of Active Releases

The delivery of value to the customer is a fundamental tenet of Agile. The whole Agile development process is geared to that end. Customer value, however,  is realized when the customer is able to start using the product . As deployment cycles for enterprise software can be quite long, time gained through Agile development is not necessarily of immediate value to the customer. For customer value to materialize, the deployment cycle needs to be fast as well.

Companies that use Agile successfully can be quite different with respect to deployment practices. Here is a quick comparison of BMC Software, PatientKeeper and Google:

  • The successful implementation of Scrum at BMC Software led to producing 3-4 releases of the BMC Performance Manager per year.  However, time to deployment by various customers varied greatly.  Hence, a relatively small number of releases was active at any point in time.
  • With PatientKeeper,  Sutherland exploited the hyper-productivity of his Agile teams to produce a relatively large number of releases. When a customer needed a “release” it was downloaded via VPN and installed in fairly short order. Some 45 active releases of the software existed at any point in time.
  • Companies such as Google expedite deployment by using Software as a Service (SaaS) as the delivery mechanism. Google has only one actively deployed release at a time, but produces many fast releases.

As one increases the number of releases, a reasonable balance between velocity of development versus velocity of deployment in the continuum must be struck. To streamline end-to-end operations, velocity gains in one should be matched by gains in the other.

It does not Really Matter if you can Tell the Egg from the Chicken

One can speculate on how things evolve between development and deployment. Whether Agile software development leads to improvement in deployment, or Software as a Service “deployment” induces faster development processes. The Agile philosophy is well expressed in either case. In either direction, the slowere speed area is considered an opportunity, not a barrier. A Software as a Service Operations person who pushes for faster development speed lives the Agile philosophy even if he knows nothing about Agile methods.

Written by israelgat

February 10, 2009 at 2:58 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

Allocating Your Agile $$

leave a comment »

“50-50” is the rule of a thumb many audiophiles use for configuring a good stereo system. 50% of the budget goes toward the speakers; the other 50% toward everything else in the stereo system. The reason is quite simple: stereo systems succeed or fail on the merits of the speakers.

Whatever your Agile budget might be, a good starting point is to spend about 50% of the budget on training, consulting and coaching during the first year of Agile rollout. This figure will probably go down to about 25% during the second year;  precious little thereafter. Such budget allocation was used at BMC Software in its Agile rollout and operation between 2004 and 2008: about 50% of the total Agile budget in 2005; 25% in 2006; single digit percentages in 2007 and 2008.

First Year Agile Budget

Starting with 50% for consulting, training and coaching during the first year is rooted in the software engineer being a craftsman. A craftsman learns and develops through apprenticeship. He learns from the masters. The popular Program With the Stars sessions  in various software development conferences recognize the power of the apprecnticeship paradigm. A good review of the power of such a session in the Agile 2008 conference can be found in the Working Together… with Technology post by Andrew Shafer.

If you accept the premise of the software engineer as a craftsman, you need to invest  in consulting and coaching more than in training. A two or three day Scrum Training class for numerous product managers, developers and testers in your company is, of course,  a good start. However, it is the day-in day-out consulting and coaching that will make the training applicable. There is no substitute to a competent Agile coach saying in the middle of a stand-up meeting “Folks, what happened to our collaboration? We are not getting the benefits of the wisdom of teams.”

In addition to the coaching needs of the teams, you as an Agile executive will probably need some coaching by a sure-footed Agile executive coach. Topics should include the following:

  • Your role in the Agile roll-out
  • Deliverable you own in the Agile roll-out
  • Behaviors that are supportive of Agile
  • Identification of promising indicators for Agile roll-out
  • Identification of early warning sign for Agile roll-out going the wrong way
  • Synchronizing release trains across multiple software development methods
  • Impact of Agile on downstream functions

Don’t think about these coaching items as luxury you can’t afford. Rather, it is money well spent. It is the cost you as an executive need to pay for being on the Agile train. The train might leave the station without you if you do not invest in your Agile education.

Second and Third Year Agile Budgets

The rationale for reducing the investment in consulting, training and coaching in the second and third year is simple. Various Agilists in your company would become experts themselves. Needless to say you will continue to invest in their skills by sending them to a conference such as Agile 2009. Much of the consulting and coaching, however, should over time be done by your home-grown Agilists.

Consider it an early warning sign if the assimilation of expertise in your company has not generated Agile experts in your teams within a couple of years. You could, of course, allocate your Agile $$ in the second and third year on the 50-50 basis recommended above for the first year. But, chances are something is not working well with your Agile roll-out.  The norm in successful Agile roll-outs is to harvest a whole bunch of quotes like the following quip made in 2006 by a QA Director with BMC Software:

 There had never been a thought towards returning to Waterfall. We only think about how to be more Agile, how to do this better. No one wants to go back!

Written by israelgat

January 22, 2009 at 10:47 am

The Core Principle Behind Agile

with 2 comments

Hyper-productive Agile teams, reaching twice, thrice and even higher level of productivity compared to industry average, have been reported by various consultants and practitioners, including Jeff Sutherland, Michael Mah and me. I run into a lot of questions about the reported case studies. Often times I sense that the executives quizzing me about the accomplishments of BMC Software are wishing at some level to find something extraordinary that would explain how my project teams accomplished hyper-productivity. In other words, the reported productivity figures are sometimes considered too good to be true in general.

IMHO Agile hyper-productivity stems from a very simple universal principle: everyone on the team does only the most important things at any point in time. Effectiveness and efficiency are the results of systemic elimination of less important features, functions and tasks.

Various executives ask me the question “Should I adopt Lean Agile or should I do Scrum ?” The answer I invariably give is “To my way of thinking, the two apply the same principle: Lean Agile focuses on eliminating waste; Scrum focuses on the elimination of “waste” in form of the less important.”

I will cover the “secret sauce” of BMC Software’s sucess with Agile methods in forthcoming posts. Before doing so, I would like the reader to come to terms with the following view: the secret sauce we used at BMC was “just” creating the environment within which the less important was eliminated.  What we did was a successful implementation of the core principle: “Do only the most important things at any point in time”.

In a way, our secret sauce was grasping this fundamental principle and developing a whole socio-technical system to free the principle from the metaphorical chains of archaic methods.

Written by israelgat

January 15, 2009 at 5:53 pm

Posted in Starting Agile

Tagged with , ,