The Agile Executive

Making Agile Work

Posts Tagged ‘BMC Software

Reflections on Due Diligence

with one comment

I still remember the reception committee from the due diligence on Tideway I did for Apax Partners some seven years ago. The folks were awesome. I am fairly certain they could convince birds to fly off the tree if they chose to apply their very many talents toward this end. I really don’t know whether Apax (who invested in Tideway) and BMC (who acquired Tideway at a later time) consider their investments in Tideway successful. But, take it from me: even the Royal Shakespeare Company would have been hard pressed to stage such a terrific act as the one played by Tideway for my benefit in 2004.

The Thing That Code Does Not Do

Click here for additional thoughts on the subject and its implications.

Written by israelgat

November 27, 2011 at 9:51 am

The BMC Agile Transformation: A Seven-Year Perspective

leave a comment »

This Executive Update represents my current understanding of the deeper reasons behind the success of  the BMC rollout. It reviews past decisions in light of  knowledge, experience, and insights that evolved a long  time after the decisions, for better or worse, had been executed. In general, it’s about my making sense of  things and sharing my insights with Cutter clients.

To download the Executive Update, click here and use the promotion code BMCAGILE.

Time-to-Market as a Function of Release Size (Source: QSM sample of ~7,500 projects)

Written by israelgat

November 18, 2011 at 4:07 pm

How to Combine Development Productivity Data with Software Quality Metrics

with 2 comments

Consider the situation described in Should You Invest in This Software:

  • One of your portfolio companies expects to ship 500K lines of code in 6 months.
  • The company asks for additional $2M to complete development and bring the product to market.
  • Using technical debt quantification techniques you find the technical debt amounts to $1M.

You are not at all comfortable “paying back” the technical debt in addition to funding the requested $2M. You wonder whether you should start afresh instead of trying to complete and fix the code.



Photo credit: @muntz (Flickr)

A good starting point for assessing the fresh start option is Michael Mah‘s studies of software productivity. Based on the QSMA SLIM metrics database of more than 8,000 projects, Michael will probably bracket the productivity per person in a team consisting of product management, development and test at 10-15K lines of code per year. If you use the 15K lines of code per year figure for the purposes of the analysis, 500K lines of code could theoretically be delivered with an investment of about 33.3 (500/15) man years. Assuming average loaded cost of $99,000 per man-year,  the software represents a programming effort of $3.3M. Not much is left if you deduct $3M ($2M+1M) from $3.3M…

Five considerations are of paramount importance in evaluating the start afresh option:

  • The comparison above ($3.3M versus $3.0M) is timeless. It is a snapshot at a certain point in time which does not take into account the value of time. To factor in the time dimension, the analysis needs to get into value (as distinct from cost) considerations. See the note on Intrinsic Quality v. Extrinsic Quality at the bottom of this post.
  • Your “mileage” may vary. For example, best in class teams in large software projects have reported productivity of 20K lines of code per team member per year. As another example, productivity in business applications is very different from productivity in real-time software.
  • If you decide to start with a brand new team, remember Napoleon’s quip: “Soldiers have to eat soup together for a long time before they are ready to fight.”
  • If you decide to start afresh with the same team plus some enhancements to the headcount, be mindful of  ‘Mythical Man-Month‘ effects. Michael Mah’s studies of the BMC BPM projects indicate that such effects might not hold for proficient Agile teams. Hence, you might opt to go Agile if you plan to enhanced the team in an aggressive manner.
  • Starting afresh is not an antidote to accruing technical debt (yet again…) over time. But, it gives you the opportunity to aggressively curtail technical debt by applying the techniques described in Using Credit Limits to Constrain Development on Margin. For example, you might run source code analytics every two weeks and go over the results in the bi-weekly demo.

As long as you are mindful of these five aspects (timeless analysis, your mileage may vary, Napoleon’s quip, mythical man-month effects and credit limits on technical debt), combining technical debt figures with productivity data is an effective way to consider the pros and cons of “fix it” versus starting afresh. The combination of the two simplifies a complex  investment decision by reducing all considerations to a single common denominator – $$.

