Posts Tagged ‘Alistair Cockburn’
Definition: Agile Methodology
Agile Methodology is actually a bit of a controversial term. Various 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
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.
Nuggets from Salt Lake City
Cote has captured my reflections on Agile Roots in the podcast entitled Agile Roots, Agile Operations & Agile Clouds. This post highlights a few nuggets not covered in the interview, as follows:
- Attendance in the conference (>200 folks) was driven only by word of mouth.
- If you ever hear the old excuse “This feature cannot be decomposed to fit in the iteration,” send the person saying so to Alistair Cockburn’s workshop Nano-Incremental Development, a.k.a. Elephant Carpaccio. Amazing what can be squeezed into a nine-minute iteration!
- The nine-minute limit on iteration length might seem artificial. However, as part of his workshop, Alistair indicated top programmers tend to break the tasks they are working on to slices no longer than thirty minutes.
- According to Jeff Patton, Jim Highsmith has recently revised his quip “Barely sufficient process” to “Barely sufficient is too much.”
- Sue Mckinney indicated average size of the development team at IBM’s Software Group has dropped from 500 to 50 over the past few years.
- Reece Newman pointed out that both Brian Marick and I are actually talking about a social contract for Agile. Brian in his response to the question “”If anarcho-syndicalism was crushed during the 1920’s in the United States and its principles inspired the Agile Manifesto as well as Agile software development, why hasn’t the Agile movement been crushed?” Me in the post A Social Contract for Agile. To quote Reece:
Although the content of the Social Contract in Brian’s answer differs from your Social Contract for Agile, the idea of a Social Contract is present in both your blog and Brian’s answer.
- Brian Marick observed that Ruby programmers often tend to work in an Agile manner. In various cases the Ruby programmers were not even even aware of Agile as a software method.
- Reece Newman pointed out that good tools tend to be “culture neutral.” Hence, they can induce behavioral changes without necessitating explicit culture change pushes.
- Last but not least – expect Agile Roots to be held again in 2010!
Agile Roots
How very gratifying it is to experience the evolution of the Agile Roots conference. This is a true bottom-up conference. I only know some of the organizers, but my hunch is that the open source philosophy is at the roots of Agile Roots. There is freshness and genuineness to this conference that clearly come across even before the conference started.
At this point in time, the following speakers have been confirmed:
I will be delivering a keynote presentation entitled Four Principles, Four Cultures, One Mirror. Click here for the full abstract. The short version is as follows:
The path an Agile roll-out should follow depends on the core culture of the corporation: control, competence, collaboration or cultivation. Irrespective of the specific culture, the Agile roll-out invariably tests cultural integration, wholeness and balance. In particular, it exposes inconsistencies between approach with customers versus approach toward other constituents of the corporation such as partners and employees. Consequently, corporate reactions to Agile often express the disappointment of an organization when it is forced to take a good look in the mirror.
I have been known to quip I feel like “one foot in cold water, one foot in hot water” with respect to Agile. So much has been achieved, yet so much is still to be accomplished. I have no doubt the conference will addrress this dissonance, integrating Agile past, present and future in a very insightful manner.
The Agile Executive 