The Agile Executive

Making Agile Work

Posts Tagged ‘Learning Agile

The Things They Say

with one comment

Here is a compilation of summaries of Amazon reviews on the Kindle edition of  The Concise Executive Guide to Agile:

If you are such a decision maker, and like most are hard-pressed for time, then you must read this book. Dr. Gat cuts right to the chase and gives pearls of wisdom – that come from having “done it himself” when it comes to the daunting task of TRANSFORMING an organization into successfully applying Agile methods. If you’re a team leader and you need executive support and buy-in, then buy this book for the key people whom you value the most. Give it to them as a gift. They will thank you for it!

“The Concise Executive Guide to Agile” by Israel Gat is a must-read for enthusiasts of agile methods at all levels of the organization. Israel has well over 30 years of industry experience, has his PhD in Computer Science, and has helped manage an agile rollout involving 1,000 software developers. While there are many technical and managerial treatises on agile methods emerging in increasing frequency all of the time, Israel’s new guide is meant to explain the essence of agile methods to R&D, Marketing, Sales, Program Management, Professional Services, Customer Support, Finance, or IT folks.

Dr. Gat goes beyond the traditional software development process literature and broadens the case for the Agile organization, with effectiveness, efficiency, and integrity – much like the Agile development process described by Israel.

A must read for any organization leader dependant on software whether it be for software for internal operations or software features built for customer sales. Israel’s breadth and depth of both knowledge and experience shine through as he provides practical advice to help you understand what Agile can and can not do for your organization.

For me, this book provided something unique, which is a look into the way high level executives think about Agile.

This book rapidly cuts through the layers of confusion surrounding Agile development and focuses on what you “NEED” to know. Dr. Gat’s vast experience shines through as he elegantly simplifies the process.

Israel’s experience and wisdom in transforming a software development culture in a very large multi-site virtual team environment is well captured…  Israel has done a great job in transforming his experience into a guide. That is the beauty of the book.

This is the “must-read” book if you’re an executive charged with Agile transformation, product development, or business strategy. The insights from Gat cover all three. Most companies talk a good Agile game. If you want results, however, please pay heed to the advice in this book.

The book will help you to flexibly navigate the hurdles inherent in selling and succeeding with Agile in your business: i.e. existing methodologies, outsourcing, diverse geographies, resistance to change, and the rest. They are all explained here by someone who has apparently already successfully fought the battles. A great read!

He has been there, and this book shares the unique insights of a senior manager who guided a large organization through the change process. If you are in this seat in your organization then this book is for you.

Israel distills his broad experience and many years of wisdom rolling out Agile into a succinct overview that is deep in knowledge, but accessible.

I’ve been a fan of Israel’s “The Agile Executive” blog for some time and had high hopes for this book… and the book didn’t disappoint!

While I was looking for answers; what I found instead was much more interesting. Israel was able to collect all the wisdom of doing large scale agile rollouts into one document, highlighting the geographic features along the way. That is a lot harder to do than simply proclaiming one correct path, and, speaking from experience, more helpful to the reader than they know.

You can read the full reviews here.

Written by israelgat

July 21, 2010 at 5:37 am

The Concise Executive Guide to Agile

with 3 comments

a

a

The IEEE Computer Society Press published today a ReadyNote[1] that I authored entitled The Concise Executive Guide to Agile. It is available through the IEEE Computer Society Store. A Kindle version will be published in June.

I had two main objectives in writing the guide:

  1. Provide the know-how for approaching Agile in a concise manner that requires minimal investment of time and effort by the reader. The ReadyNote does so by summarizing most Agile topics in a page or two. Detailed coverage of a topic is left for follow-on reading in the selected references that accompany each topic and in the Further Reading appendix.
  2. Be accessible to any executive  — R&D, Marketing, Sales, Program Management, Professional Services, Customer Support, Finance, or IT.  The only assumption I make is that the reader has a conceptual grasp of software and software engineering as well as an interest in learning about Agile. No deep knowledge, let alone technical knowledge, about software engineering is required for comprehending the guide.

There is no fluff in the guide. Every paragraph has been written to satisfy the “And therefore what?!” criterion. It is my intent to drive a point home and make it clear to the reader what he/she could do with the information in as few words as possible.

A simple acid test for the guide is your successful assimilation of it in entirety during a flight in the continental US. Something has not quite worked if you need to fly all the way from the US to Europe or vice versa in order to comprehend the guide…

I would like to express my sincere thanks to Michael Cote, Michael Mah, Hubert Smits and to the fourth reviewer (whose identity I don’t know) for their many helpful insights and suggestions. I am also deeply indebted to Linda Shafer and Kate Guillemette of the IEEE Computer Society who got me to write the guide and supported the writing and editing process along the way.

Enjoy reading!

Footnotes:

  1. “ReadyNotes are short e-books that are tightly focused on specific topics” [IEEE Computer Society Press].

The System Assumes the System is Right

with 2 comments

The post It Won’t Work Here proposed tactics for dealing with a specific class of arguments why a company should not adopt Agile:

  • Uniqueness: “Some very unique elements exist in our company. These elements render industry data inapplicable.”
  • 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.”
  • 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.”
  • Affordability: “The company is strapped to the degree that investment in another software method is a luxury it can’t afford.”
  • 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.”

This posts augments It Won’t Work Here by shedding light on the reflexive behavior of the system the Agile champion is likely to run into while applying the recommended tactics.

The fundamental distinction the Agile champion needs to keep in mind is between individuals and organizations. To quote from Charles Perrow‘s work on the subject of complex organizations:

One cannot explain organizations by explaining the attitudes and behavior of individuals or even small groups within them. We learn a great deal about psychology and social psychology but little about organizations per se in this fashion.

To successfully function as an entity, an organization must assume that the system put in place to carry out its tasks is right. If the system is not right, the order and integration required for the proper functioning of the organization can’t be maintained. This assumption about being right tends to become all-inclusive. It is applied to both essential tasks and non-essential trivia.

The key to the success of Agile adoption in the face of the “system is right” reflex, is to budget your battles. As an Agile champion you fight only for things that are core to Agile methods, not for the myriad of contextual details about which the system assumes it is right.

For example, I would not spend a lot of energy on determining the unit of measure to be used in the Agile initiative. As an Agilist I prefer stories as the standard unit, e.g. release 2.0 was 500 stories while releases 3.0 constitutes 1,000 stories. But, I would accept lines of code or functions points as the standard unit of measure if the system so prefers.

Conversely, I would not accept system convictions when they violate core principles of Agile. For example, The Agile Triangle advocated by Jim Highsmith views scope, schedule and cost as constraints. This way of viewing Agile software is non-negotiable in my book. The reason for this strongly held conviction of mine is simple – the Agile initiative is likely to fail if the three (scope, schedule, cost) are considered as goals.

Source: based on Figure 1-3 in Jim Highsmith‘s Agile Project Management: Creating Innovative Products.

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.

The Friction of Agile

with 2 comments

Everything is very simple in War, but the simplest thing is difficult. These difficulties accumulate and produce a friction which no man can imagine exactly who has not seen War… This enormous friction, which is not concentrated, as in mechanics, at a few points, is therefore everywhere brought into contact with chance, and thus incidents take place upon which it was impossible to calculate…

IMHO, this excerpt from On War applies exceptionally well to Agile roll-outs these days:

  • Simplicity: The four principles of the Agile Manifesto are intuitively compelling. You could (and probably should) use them as the core definition of what Agile is all about. Likewise, you do not need more than a single hand-drawn matrix to illustrate how WIP limits in Kanban work. In contrast to various other terms used in development and IT – e.g. SOA – the conceptual power of Agile methods is easy to grasp.
  • Friction: Assume you were building a company from scratch without any pre-conceived notions of the organizational constructs you would put in place. Assume as well that you were developing your organization with end-to-end Agile effectiveness in mind. You would probably devise a holistically integrated organization. For example, you might opt for an organizational design in which each level of the organization will include all functions relevant to Agile – R&D, IT, Marketing, Support, Sales etc. In other words, ideally you will not go for the traditional organizational design: a vertical R&D stove pipe, a vertical Marketing stove pipe, a vertical Sales stove pipe, etc.  As in reality you are unlikely to get the charter to start with a clean sheet of paper, the friction arises in each and every point in which your end-to-end organizational design for Agile deviates from the traditional organizational constructs your company uses.
  • Not concentrated: As Clausewitz points out, the friction of war is not mechanical friction – you can’t address it by pouring in a ‘organizational lubricant’ in just a few places. Flooding the whole organization with the lubricant is likely to create a morass in which all agility will be lost.

I recommend four principles to minimize the organizational friction of Agile, as follows:

  • Acknowledge you accrued organizational debt: It is conceptually quite similar to accruing technical debt – various organizational decisions and compromises taken along the way were rushed to the extent that they leave much to be desired. The organizational constructs and practices that sprang out of these decisions need to be refactored.
  • Carry out the organizational refactoring work from the outside to the inside:  A truly holistic Agile design will incorporate customers and partners. Start with the way you will integrate them, thence apply this very same way to the integration of  the organizational entities within your company.
  • Build on the strengths of your core corporate culture: As pointed out by Drucker:

… culture is singularly persistent… changing [organizational] behavior works only if it can be based on the existing ‘culture’… [Drucker, 1991]

Since the end of the Cold War, a fair amount of debate has taken place around the applicability of the friction of war principles to armed conflicts in the information age. The conclusion is of interest to both military personnel, Agile practitioners and IT professionals:

… while technological advances might temporarily mitigate general friction, they could neither eliminate it nor substantially reduce its potential magnitude.

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.

The Success of the Success Tour

leave a comment »

We started the 2009 Rally Agile Success Tour (AST) Series in March in Denver, CO; we just concluded it in London, UK. In between the AST “train” stopped at:

All in all we hosted about 1,000 participants in these cities. More than 40 panelists shared Agile experiences with their local colleagues. Some 200 meetings were held with various participants in conjunction with the events. Obviously, I cannot write here about the level of business generated by the success tour, but none of my Rally colleagues complained so far…

The breadth and depth of topics that were covered is mind-boggling. Here are a few of the most intriguing ones:

The success tour proved successful to a degree that actually perplexed me for quite some time. I had certainly expected a strong series of events from the outset and could point out to various things we were doing right along the way. Yet, the very simple ‘secret sauce’ that made the event series so remarkable eluded me until I collected my thoughts for writing this post:

The Agile Success Tour proved phenomenally successful because the Rally team is so much like the customers and prospects that participate in the events, license the Rally software and work hand-in-hand with Rally coaches.

A few words of explanation for what might seem on the surface like a somewhat banal statement. The various members of the Rally team – sales reps, coaches, technical account managers, marketing professionals and execs – resonated with participants in the events due to exceptionally high level of congruence in values, thinking and practices. If Ryan were the CTO of eBay he would probably have licensed Rally software; Jean would have re-architected the flow of eBay processes; Zach would have integrated the ALM tools eBay uses. As for Lauren, she would have single-handedly created a world-wide marketing events organization for eBay.

The power of being like your own customers is magnetic. Digital Equipment Corporation was immensely successful selling minicomputers to engineers like their own engineers in the 60’s and 70’s. Sun Microsystems rode the early Internet wave as their product designers were carbon copy of the folks who roamed the World Wide Web. Apple triumphed with the iPod because just about every Apple employee would have murdered for such a cool device. Nothing beats the intuitive understanding that comes with designing, marketing and selling the kind of product you will buy, play with and use yourself.

After the Santa Clara event, Forrester’s Tom Grant told me the following about Rally:

What a smart company – everyone gets it!

Though a slightly different perspective than mine, Tom had actually identified the outcome of the company-customer congruence I am highlighting in this post. Everyone at Rally gets it due to natural identification with his/her customers. Contexts and experiences of customers are exceptionally well understood and often replicated in Rally’s Boulder, CO headquarters and its various branch offices.

Fundamentally, the success of the success tour reflects the affinity between Rally and its clientele.

Follow

Get every new post delivered to your Inbox.

Join 38 other followers