Note: This is not a discussion from a value perspective. The software, warts and everything, might (or might not)  be valuable to the target customers. The reader is referred to Jim Highsmith‘s analysis of Intrinsic quality versus Extrinsic Quality in Agile Project Management: Creating Innovative Products. See the Cutter Blog post entitled Beyond Scope, Schedule and Cost: Measuring Agile Performance for a short summary of the distinction between the two.

Between Agile and ITIL – Part II

leave a comment »

The July 2009 post Between Agile and ITIL introduced the application of Agile principles to system management with the following words:

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.”

Yesterday’s press release about the acquisition of Phurnace by BMC validates the projection given in the afore-listed post. Colleague and friend Michael Cote puts his finger on the heart of the acquisition in his post in People Over Process:

The interesting part is also that this is automation – I’m assuming – at the application layer, where as most automation talk in past and present is at the infrastructure layer. Of course, the thought leaders in this area – folks like Reductive Labs (Puppet),OpsCode (Chef), and in a more general sense cloud management outfits – are doing a helpful job of blurring the distinction between traditional IT layers like application and infrastructure with their dev/ops angled automation. Check out this white paper done by Reductive Labs and dto solutions on the topic for a nice toe-dip. And, I’d expect to see more application layer automation from VMWare/SpringSource. Older automation portfolios like BMC’s Blade Logic line need to keep a close eye on these developments, hopefully, taking in the proven parts of that work.

One can, of course, automate IT tasks without embracing Agile. The fundamental question to be answered is whether one considers ITIL as an “empirical” process control model or as a “defined” process control model (or possibly a hybrid).

Agile Across the Enterprise: Prioritizing Value in Support and Training – Guest Post by Anne Gentle

with 6 comments

If I could choose a subtitle to Anne’s guest post, I would pick How to Produce a Book in Five Days. While this subtitle does not take into account preparatory work prior to the five days, it captures the essence of the revolution in social publishing. The  intensive collaborative authoring that takes place during book sprints leads to hyper-productivity that transforms the economics of various classes of books.

A thread of particular interest in the post is the path innovation took. Anne walks us from Cote‘s simple question “Why does it take three days to get a PDF out for review?” all the way to producing over 250 pages of documentation in a book sprint. Her story is a great proof point that Experimentation Matters.

Here is Anne:

One of the Agile Manifesto’s basic balance equations is valuing working software over comprehensive documentation. This line of the Agile manifesto can be confusing to some supporting roles in an Agile development enterprise. As technical support staff, trainers, and content creators, what are we doing to fit into this Agile methodology, and what’s working well? Let’s explore some old habits that need to die, and some new rituals to fill that space.

Nowadays, Google’s search power offers software users access to documentation through forums, mailing lists, even through blogs and wikis maintained by the developers and authors themselves. These new conversational methods for documentation, support, and education have opened new opportunities for those groups to add value to software adoption. Ways to provide additional value to the working software include helping people learn the software, troubleshoot the software, or do their job with the software. Education, uptake, and support are all integral to the overall value of a software product.

Value proposition

First, a discussion on the value added by good websites, updated and relevant training materials, and a helpful support staff.  Those departments want to avoid the continual cost center perception. To do so, they find ways to add to the bottom line, such as:

  • increasing sales (enterprise) or increasing adoption (open source)
  • keeping users happy and satisfied
  • adding contributors to the community, whether helpful troubleshooters or prolific coders
  • decreasing support costs (in time and money)
  • converting participation into value
  • increasing positive perceptions of the software

In my experience, these values are universal to both enterprise software and open source software. Let me share my story.

Wikis are an Agile tool

I have been a technical writer on Agile development teams, and working in tightly collaborative environments has taught me a lot about adding value in the customer’s perception. I still remember being challenged by Michael Cote when we were at BMC Software. He asked, “Why does it take three days to get a PDF out for review? Why aren’t technical writers using wikis for documentation?” Those questions prompted quite a bit of research that finally resulted in my book, Conversation and Community: The Social Web for Documentation.

I had a lot to learn to answer Cote’s questions. What to do? I decided a wiki apprenticeship was the answer. At the time, wikis seemed to be the realm of open source software. I was nervous about approaching an open source project with so little experience in open source to draw from, but when a former BMC director sent out a call for help with the One Laptop per Child project, I responded. They had a draft started and we put it on the wiki.laptop.org wiki to start with, as a too-long single article on the wiki. Soon after, FLOSS Manuals approached OLPC to see if they would like to have FLOSS Manuals host the wiki on their wiki site at www.flossmanuals.net. Adam Hyde, the founder of FLOSS Manuals, had built a wiki tool that allowed multiple chapters to be output as HTML or PDF. When I saw what the tool could do, I jumped at the chance. We copied and pasted the entire manual into the FLOSS Manuals site. Yes, copy and paste. But it got the content into a platform that enabled much more agility for the content.

Book sprints are one Agile method

After that initial content seeding, we discussed holding a book sprint to create a better book for more audiences, especially since SugarLabs had formed an organization separate from OLPC to work on the operating system separately from the hardware. A book sprint, much like the Agile sprint term, is intensive collaborative authoring in a week’s time. We run sprints as a five-day event, and use real-time collaboration tools, and sometimes bring all the authors in to a single location and have a bullpen of sorts. Lots of planning goes into a book sprint prior to the actual sprint, such as identifying sources of content that can be repurposed for the sprint, agreeing to the audience for the resulting documentation, and writing an outline for the deliverable, whether it’s intended to be a textbook, a curriculum workbook, an online help system, or a website.

After a sprint planning session on the Sunday of the sprint week, authors are ready to start writing immediately because the outline for the book is set in the wiki. Often we outline with Post-it notes on the wall to start, a familiar sight to many Agile practitioners.

Monday, Tuesday, and Wednesday are heads-down writing days from about nine in the morning until an enforced stop time at six each day. Just like a stand-up meeting, we use a daily conference call to stay in touch with the handful of remote contributors and find out if anyone is stuck or has questions. Thursday is a day for assessing how much we have so far, and what final tasks should be done to make the sprint a success. Thursday night we intentionally plan for a fun event, as the writers certainly have experienced an intense effort like no other and need to have some fun and allow for a release of built-up pressure! Friday is a clean-up and review day, and the final PDF is uploaded to Lulu.com for creating a bound book. We can also export the wiki content to HTML, and either embed it on a website or ship it with the software product itself. In the book sprint for OLPC and SugarLabs, we produced over 250 pages of documentation. You can learn more about book sprints (including examples of the budget for this sprint) by reading the free chapter from my book, or by reading the book about Book Sprints hosted on FLOSS Manuals.

In my journey towards Agile value-add across the enterprise, I learned that wikis are much more likely to be used internally for collaboration, and that there are far fewer examples of wikis where customers and Agile team members are collaborating on training materials, tutorials, reference information, or strategy guides for enterprise software. To shift that adoption rate towards external collaboration, I’m interested in book sprint experiments in the enterprise, as well as additional collaboration methods. Along the way, I’m finding ways to transfer lessons learned in open source to corporate environments. I offer this story as one way that Agile methods applied to other departments and their processes can increase overall value to the software developed.

About the author: Anne Gentle works as a senior technical writer at Advanced Solutions International in Austin, Texas on an Agile development team. She just finished a book with XML Press about using social publishing techniques for technical documentation titled Conversation and Community: The Social Web for Documentation. She volunteers as a documentation maintainer for FLOSS Manuals, working on manuals for One Laptop Per Child and SugarLabs, both education projects dedicated to providing technology for children in developing countries. She writes a blog at justwriteclick.com and welcomes feedback and conversation there. As the mom of two young boys, she loves to be busy while upholding the value of an Agile principle of individuals and interactions (and sometimes refereeing battles over toys).

