The Agile Executive

Making Agile Work

Pains from Los Angeles

with 14 comments

Click here, here and here for stroke-by-stroke coverage of the March 26 Rally event in Los Angeles by Zach. From my own interactions with participants during the event, I compiled the following  list of the most painful issues between an Agilist and his/her executive(s):

  1. The “sausage syndrome”: “Don’t bother me with details how you do the software – just get it done” seems to be the attitude of numerous “business executives.”  I must admit I still don’t get it. Software is becoming pervasive on an unprecedented scale. And, software is becoming bigger and bigger component of just about any product in which it is embedded. Ditto for software as part of the business process. What is your recipe for success if you (as an executive) don’t get down and dirty on such a major component of your business?!
  2. Agile as part of the overall software engineering fabric: This issue is a close cousin of the “sausage syndrome”. Expectations of Agile are unrealistic as it is not grasped holistically as one layer in the overall context of  the art of programming. We direly need a construct like the OSI Reference Model for software engineering.
  3. Agile and the real customer: Much of the emphasis is still on Agile in R&D. The real customer is not iteratively integrated  in the development process. In spite of a ton of data to the contrary, we often drive the iterative development process under the fallacy that the customer problem is well understood.
  4. Agile in the business context: Discussion are usually focused on $$. Most Agilists do not seem to be well equipped to discuss Agile in the contexts of  risk mitigation and compliance.
  5. Assimilating Agile: Little understanding that apprenticeship is a wonderful way to learn Agile. Precious few invest sufficiently in on-going Agile consulting and coaching.

I started the event stating that I feel like one foot in cold water, the other in hot water: we accomplished so much over the past few years, yet much more could and should still be accomplished. I finished the event with precisely the same feeling: a ton of enthusiasm for Agile in the trenches; the immense opportunity to harness this enthusiasm at the enterprise level is not quite happening yet.

Advertisements

14 Responses

