Posts Tagged ‘Learning Agile’
The Things They Say
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.
The Concise Executive Guide to Agile
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:
- 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.
- 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:
- “ReadyNotes are short e-books that are tightly focused on specific topics” [IEEE Computer Society Press].
The System Assumes the System is Right
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
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.
The Friction of Agile
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]
- Use modern corporate for the fundamental organizing principles. See Relational Networks, Strategic Advantage: New Challenges for Collaborative Control by Hagel, Brown and Jelinek for a good recent article on the subject.
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
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
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:
- Atlanta, GA
- Boston, MA
- Chicago, IL
- Los Angeles, CA
- New York, NY
- Santa Clara, CA
- Seattle, WA
- Washington, DC
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:
- Agile Business Service Management
- Agile contracts
- Agile Governance
- Beautiful software
- Lean
- Sausage Syndrome
- Software capitalization
- Use of emulation in Agile projects
- Virtuous Cycle of Agile
- Why Agile is natural for Business Intelligence
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.
Scale in London – Part II
What a grand conclusion for a year of Agile Success Tour events! High that my expectations of yesterday’s event in London were, the actual delivery and interaction with the participants surpassed them. As a matter of fact, I have not done as many customer 1-1’s in any of the previous events. Some of the interactions were with folks who came to the event from the continent. Remarkably, various customers stayed after the event to spontaneously dialog with other participants.
Speaking for Memex, Jim Mccumesty established the tone for the whole event. Agile to Jim is about:
- Making a real difference
- Changing patterns of individuals and teams
- Transforming ‘life styles’
Have no mistakes – Jim had a lot of hard methodical and technical data that he shared with the audience. It was clear however that for Jim the whole things is about doing good things through Agile. His passion was contagious.
Trevor Croft viewed the decision to go Agile by Misys as a matter of fitting software methods to business circumstances. Agile was chosen to due to intrinsic characteristics of their Business Intelligence projects. Specifically, Trevor highlighted the following factors:
- BI requirements would be constantly dynamic in breadth and depth
- Needed to be quick to market from vision to delivery
- Higher revenue –> emphasis on innovation
- Break out of waterfall nexus of first trapping all requirements
- Highly modularized factory production line approach for delivery
Trevor’s good points resonated with the trend highlighted by other panelists – the emphasis in Agile is moving toward:
- Delivering the right products; and,
- Delivering innovative products
Paul Lazarus of SpilGames equated Agile with growth. At the heart of it, SpilGame’s fast expansion from Holland to Poland and China was characteristic of the role Agile plays in the knowledge economy. Projects flow to the teams and to the talent, not the opposite way around.
David Hicks gave impressive highlights from the Nokia/Symbian/RADTAC work on the Symbian operating system over the past ten years:
- >50 MLOC!
- In a little over one year they are reaching the level of >1200 software engineers Agiling furiously in >120 teams
- All these folks/teams on a single software product with synchronized release trains every 8-12 weeks
It is enlightening to combine David’s data with Dean Leffingwell’s reports on his experience at Nokia. The affinity of their insights is remarkable. Dean, in collaboration with Juha-Markus Aalto from Nokia, published an excellent paper on the subject. Moreover, Dean is actually ‘binding’ together his insightful blog posts to publish a new book entitled Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise. The book will be published by Addison-Wesley in early 2010.
Much more could and should be written about the London event. Until I have the opportunity to do justice to the subject, I will just mention my overarching conclusion from the event. The business interest in Agile in both the UK and in EMEA is as strong as the one in the US, if not stronger.
Scale in London – Part I
No, this is not (yet) the report from the Rally Agile Success Tour (AST) in London. You will need to wait another week for my report from this forthcoming event. Rather, this post is to advise folks in the greater London area of a an intriguing thread we will be discussing in the Rally event there on Thursday, October 29.
The choice of companies for the event enabled us to offer participants the full spectrum of Agile scaling experiences, all the way to some 1,200 Scrummers on a single product in one case study. As a result, the richness of the forthcoming panel presentations is unprecedented. Time permitting, we will discuss the following subjects, and then some:
- Three-layer enterprise Agile model
- How to maintain integrity of a vertical feature when it has to be delivered by many Scrum ‘component’ teams?
- Bringing multiple teams and multiple SDLCs together on one workflow
- Cultural differences vis-a-vis Agile between Belgium, England, Finland, Holland, India, Israel, Poland and China.
- How do you accomplish Fully Distributed Scrum under the cultural diversity indicated in the previous bullet?
- The use of deep immersion techniques in Agile
- The Agile with the Masters paradigm
- How to maintain the push/pull balance?
- What limit should be placed on the Daily Commit?
- Emphasis on innovation – not “just” faster, better, etc.
- Advantages of Software as a Service (SaaS) in the Agile context
- How to tie the Agile initiative to strategic investment considerations?
- What was the ‘secret sauce’ of BMC’s Agile implementation? How can you apply it in your company/organization?
- What is likely to be the hottest frontier in Agile during the 2010-2012 period?
One other “ingredient” makes the London event very special. All previous events, gratifying and successful that they were, have been held in the US. The event in London will certainly be different from its US predecessors. In experiences, in interpretations, in points of view, in challenges, in business designs and so on and so forth.
I Look forward to meeting you in London!
An Omen in Chicago
Amazing how things come together. A gentleman introduces himself at the conclusion of my breakout session (Socializing Agile with your Executives) in yesterday’s Rally Agile Success Tour (AST) event in Chicago. I am pleasantly surprised to learn he is Cutter Consortium colleague Scott Stribrny. Within a few sentences I discover he was actually the Cutter consultant to Follett Software. As readers of this blog are well aware of, Follett Software was prominently featured in the landmark study of Agile quality, productivity and time-to market by Michael Mah. To put the icing on the cake (so to speak), Rachel Weston – Rally’s Director of Professional Services – uses this very study by Michael Mah in her keynote presentation at the end of the event…
Symphono’s Robert Schmitt started the day with a quote from one of his developers:
I don’t want to deliver just twice a year; I love to deliver!
The power of this kind of craftsman’s pride in his/her software was nicely illustrated by hard numbers Robert cited. For example, on one of their projects, Symphono observed a cost of $12K instead of the $72K they would have expected under traditional software methods.
Playboy’s Mark Row highlighted the intricacies of project managing contents alongside project managing software. In Mark’s experience, contents developers tend to be visually oriented. Writing requirements does not quite cut it for folks of such orientation. As Mark needs to manage software development priorities across all contents initiatives (and many owners), the balance to be struck between the two is quite tricky. The non-formalistic nature of Agile has proven quite effective in bringing things together. As a matter of fact, Mark indicated Playboy’s marketing teams are now doing daily Scrum-like stand-up meeting. The bottom line from the perspective of his executive management is crystal clear:
Night and day since going Agile
Pariveda’s Jim West kept all of us honest with respect to how bad the starting point for Agile often is. According to Jim, they did not start Agile from square zero – they actually started from minus two (-2)…. In spite of this far from optimal starting conditions, Pariveda been successful on two noteworthy accounts:
- Productivity improved by 15-20%
- The managed to satisfy the needs of other processes by incorporating them in their Agile process. For example, SOX work items are represented as story cards in their backlog
Last but not least, ShopLocal’s Brendan Flynn highlighted the progress they made with Agile contracts. They incorporate both user stories and acceptance criteria in the contract. Furthermore, they pay special attention to specifying what is not included in the contract. To paraphrase the French proverb, Shop Local’s experience is that “good accounts make good (customer) relationships.” Remarkably, they achieve good customer relationships through Agile contracts at the scale of 5+ Billion page views annually through just one of their products!
Expressive quips were brought up in the lively Q&A sessions that followed the presentations. Here are a few gems:
Make Agile your flavor [tailoring Agile to the needs of the organization]
Make database decisions [data-driven decisions in Agile]
A cube empire [working environments in the 80’s and 90’s]
Exchange requests, not change requests [Agile contract policy]
In two week the Agile Success Tour “train” will cross the channel to London. (Please, do not enquire now how the train will make its way from Boulder, CO to Paris, France – we are delaying the decision on that leg of the trip to the last responsible minute). I suspect some of the Agile topics to be discussed in London might give a mild heart-burn to UK-based ITIL aficionados. But, how appropriate it is to conclude a year of great Agile success tours with an event in the grand city London!
The Agile Executive 