It Won’t Work Here

with 3 comments

Two major obstacles to vetting Agile topics effectively with executives were identified in the post entitled The Business Value of Agile Software Methods:

  1. Lack of hard quantitative data.
  2. The “It won’t work here” syndrome.

As indicated in the post, the data provided in the study How Agile Projects Measure Up, and What This Means to You and the book The business Value of Agile Software Methods address the first obstacle. This follow-on post is about the second of the two obstacles – the resistance to Agile transformation in the face of hard data on its benefits to other companies.

Resistance in the form of “it won’t work here” is typically anchored in one or more of the following five beliefs:

  1. Uniqueness: “Some very unique elements exist in our company. These elements render industry data inapplicable.”
  2. Secret sauce: “Something very special element existed in the companies reporting great success with Agile. Our company does not possess nor have access to the ‘secret sauce’ that enabled success elsewhere.”
  3. Cultural change: “For the Agile initiative to succeed, our corporate culture needs to change. The required cultural change takes a lot of time and involves a great deal of pain. All in all, the risk of rolling Agile is unacceptably high.”
  4. Affordability: “The company is strapped to the degree that investment in another software method is a luxury it can’t afford.”
  5. Software is not core to us: “We are not a software company, nor is software engineering our core competency. Software is merely one of the many elements we use in our business.”

Various other reasons for not going Agile in the context of a specific company are, of course, cited at some frequency. The five reasons listed above seem to be encountered most often by Agile champions.

Use the following counter-arguments to turn around these beliefs:

  1. Uniqueness: Very rare occurence. Companies use similar business designs, apply fairly standard operating procedures, utilize common technology, are subject to the same regulatory constraints that their competitors are, have offshore sites in places like India, etc. Discussion of your company vis-a-vis its direct competitor usually suffices to overcome the uniqueness claim. 
  2. Secret sauce: The ‘secret sauce’ is neither secret nor difficult to concoct. For example, the secret sauce used by BMC Software in its successful Agile initiative  had four simple ingredient: intentionality, know-how, flexibility and patience. Based on insights by colleague and friend Alan Atlas, I have recently added mutuality as the fifth ingredient. Your own secret sauce might be somewhat different, but I very much doubt that an extravagantly exotic sauce will be needed.
  3. Cultural change: Myth has it that Agile would only work in the Collaborative culture. Reality is it will work in any of the four core cultures identified by Schneider: Control, Competence, Cultivation or Collaboration. See Four Principles, Four Cultures, One Mirror for an approach to building Agile on the strength of whatever culture prevails in your company/organization.
  4. Affordability: The question to ask is whether you can afford not to improve your software. Tools are readily available to quantify your company’s technical debt. Monetize the technical debt and include it as a liability line item in a pro forma balance sheet. Doing so is likely to shift the discussion from affordability to how to create elbow room for handling the technical debt.
  5. Software is not core to us: Indeed, it might not be but it is likely to become so in just about any industry. Use an analogy like the record industry vis-a-vis the publishing industry. The record industry has been decimated by software over the past decade. Chances are a similar decimation is likely to occur in publishing unless the industry transforms itself. (Some of the decimation that already took place in publishing has become quite visible recently. For example, last week Bloomberg LP announced completion of the acquisition of BusinessWeek for a paltry $5M).

You will need to be realistically patient with respect to the time it takes for the considerations listed above to sink in. It could easily take six months just to forge a consensus on the subject in the executive team. It might then take another six month to operationalize the consensus. Chances are there is an elephant hidden somewhere in the “room” if you don’t carry the day with within a one year period of diligently vetting Agile with your executives.

Teach Your Boss to be Agile with a Social Contract – Guest Post by Alan Atlas

with 4 comments

When I [Israel] joined BMC Software in Fall 2004, I made a promise to each and every one of the hundreds of employees in my business unit:

I commit to read and respond within 48 hours to any email you send me. My answer is not likely to be long as I am drinking from a hose right now. But, it will be substantive.

Till this very day, various ex-employees of mine tell me that this simple statement was actually the first step toward our adopting Agile – it created mutuality in our relationships. A few months later, when we started discussing the ground rules for Agile team empowerment, I was credible with respect to adhering to voluntary “contracts” due to the mutuality established in the “email policy” cited above (and other “it cuts both ways” steps we as a management team have taken along the way).

Fast forward five years to today. How delightful it was to get the guest post below from Rally coach Alan Atlas. His post has taken me all the way back to the very gratifying experience of starting the enterprise-level Agile “adventure” at BMC. Furthermore, Alan’s post made me realize I need to add mutuality as the fifth ingredient in my ‘secret sauce’ for large-scale Agile implementations.

Here is Alan:

Hey, how’re you doing? How’s the new Agile thing going? What? Oh, yeah. We had that same thing. The manager thing. Yep. It can be a killer! Wanna know what we did?

Dan Rawsthorne first introduced me to social contracts. He had put together an example that was called something like “Contract Between the Team and the Organization”.  Israel Gat’s work on Agile Social Contracts gives perspective on using them at the enterprise level.

I have put social contracts to good use more than once, and I am convinced that they are a tool that has much to offer to coaches, consultants, and maybe most importantly, internal Agile champions at companies around the world.

Most of us are familiar with the idea of Working Agreements. Working Agreements are a form of social contract that is often used to help a self-organizing team to establish behavioral standards without having them imposed from the outside (e.g., by a manager). Working Agreements are:

  • Established and changed by mutual agreement
  • Enforced by mutual agreement
  • Outside of established corporate legal structure, and
  • Made between peers.

A social contract, at least the way I have seen them created and used, is essentially a Working Agreement between non-peers.  In an Agile context, social contracts are written between a team and its management, or a team and its encompassing organization.

Of what use is an agreement in which each clause can be summarized as “I promise to do something that you want until I change my mind”? I think there are two really important benefits to be realized by using social contracts:

  • They codify and externalize the agreement, making the substance of the agreement clear, and
  • They form the basis of an “interaction between people” (i.e., a conversation).

Here’s an extract from a hypothetical Social Contract:

  1. The Organization and the Team agree that:
    1. Customer satisfaction is our ultimate goal
    2. Mutual respect will be the foundation for trust between all parties
    3. The Team promises the Organization that:
      1. It will develop the most valuable software, as defined by the Organization through the Product Owner, at all times
      2. It will provide transparency in all things related to its activities
      3. The Organization promises the Team that:
        1. The Team’s success will be judged by the production of working software
        2. The Team will have a Product Owner and a Scrum Master and a reasonable expectation of team stability

Yes, it does seem a bit idealistic and maybe even unrealistic. Yet, it is invaluable when used in the following way:

“Hey Boss. One part of launching the team on Scrum is to sit down with you and go over our social contract. Let’s take a look and talk about the things that are in here.”

The social contract is, above all things, a means to direct a conversation with your manager about roles and behaviors in the new world of Scrum. If you can all actually agree on one, and even sign it, Wow! But if you can’t, you can still use it to begin to teach your boss (I bet she wasn’t included in team Scrum training, was she?) how to be a good boss in an Agile world. If you are afraid of broaching certain subjects, arrange to have a neutral Agile coach supply you with an Agile contract, in which case you can’t be blamed for the content.

“The Organization promises the Team that impediments raised by the team will receive prompt and thorough attention at all levels.”

“The Team promises the Organization that it will adhere to all corporate quality standards when building software.”

“The Team promises the Organization that it will maintain the highest possible level of technical rigor through design and code reviews.”

And on and on…

Don’t be too disappointed if it never gets completely agreed and signed and put on the wall. Use it to open up a dialog with your management that you can build on over time.

Written by israelgat

November 5, 2009 at 7:46 am