Subscribe to comments with RSS.

  1. […] Zach Nies and Israel Gat blogged the event already, no need for dup info. […]

  2. Israel, having been present at the event, I can say that I really valued your opening remarks. I didn’t get to attend your breakout session with regard to “Socializing Agile with your Executives”. I am curious if you provided specific guidance about how to teach your executive to talk to the marketplace, shareholders, and major customers differently when they are adopting Agile. For my part, I think this is key. I believe executives need guidance in what metrics to seek from their teams, and then what information to share with the community about product delivery. I would also contend that executives need guidance about how to create great visibility into product releases. Could you provide some guidance on this? Thanks!

    Jean Tabaka

    March 29, 2009 at 4:37 pm

  3. Thanks for the kind words, Jean!

    The conversation with the executive within the company needs to focus on five topics: A) Agile principles (as distinct from Agile practices); B) the imperative need of the executive to be on the Agile “train”; C) what the executive owns and what he/she does not own in the Agile process; D) what specific deliverables is the executive responsible for in the Agile rollout/process; and, E) behaviors that are supportive of Agile versus behaviors that suppress Agile (see Christophe’s breakout session in LA – http://tr.im/hY3V).

    Initial metric for Agile should be just one of the following three: A) time-to-market (as a function of the release size); B) productivity; or, C) quality. As the executive and the team get sure footed in Agile, the single initial metric could be summplemented in two ways: A) add a second metric of the three listed above to the first one, e.g. both time-to-market and quality will serve as metrics; and, B) add outcome metrics which adress customers, markets or $$.

    The conversation an executive should have outside the company about Agile is a function of what he/she expects to accomplish through Agile. For example. the executive might choose to present Agile as merely a “quality initiative”. On the other side of the spectrum, he/she could actually articulate that the company is pursuing new business designs based on the capabilities of Agile. For example, market-of-one for top customers is a business design that Agile can enable (http://tr.im/hY4g). I will soon compile a full-fledged post on the subject of conducting the conversation outside the company.

    Israel

    Israel Gat

    March 29, 2009 at 7:47 pm

  4. Israel, which agile principles do you concentrate on? I dislike using the Agile Manifesto principles because they are really mostly practices. I tend to use the lean principles from Tom and Mary Poppendieck’s books. I was just wondering what you use to see a comparison.

    Bob Hartman

    March 29, 2009 at 8:08 pm

    • Bob, I do not think it makes any difference in the context of the conversation with the executive. The only thing that matters is seeing eye-to-eye on a set of underlying principles. I consider the agreement on principles critically important as folks often look at the Agile processes and artifacts instead of trying to understand the deeper truths underneath.

      I usually try to express the principles in the most meaningful way to the person with whom I speak. I like the way Jim Highsmith summarizes the Manifesto: “Value over Constraints; Teams over Tasks; Adapting over Conforming.” I usually add Jim’s thoughts about innovation through experimentation to the conversation. If the excutive I speak with is particularly interested in Lean, I usually follow the good counsel of Mary and Tom you refer to. And, I often discuss the Deming System of Profound Knowledge as another “layer” in the discussion.

      One theme I still wrestle with is Complex Adaptive Systems. For one reason or another most people I speak with find it hard to comprehend/accept. Hence, I tend to keep this subject for later discussions.

      Israel

      israelgat

      March 29, 2009 at 9:28 pm

  5. […] Participant responses to the feedback questionnaire from the recent Rally event in NYC and the companion event in LA have been posted in the Rally Agile Success blog. Interestingly enough, in both cities […]

  6. Sorry for the late comment… for me, it’s ironic that you referred to the OSI Reference Model as an analog for how Agile could be taught, explained, and/or understood.

    I started in the networking field when the OSI model was the New Big Thing. It definitely was helpful as a means for understanding varying network architectures, which is how it was meant to be used. Yet I seemed to encounter far too many folks in the field who assumed that the OSI model was meant to be prescriptive, rather than descriptive (thus confusing the OSI _model_ with the OSI _protocol stack_.) This confusion between descriptive vs. prescriptive models is one of the issues that plagues Agile today.

    Dan Breslau

    April 9, 2009 at 8:07 pm

  7. Dan, my reaction (many years ago) to the OSI Reference Model seems to have been quite similar to yours. I felt it gave me the tool and the language to effectively discuss the essence(s) of networking in a holistic manner. I wish I had such a conceptual tool to properly position Agile in the overall software engineering fabric.

    With respect to being overly prescriptive, my own sense of Agile these days is that we emphasize the practices more than the principles. I actually use the quip “Principles over Practices” whenever I start suspecting an Agilist I speak with is too dogmatic.

    Israel

    Israel Gat

    April 9, 2009 at 9:04 pm

  8. Come to think of it, I think there *is* such a model for software processes, but I hesitate to mention it.

    It’s CMMI.

    Before anyone boos me off the stage, I’ll admit that I’ve never actually looked at CMMI, so maybe I’m off-base here. I did have some exposure to its predecessor, CMM, well over a decade ago. I came away from that with much the same take that we’re describing re OSI: In their search for prescriptive solutions, my team had made CMM into something far more bureaucratic than it needed to be. I suspect a lot of teams did the same.

    Dan Breslau

    April 9, 2009 at 9:24 pm

    • I hear you, Dan. I am, however, looking for a richer model (in which CMMI might be a component). The nature of the problem is nicely captured by Cutter Consultant David Spann in his article Breaking the Facade of Truth (http://ow.ly/2xyf):

      Scrum, as a management methodology, is elegant in its design: offering just enough practical advice to agile teams so they do not overcomplicate the development lifecycle with too much ceremony and documentation. However, it is a management methodology, not a software development methodology; therefore, it assumes such matters as sufficient architectural design, appropriate technical environments, and protocols for development, testing, and production are in place. Similarly, it assumes someone or some group is managing the customer/product community so that the product owner can represent a unified and prioritized description of the business need.

      Israel

      israelgat

      April 12, 2009 at 9:49 pm

  9. I think we’re on the same page. The key, as I look at it, is to step back from the OSI model for a moment and remember that it was originally used to organize the answers to a set of questions: How are the bits encoded on the medium? What component(s) ensure accurate, end-to-end transmission of the data? Etc. The answers are well enough engrained in us by now that it’s all too easy to forget what the questions where.

    What I think you’re looking for, then, is a framework for organizing the questions that need to be asked about any software development process (how is the architecture determined? How are builds managed? Who does the testing, and when?)

    With that in place, you could then build an information set (a matrix, a layer cake model, a sausage… 🙂 that shows which questions are addressed by which methodologies. More importantly, this could help organizations identify questions that they’ve forgotten even to ask.

    Using David Spann’s example, Scrum mainly addresses questions regarding the flow of work through the organization, but it [deliberately] does not address architecture and many other important questions. An organization that adopts Scrum needs to understand which questions won’t be answered by Scrum.

    Bringing this discussion full circle: If you keep the focus on the questions, rather than the answers, then you might be able to steer around the prescriptive tar pit that the OSI reference model was turned into.

    Dan Breslau

    April 12, 2009 at 10:47 pm

  10. […] 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 […]

  11. […] a comment » Various posts in this blog (click, for example, here, here, and here) brought up noteworthy threads from the Rally Agile Success Tour events in Denver, […]

  12. […] a comment » Reflecting on the Rally Agile Success Tour in Los Angeles, I discussed the “sausage syndrome” as one of the more painful issues between the Agile […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: