Agile 2005 Conference Notes

20 min readFeb 19, 2022

[The notes for this conference are a combination from several people, including myself, which I have edited to reflect things I found interesting.]

The first day at Agile 2005 featured a keynote delivered by Brian Marick and Bob Martin in the morning and an afternoon tutorial on Agile Project Management: Reliable Innovation, delivered by Jim Highsmith.

Agile Project Management

A theme in both the morning keynote and the afternoon tutorial was the role of project management in agile projects. As people scale up their agile efforts, they see the importance of the role of project management but done with a more agile approach. [A particularly specific book about this, though many years old, is The Software Project Manager’s Bridge to Agility by Michelle Sliger and Stacia Broderick which translates PMI’s PMBoK concepts into how Agile achieves them.]

Related to this topic, the conference was a bit of a coming out party for the Agile Project Leadership Network and the Declaration of Interdependence (DOI). [In the Agile 2004 notes post, the “Dead Fish Society” was the precursor to this. Unfortunately, the APLN no longer seems to exist.] The following DOI statements were developed by a group of agile project managers in a meeting between the two conferences:

We increase return on investment by making continuous flow of value our focus
We deliver reliable results by engaging customers in frequent interactions and shared ownership
We expect uncertainty and manage for it through iterations, anticipation and adaptation
We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference
We boost performance through group accountability for results and shared responsibility for team effectiveness
We improve effectiveness and reliability through situationally specific strategies, processes and practices

These statements, along with the people behind them, were intended to drive a shift in traditional project management approaches.

Keynote: “Where were we? Where are we? Where are we going?”. (Brian Marick and Bob Martin)

A few takeaways for me were:

The ‘flow of value’ (see bullet one of the DOI) is a key component of agile methodologies. We want to deliver value to the customer throughout a release, not just at the end.
In progress metrics are critical for measuring customer value, especially finding a way to measure project velocity in customer valued units.
While the agile consultants have been promoting agile ‘brands’ (XP, Scrum, Crystal, etc), the industry has been picking the best components of various agile techniques and integrating them into their process. We should expect to see a convergence of agile approaches, a core body of agile knowledge, and a decrease in the importance of the brands. [This clearly has not happened.]

Highsmith Tutorial on Agile Project Management

This tutorial was broken into two main parts: a review of our understanding of agile project management and the key enterprise issues associated with agile development:

· Being able to respond to change late in the cycle is a huge competitive benefit.

· To innovate, you need time to reflect. [Deliberately building this into the team’s time will send the signal that innovation truly matters.]

· Focusing on improving quality tends to benefit cost, schedule, and staff size as well as defects. [Faster, cheaper, better is the hope for any improved way of working. Agile approaches could be faster, but they definitely can deliver value sooner which may help reduce costs by reducing errors and misinterpretations. They should, however, also deliver better results both from a pure defect-free perspective but also by increased customer satisfaction.]

· Scope creep has long been considered a negative in project management. But we can learn much during a project which we can take advantage of to improve the product.

· A useful analogy for predicting the course of a software project is predicting the path of a hurricane. As time goes forward, people have much better information to narrow the time, location, and scope of the hurricane. Regarding applying this idea to software projects, it doesn’t mean we don’t try to predict and get better over time; but we must realize that we’re making estimates with a high amount of uncertainty.

· Formality doesn’t mean discipline, nor does discipline mean formality. Many agile methods are both highly disciplined and informal.

· Engineering practices should not be classified as either agile or not agile. The underlying principles are what make a practice agile. Code reviews, not generally considered agile, can be done with low ceremony focus on quality.

· Highsmith reviewed the impact of uncertainty and complexity have on a project. The higher the uncertainty, the greater need for agility. The higher the complexity, the more structure that is required. Highsmith also leveraged some very good material from an article that Todd Little of Landmark Graphics wrote for IEEE Software, May/June 2005 titled “Context-Adaptive Agility: Managing Complexity and Uncertainty.”

While there were several testing sessions at the conference, the role of QA and software testing in agile is evolving. A useful tool from the conference is Brian Marick’s quadrant for understanding different types of tests

[You can find this discussed in the testing work of Lisa Crispin and Janet Gregory.]

Tutorial on Engineering Practices of Agile Methods (Jim Highsmith)

Highsmith talked about “technical debt” which is accumulated design/architecture issues that are “patched” into the system without refactoring (i.e., redesigning) to maintain integrity in the system. Belady and Lehman talked about this concept (i.e., the need to invest deliberate effort to maintain design integrity over time) in their book Software Evolution in analyzing the data from the IBM 360 project which occurred [now about 60] years ago.

Highsmith also noted that it’s difficult keeping formal documents of any kind up to date, suggesting the use of wall charts, stickies, white boards, etc. and photographing results (and daily changes) with a digital camera. Then, if you need formal documents, you can always turn the photos over to someone to transcribe into document form [or simply accept the photographs as the documentation]. What is the true value of formal documents as probably only the last version matters?

The “Customer,” in agile terms, is the person/organization paying for the development. The customer can ask at any time and receive feedback on the quality of the software at that moment.

Focusing on “what” before “how” helps the customer in defining their needs and requirements. For example, if you ask someone, “What words do you know?” the answer is “A lot,” but they can’t write them down for you all at once.

Earlier application of test expertise helps the team get good at finding issues. Developers also know quickly just what works and if they are really “done” when tests exist and daily (at least) builds occur that run them. [At my last full-time role an internal enterprise coach, the company had evolved to where they could run hundreds of thousands of tests every night, knowing the stability of the 40M line of code system at the start of each day.]

Law of Mobility

“If you find yourself in a situation where you are neither learning nor contributing, move somewhere where you can.” [This was repeated at every Open Space session I ever attended over the years but could apply to any session. On the other hand, Alistair Cockburn once encouraged session attendees to try to find at least one thing which could be taken away, even from a less inspiring talk, and use it in some helpful fashion.]

Experience Report on Applying Agile Methods within a More Traditional Environment (John Cunnigham (IBM))

Cunningham noted a couple points I found of interest:

· Customers care about predictability and quality (and the value both bring to a project).

· You need a “stuffer” role to do all the “stuff” the traditional environment requires so that the team itself is not burdened with it. This is something the (project) manager can do for the team to shelter them from the “stuff.”

Keynote on “A Few More Things Nobody Wants to Talk About” (Tim Lister)

Here are some points Lister made in his Keynote:

· We don’t need “pilot projects” when we feel good about our ability to succeed and about our ability to recognize early when things are not going well and have the ability/willingness to stop and change course.

· Managers have almost no collegial environment and no, even informal sometimes, way to learn how to do the job. Classes in management don’t seem to address stuff that matters. Why not pair managers?

· QA is viewed as a bottleneck. It’s supposed to be! (At least at one level.) When we don’t like the time QA takes, it is probably because QA “is reacting to the cacophony of what goes on before it.”

· Getting requirements agreement is not a “neat” activity (from an enjoyment or cleanliness perspective). “Gathering” requirements suggests they’re out there just waiting to be found and collected. They’re not in most cases. They’re “invented.” (He recommended Gerry Weinberg’s book Are You’re Lights On. I also like his book Exploring Requirements which is not an agile-specific one but addressing ways to uncover requirements.)

· “Estimating is overwhelmed by expectations.” There is great skew in the data since things often come in late and over budget but rarely early and under budget. We seem to provide estimates with great precision, down to the day, but, in truth, rarely have a right, based on part performance, to estimate more than the season!

· “Cargo overload” (functionality that is late or not delivered) is a common problem. Lister suggests we have to learn to separate goals from estimates, i.e., what we hope/want to achieve from what we can honestly say we can do based on past performance. (We can then address risks and issues to try to meet goals knowing honest estimates.)

· Software is uninteresting. It’s a medium, nothing more. What’s interesting is what we envision the software will do for us.

· “Never lose the satisfying feeling of making something valuable together with your friends.”

· “It’s hard enough to develop software when everyone’s trying to do it.” Imagine how hard it is when they aren’t.

Commoditizing Agility (Joshua Kerievsky)

[It’s interesting to consider what now exists in the form of agile-related training and certifications given the things said in this session.]

The cost and time to transition to a new methodology is expensive, so people often simply do not try (or make it if they do). A large organizational transition involves a very diverse set of people and groups in a company. Many of these groups are not initially considered. For example, early and frequent delivery of software with customer feedback may require significant involvement by the legal department based on how current client contracts and non-disclosure agreements are written. [Or how the agile team focus could impact traditional annual performance management systems.]

There is a problem of “serialized knowledge transfer” which is repetitive and boring for those delivering it and which impedes getting into deeper, more productivity affecting methods/techniques. One goal is to build a “community” within the organization that is very good such that they can do the “tech transfer” to others. It takes a higher level of organizational commitment to get this to happen which is often hard to achieve compared to getting an individual group’s management to try out agile approaches.

Perhaps it is time for the agile community to develop some “packaged” training as is done in other domains (e.g., marketing and sales) using videos/DVDs and interactive computer-based training? This would allow the basics to be presented in a way that works and is scalable.

Experience Report on introducing XP (Jon Spence of Medtronics)

Should “upper” management really care what methods are used if product commitments are met. Many companies are not “software shops” in that they sell products/services other than their software. If IT supports that other product/service delivery, who cares?

He noted that they met all FDA expectations and that the auditors were quite accepting of the documentation they produced. (But getting assessors and auditors comfortable with agile approaches will take some effort.) [I have had success working with most auditors and assessors in this regard.]

Open Space discussion points on “Should we be considering the overselling of agile methods?”

Doesn’t everything in IT get oversold with the “applause meter” swinging back and forth over time? There is always going to be a passion about something new if people have seen benefit in it. (Of course, true believers can often make something “work” simply because of their passion and enthusiasm for it since these latter things are what, probably, make many things really “work.” That, of course, results in others saying, “Sure it worked for you. Anything can be “made” to work in a small environment.”)

How should we be selling agile methods? What would we envision we need to do to get agile methods to a point where they are commonly (and correctly) understood (if not accepted)? People will look for someone to, generically, tell them how to do it, though.

Maybe we should focus on values and principles first, not methods. [This is a theme I have tried to promote for the past decade in my own coaching and training. I am hoping to get sessions approved for Agile 2022 on this topic.]

General Thoughts/Information

Here are some other takeaway thoughts and pointers to related items:

· When does doing things the “right” way start to cost less than doing them the “wrong” way? Theoretically, of course, it should happen from the very beginning but, depending on how costs are calculated and what costs management may be sensitive to, up front expenses may be more visible than backend ones.

· Agile methods don’t solve all (even most) problems directly. For example, adaptation to change is not made easier initially because the change is to agile methods. While points of resistance may differ, the job of being a “change agent” and making change occur in an organization remains regardless of the change. [A lot of advice and ideas at sessions during many of the early agile, and other, conferences was about basic change management. A book called Fearless Change, by Rising and Manns, was mentioned at a couple sessions in this conference. [A book, not specifically related to an agile approach but which addresses organizational change is Leading Change by John Kotter. You can read about his 8-step change approach on his website.]

· Perhaps the hardest aspect of agile methods to get across to those from traditional development environments is the fact that design is so “distributed” across many artifacts. Requirements exist in the form of user “stories” and use cases. Test cases clearly exist. The code is there, of course. But “design” exists across all of them and more, including the wall charts, stickies, and digital photos.

· Take a look at Deming’s 14 Points since most of them can be related to agile methods concepts/techniques. This may be a way to “sell” agile ideas to folks from a more traditional quality background.

· Folks from Thoughtworks gave a talk and used the term “behavior-driven development” rather than “story/test driven” as a way to engage Business Analysts more in test/condition definition using the FIT test approach. Otherwise, the BAs viewed “test” writing as work for QA, but they did believe they were in the business of defining “behavior.”Agile 2005 Conference Notes

I used to attend agile and quality related conferences years ago and have saved notes from many of them. While some topics have become overtaken by events since then, there still seem to be some useful ideas that I’d like to pass along. [These notes are a combination from several people, including myself, which I have edited to reflect things I found interesting.]