The Agile Executive

Making Agile Work

Archive for the ‘Starting Agile’ Category

A Seven Year Retrospective

with one comment

The results measured by Michael reaffirmed for me a core belief that I had developed as a young man in the Israeli army: ordinary people can achieve extraordinary results. We did not have, with all due respect, extraordinary talent at BMC; our development tools were nothing to write home about; the problems of communicating effectively across 10.5 hours of time zone difference from Austin, TX to Pune, India were very real; and, we were subject to repeated layoffs. What we accomplished was primarily a matter of doing the right things by an extremely important stakeholder – the business unit employees.

Click here for a detailed account of the 2004 experience from a 2011 perspective.

Written by israelgat

October 1, 2011 at 6:56 am

Definition: Agile Methodology

leave a comment »

Agile Methodology is actually a bit of a controversial termVarious authors consider Agile a method, as distinct from a methodology. Others, prefer methodology over method. For example, using the Merriam-Webster dictionaries, Alistair Cockburn makes the following distinction between methodology and method in Agile Software Development: The Cooperative Game :

  • Methodology: A series of related methods or techniques
  • Method: Systematic procedure

Alistair views Agile as a methodology in the sense defined above. For example, he discusses Crystal as a family of methodologies. The reader is referred to Alistair’s book for a an excellent analysis of the various aspects of methodologies. As a matter of fact, Alistair tracks down the confusion between method and methodology to certain inconsistencies between various versions of the Oxford English Dictionary.

On the other hand, best I can tell from various conversations with him, Jim Highsmith seems to prefer the term Agile Method. This preference is reflected in Agile Project Management: Creating Innovative Products. It is possible that Jim’s preference is due to writing his book from a project management perspective.

Rather than getting in-depth to the method versus methodology controversy, I would simply cite two definitions I find useful in capturing the essence of Agile methodology, or method if you prefer.

An interesting metaphor for Agile has been used by Jim Highsmith in a 2009 Cutter Advisory:

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 way without losing the richness of the various elements in Agile.

Using Scrum as an example, colleague David Spann gives the following down-to-earth summary of the key structural components of Agile in a 2008 Cutter Executive 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.

Needless to say, the structural elements will change from one Agile methodology to another. However, examining an Agile methodology through the {roles, ceremonies, artifacts} “lens” is an excellent way to summarize an Agile methodology. Furthermore, it enables easy comparison between the ‘usual suspects’ of Agile – Crystal Methods, Dynamic Systems Development, Extreme Programming, Feature Driven Development, and Kanban. The reader is referred to The Business Value of Agile Software Methods: Maximizing ROI with Just-in-Time Processes and Documentation for detailed comparisons between the various methods/methodologies.

Definition: Agile Development

with 2 comments

The difficulty to concisely define the term Agile Development stems from the very nature of the Agile Manifesto:

  • The manifesto is a statement of values. By the very nature of values, people share them in a loose manner. Both definition and adherence (“But do they really practice Agile development?”) are qualitative and open to interpretation.
  • The manifesto values are relative. The manifesto is quite explicit in stating “… while there is value in the items on the right, we value the items on the left more:”

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiations

Responding to change over following a plan

Agile development is often described in terms of the software method in use. For example, in his foreword to Agile Software Development with Scrum, Bob Martin summarizes Agile methods as “… people oriented software processes that work without getting in the way,” Martin Fowler emphasizes another aspect of Agile methods in his own foreword to the very same book:

… a new breed of software processes which are based on an empirical approach to controlling a project.

A more detailed definition is given by authors Rico, Sayani and Sone in their October 2009 book The Business Value of Agile Software Methods: Maximizing ROI with Just-in-time Processes and Documentation:

Agile methods are contemporary approaches for creating new software based on customer collaboration, teamwork, iterative development, and response to change. Combining communication and interpersonal trust with a flexible management and development framework, they contain just enough process to capture customer needs in the form of user stories and to rapidly create working software. However, the key to Agile methods are rich, high-context communications with customers along with cohesive teamwork.

On the other hand, such an authority (and signatory to the Manifesto) as Jim Highsmith does not seem to define the term Agile Development per se in the second edition of Agile Project Management: Creating Innovative Products. Instead, Jim defines Agility through two statements:

Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.

Agility is the ability to balance flexibility and stability.

Likewise, in Agile Software Development, Alistair Cockburn focuses on discussing what is core to Agile, emphasizing the properties of Agility through the following citation:

Agility is dynamic, context specific, aggressively change-embracing and growth-oriented. It is not about improving efficiency, cutting costs or battening down the business hatches to ride out fearsome competitive ‘storms.’ It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share and customers in the very center of the competitive storms many companies now fear.

Rather than trying to reconcile all these worthy definitions, I would suggest five context-dependent approaches to the definition, as follows:

  • For the reader who tries to understand what Agile is all about: It is the mindset that really matters. Read the Agile Manifesto and the corresponding History.
  • For the reader who is anxious to put his/her hands around an Agile implementation: Pick a specific Agile method – any method – and study it with special emphasis on the roles, process and artifacts of the method. It could be Crystal, Extreme Programming (XP), Scrum, Dynamic Systems Development Method (DSDM), Kanban or any other method that shows promise as a good fit  for your specific environment. Consult 10 Steps for Starting an Agile Start-up for a down-to-earth blueprint for implementation.
  • For the reader who tries to assess whether a project team is really Agile: It is a maturity curve issue that manifests itself in quite a few disciplines. For example, see the various kinds of maturity models surveyed in the BSM Review blog. You will probably need to determine the maturity model that suits your environment and apply it to the method you are practicing.
  • For the reader who needs to explore Agile in a business context: You need not worry about the technical aspects of Agile. See the category Benefits of Agile in this blog.
  • For the reader interested in applying Agile beyond development: Extending Agile changes its definition. See the various posts on the subject by Eric Ries in Lessons Learned.

Please remember: when it comes to defining Agile Development, you have a problem of choosing, not of choice. It is the use to which you put the definition that determines the choosing.

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

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

Don’t Take Your Boss to Lunch

leave a comment »

During my Agile 2006 presentation I made the following recommendation to the audience:

Don’t take your boss to lunch; take him/her to the daily stand-up meeting.

The point I was trying to get across is straightforward: there is no substitute to “touching” Agile and being touched by Agile. Instead of preaching the benefits of Agile, get your executive engaged in the Agile process.

Last week, colleagues Ken Collier, Jonathon Golden and I were on a Cutter Consortium consulting engagement. The CEO of the company we were consulting to immersed himseld  in the workshop. I would say he spent about 50% of his time in the three day workshop in which we worked with his team on Agile and refactoring.

This CEO certainly got it [Agile]. And, he took his CTO and us to lunch.

It might have been a breach of my own counsel don’t take your boss to lunch…

Written by israelgat

September 27, 2009 at 6:18 pm