Agile 2008 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.

[Again, this is a combination of my notes and those of some others. Fortunately, I had not lost track of the names of at least a couple of those people.]

Keynote Highlights

There were three keynotes delivered at the conference.

Certainly the most entertaining (as well as technically interesting) was the opening one by Robert Martin who spoke about the importance of “clean code,” a topic of his new book. He urged everybody to focus on writing clean code: “Craftsmanship over Crap.” [Unfortunately, the video to this talk seems no longer to exist, but seek out many YouTube videos of other talks he has given. Martin also gave a dinner talk which is mentioned later in these notes.]

The second keynote was by James Surowiecki, the author of The Wisdom of Crowds., who spoke about how “wisdom of crowds” could apply to self-organizing teams. A carefully formed team can make better decisions than any lone individual expert. [His view matched well with the 11th agile Principle and I have more details about his talk later in these notes.]

The closing keynote speaker, Alan Cooper, was received by the audience with skepticism over his ideas concerning the software lifecycle. [I’ll have more detail on his keynote later in these notes.]

Conference Growth

This year, over 1600 people attended from more than 50 countries — a 400 person increase over last year which had ~300 more than in 2006. Notable this year was a new structure which had 35 sessions going on in parallel, making it impossible to attend many things that seemed like they would be interesting. All sessions were 90 minutes in length. Some had one speaker/leader, others had 3 speakers for 30 minutes each. Some workshops were double sessions of 180 minutes, as well. Based on the quality of some sessions, there were clearly too many going on at once.

Several things were missing this year that seemed to me to have been important elements of past conferences:

· Many “luminaries” were absent, e.g., Kent Beck, Ward Cunningham, Alistair Coburn, Jim Highsmith, and Ken Schwaber. [The absence of such people at these conferecnes, noted in prior notes, started quite early as you can see.]

· There was no obvious Agile Project leadership Network presence. This is the group that works to apply agile concepts to project management in all domains, not just software.

· Open Space was even more relegated to a side act this year than last. Open Space is where attendees can propose and have a space where they can hold ad hoc discussions. Other conferences call these Birds-of-a-Feather sessions and usually hold them in the evenings while Open Space runs all day and into the evening in parallel with everything else going on. It may be that organizers have felt, especially with the large jump in attendees the past couple of years, that the quality/value of Open Space is not enough for most conference attendees to make it an important part of the conference. I know I have had interesting discussions in the past at Open Space and feel the lowered attention given to it may be a self-fulfilling action.

What follows are day-by-day notes of the sessions I attended (and felt had some value) and what I thought was of interest in each of them.

Monday — Research tracks

I attended many of these, but also used this day to meet up with many people that I only get to see once a year because they are from other countries (mainly in Europe). Among these was a Finnish research/professor who will be taking over the agile standards work for IEEE. The idea of an agile “standard,” defining the customer-supplier relationship, not standardizing techniques and practices, has drawn ISO attention as well. So this work may lead to an ISO effort that will be a world-wide standard. [Again, as noted in the prior conference notes posts, this never happened.]

Perhaps the most interesting research presentation, as many are by graduate students on their dissertation work, was by Dr. Ahmed Sidky (a consultant and member of the McIntire School of Commerce at the University of Virginia) who, with his students, has developed what he believes is a useful agile maturity/adoption assessment tool (and 5-point scale). This would seem to be attractive to corporate folks, i.e., an assessment they can take on-line to tell them how agile they are. However, many people simply feel this sort of thing will do to agile what assessment has done to the CMM®/CMMI® work over the years by focusing attention on the result (and the speed of getting it) rather than the process for achieving the result. [Dr. Sidky is now known for heading up the ICAgile training certification program.]

Keynote (James Surowiecki)

Surowiecki noted that three things are needed for effective group wisdom:

1) The capability to aggregate many perspectives and for the group to have access to that information;

2) Diversity at a cognitive, not HR,/sociological, level to bring in the necessary variety of perspectives;

3) Independence of people in their ability to voice honest perspectives.

Aggregation is clearly necessary to accumulate the many views necessary for the group’s intelligence to take effect. Individual opinions in isolation would just leave you with dozens, hundreds, or thousands of data points and no analytical/statistical summation of them.

Diversity prevents following wrong paths as extremes of opinion can cancel one another out and avoid pursuing extraneous paths. This is especially true and valuable in smaller groups as it avoids “pre-determined” answers and undue influence of homogeneous groups [often called group-think]. Indeed, Surowiecki claimed that small, homogenous groups become “dumber” as their ideas are echoed back at themselves. In such situations, further collaboration actually produces less effective results. You need a “devil’s advocate” perspective and people willing to have “a good fight.” However, the group must then commit to go forward and implement the result. (Surowiecki referenced work by Scott Page at the University of Michigan.)

Finally, independence is needed to overcome the pressures that exist if people feel they must not diverge too far from the opinions of those hierarchically higher in an organization’s structure. Of course, leadership will not get good feedback if “subordinates” cue their feedback to what they think leadership wants to hear. (Command and control is the assumed culture in most hierarchical structures. Much visible effort may need to be devoted to overcoming the natural command-control pattern of a hierarchy.) However, a lot of the time, imitation is a successful strategy, in the small (i.e., for individuals or very small groups). If everyone in an organization works this way, it fails due to the homogeneous group effect of the group’s ideas being echoed back at itself. Surowiecki also stated that, implicitly, we punish independent thought. We don’t wake up saying, “I’m looking forward to conforming today.” On the other hand, do we wake up saying, “I’m going to act independently today”? This can result in outlier views being more likely to be penalized — perhaps just through indifference — than middle of the road ones.

As an example of the challenge in finding where the knowledge is buried in an organization, Lew Platt of HP was quoted as saying, “If HP knew what HP knows, we’d be a lot more successful.” There is a lot of knowledge in an organization that never surfaces. An increase in formal documentation, however, is not likely to be an effective way to capture this. It has to come through more informal, more “public” channels of direct, open communication.

When it came time for questions, I asked Surowiecki what impact his ideas had when he spoke about them in organizations. He stated that, when an organization did accept his observations, he saw a change in the expectation of what is considered “diverse” and what constitutes “expertise.” This did not denigrate the need for true skill since access to knowledge is needed, i.e., you can’t take a random group of people and ask them to decide without data/knowledge. It does not take “expert” knowledge, however.

Surowiecki also noted that larger crowds work better, but 6–8 people can work well. However, you must work harder to get diversity and maintain independence in smaller groups. Limiting the feedback rounds (in a Delphi approach) will avoid harmful “group think” regardless of the group size. It is true, though, that smaller groups are not as good at pulling out non-shared (individual) knowledge within the group since concern for what others think is stronger when individuals are more easily identified within the group.

When asked about how good crowds are at predicting outlier events, Surowiecki stated that there is no reason to think they are better at this than experts. But, he asked, are the “black swans” really the critical ones to care about? They are often events that capture great attention because they are so unexpected by most people, but are they the ones that have the most long-term affect on an organization?

Finally, Surowiecki was asked what group homogeneity concerns say about (not) breaking up a “well-functioning” team. He stated that this was not as great an issue long-term if people do not spend a lot of time together outside the team’s work situation. If they have both close working and social bonds, then gradual group homogeneity, while it can be excellent for productivity, may not be as good for decision-making. This suggests some rotation of people within groups and seeding new groups with experienced people from functioning teams is not a bad idea as long as the critical functioning group structures are not totally broken down.

A Model for Questioning Agility (Scott Barber)

This talk was the first of several in a track called “Questioning Agile” which I spent a good bit of time in since I wanted very much to see people’s (mis)perceptions of agile methods and their application. Barber is a tester by profession (as was the track chair, Jon Bach) and noted that questioning things is a primary function of testers on software projects.

During the session, three points seemed significant to me:

· One indicator of the agility of an organization is to ask “How agile is the manager if anyone is more stressed out than s/he is?” That is, the role of the manager/leader in an agile project is to take on impediments and allow the team to focus on delivery. If the team is stressed about impediments, then the manager/leader/organization is likely not being as helpful in impediment removal as required.

· If you don’t know the business case for what you’re doing (no matter your role, i.e., admin to CEO), you’ll likely encounter stress.

· Quoting Jerry Weinberg, “It’s not complexity, but our reaction to the complexity that matters.”

Storytelling Skills for Teams (Rebecca Wirfs-Brock and Rachel Davies)

The double (180 minutes) workshop began with a few minutes of discussion about issues related to traditional requirements such as impersonal language and usually missing rational/context. This is precisely what the agile story approach is intended to address. But stories are tools for collaborative planning, not mini-requirements specifications. In this regard, Ron Jeffries “3 Cs” were emphasized:

· Card — index cards are usually used to emphasize that stories are not intended to be comprehensive explorations of requirements in and of themselves, but reminders of topics that need discussion and collaboration.

· Conversation — the communication between Product Owner(s) and development team(s) is the essence of the story approach to requirements in an agile context. Stories exist to remind us to have such conversations.

· Confirmation — to know when a story is delivered, it is necessary to have “DONEness” criteria which confirm satisfactory completion of the story (from a business value perspective).

A small bit of time was spent talking about what is called “abuse” stories (or “anti-requirements”) which represent capabilities to be avoided in the software. For example, some would be very serious such as security flaws, others would address “user errors” that should be caught.

The story form known as an Epic (or Theme) refers to “overarching” requirements and large user context. This is very useful for release-level planning, allowing a whole set of stories to have context placed around them and allowing iteration level discussion to go faster since everyone is assumed to have already discussed these larger concerns during release planning.

Wirfs-Brock spent some time talking about “designer” stories: once-a-release stories about concerns that developers have, i.e., what’s tricky, hard, etc. or what needs to be done to lay a foundation for getting other things done successfully.

Panel on Troubleshooting Distributed Agile Projects

This was a group of people from various agile consulting firms, talking about their experiences managing distributed agile teams. To start, the moderator asked the audience and panelists what countries were/had been involved in distributed teams for their projects and over 25 were called out.

The panel’s first advice was not to forget that “There are people on the other side.” This was a theme for much of the rest of the advice. As an illustration of this, several of the panelist’s companies used offsetting hours on both sides, i.e., some people coming in earlier than usual to allow the others to not have to work as late.

Another piece of advice was that “Distribution comes at a price.” At the start of a distributed engagement, you should bring everyone together, at least once, for a few iterations. (Panelists were all using 2-week iterations.) They also recommended always having at least 1 person from each location at the other location(s). [Of course, since the distribution patterns brought on by COVID-19, this advice may have to wait before it can be practiced again. I have experienced with approach in the past and it has had significantly positive impact on distributed team culture.]

Besides the above suggestions, the panel was asked to list recommendations for starting well. They said:

· training and coaching everyone — business and technical, staff and management;

· leveraging technology (e.g., video) [which we have had to do these past two years];

· understanding cultural differences;

· agreeing on communication and work patterns;

· agreeing on engineering practices;

· using work to achieve team-building.

Regarding technology, the panel said that tools help to “administer” distributed work, but you should not replace low-tech tools (e.g., task board) with purely electronic means.

Panel on Crafting User Stories

This panel was a series of “summaries” and question-answering by those present, though 3 of 4 panelists were replacements for people who were originally listed. Gil Broza was the sole original listed member.

Gil Broza:

1) stories and story exploration should be viewed as evolutionary with “just enough” detail;

2) each story should have business justification (but just what “the business” meant involved some later questions and answers);

3) a shared “glossary” needs to exist, or evolve, so people fully understand what one another mean (but not a written one necessarily, though this might be a useful archival record for someone to create);

4) legible (yes, neatness counts) so various people did use a tool to collect stories and print out the actual story cards;

5) the familiar role-action-context format (e.g., ‘user logs on with an expired license’) was recommended (but Hussman had another suggestion);

6) it’s important to know where a story “fits in” (to the overall project theme/goal);

7) it’s important to know when a story is done — make it measurable, i.e., clear “DONEness” criteria;

8) it’s important to get the size right — Eckstein had something to say about this;

9) for estimating, prefer “small, medium and large” to numerical pointing and try relative placement, i.e., smaller/larger comparisons, to get an overall sequence of size/complexity.

Jutta Eckstein:

1) a story has to show “Business value” for somebody, but the issue was the many different user types, not all who are end users;

2) a team does ~5–10 stories per iteration, so story size depends on this rule of thumb and the iteration length.

David Hussman:

1) an alternative to the role-function-value template is the use of personas as they allow more context than single story formats and can show a “theme” — an entire work/experience flow.

2) get people “talking in tests, i.e., discussing acceptance and “DONEness” criteria”;

3) themes allow the Product Owner to roll up a lot of stories into a release view, so the Product owner isn’t faced with just a lot of little things;

4) suggest use of rock-paper-scissors as a “pointing” technique for medium, small and large relations — as Hussman said, “You’re never without your estimation ‘tool’ that way”;

5) get to the conversation and do not bog down debating what a point means — if the debate is an issue, someone is not trusting the team’s ability to deliver, so points are the red herring to avoid having that more important (and difficult) discussion.

Ellen Gottesdiener:

1) clarity and scope are important (e.g., “DONEness” clear margins, business value);

2) need a “big picture” for context in a larger project, i.e., a “business architecture” to drive release planning;

3) don’t forget to consider external interfaces/dependencies in story-writing;

4) “ilities” (i.e., non-functional requirements) could have their own stories or be part of the “DONEness” criteria of others;

5) some work-ahead (by the business side) is beneficial;

6) the team should ask “What’s the smallest possible thing that the business could use” to elicit workable stories that can be done in a short period of time.

During Q&A a couple other points emerged:

· Ask “If you had that, what could you do?” to help identify value.

· What is “the business” that needs to get value? Is it just the marketing/sales/end-user/client view or is it the entire company view? If the latter, then a Product Owner view may not be comprehensive enough if it is just based on who will use, or pay for, the software. There can be value to “the business,” “the customer,” “the company,” “the user,” “the product,” … vs “the project.”

Panel on Fully Distributed Scrum

This was a panel about Scrum teams that span locations, i.e., not individual teams all in one location.

As with all the other distributed agile advice, this panel also urged co-locating everyone for a while, then distributing the teams, so that team culture and expectations are built first. Then, as new people join teams, send them to the other location(s) for a while. As others had suggested, the advice on new teams was to seed them with members from experienced ones, but do not break up whole teams.

Jeff Sutherland emphasized that stronger definitions of “done” will raise velocity [byt reducing waste in rework asnd building confidence in the work that is accomplished].

Cultural Communication Issues (Rayhan and Haque)

This talk was about distributed issues, though it could have been about cultural differences and communication even in collocated teams.

Much of the cultural issues discussion would be familiar to many people such as, for example, how “Okay,” in Asian cultures, does not mean “Yes, I understand and will do that.” It must be understood to mean “I heard you.” Regarding this, I suggested a technique used in auditing and interviewing which is not to rely on questions and statements that can be answered easily with an “Okay” response. It is necessary to ask people “How” they would then pursue doing the thing to which their response was “Okay.” Their answer to this will reveal what the “Okay” meant to them (or should mean to you).

Another point was how certain cultures will, to meet promises, work extreme hours, so pushing them into such promises, without knowing it, can cause unstated friction in their feelings regarding the work and/or the onshore (part of the) team.

Future of Agile (David Anderson)

Anderson was one of the members of the first FDD (Feature-Driven Development) project team in Singapore many years ago. His background, however, includes Lean principles, modeling, Goldratt’s Theory of Contraints, Deming’s work on the Theory of Profound Knowledge, and, recently, collaboration with people at the SEI on Agile in a CMMI® environment.

Anderson stated that enterprise agility requires a CMMI® Level 4 maturity. CMMI does work. We don’t need an agile maturity scale as some have proposed. Level 4 focuses on objective predictability and predictability allows you to be more agile and respond to change faster. But, for this (and Level 5), you need institutionalized learning — a Kaizen culture, borrowing from the Japanese approach to team work. Unfortunately, agile teams can be very good at CMMI Levels 2&3, but not beyond. Kanban (and Kaizen) helps teams get to a Level 4 maturity. (Anderson pointed to an Agile 2007 paper by Jeff Sutherland on how Level 4&5 organizations adopt agile better.)

Anderson raised an approach many of us had not heard of before: Real Option Theory. He stated it was a way to be responsive and adaptive. Unfortunately, he did not have time to go into it more fully as most people were asking about the CMMI/Agile connection. (I have started to look into this topic, but most material, so far, involves investment decision-making, though it is clear from some websites that ideas are being applied/tried in other domains.)

An interesting comment he made was that “We prefer being right but prefer being wrong more than uncertain.” Hence people may rush to an answer or decision to avoid not having one rather than think about just when a decision must be made. The idea of setting a time-box on when a decision must be made, though, is an agile idea from Lean know as the “last responsible moment.” That is, a deadline is established, but much thought goes into determiing when that has to be to avoid decision-making before all the knowledge is available that could be used to make it the best decision at that time.

Are You Still Agile — Workshop

The idea of this 90 minute sessions was to have the audience divided into “purists” and “pragmatists” to argue whether, in a couple scenarios, behavior had been compromised to the point where it was no longer deserving of the name “agile.” The teams took their positions and presented their points of view. An experienced agile practitioner and a researcher, J.B.Rainsbeger and Ahmed Sidky, served as “judges,” providing feedback to both teams on how well they presented their case. It was an interesting session, for the experience, but did not produce a lot of results that seemed new to me.

Sidky did make a good point about how “reliance” on documentation can prevent communication or imply that the documentation is the first/best/“real” source of knowledge for the project. Thus, documentation, in the name of archival need and efficiency, should not be allowed to replace the need for people to communicate as the key in-process form of exchanging information.

Banquet Keynote (Robert Martin)

Martin was the person who originally suggested that the various agile methods practitioners get together to talk about their shared beliefs. This led to the Agile Manifesto. As such, Martin is regarded highly by many in the agile community and is an entertaining speaker. Amidst his humor, four things struck me that he said:

“The only way to go fast is to go well.”

“Feel urgency but belie that by calm behavior.”

“How can you release code if you are not sure it works?”

“Anything you do to make code harder to read makes it harder to write.” (Martin has recently released a book called Clean Code which talks about this.)

Keynote (Alan Cooper)

Cooper, among other software he has developed, originated the product sold to Microsoft which became Visual Basic.

Cooper’s main point was a discussion of multi-stage development, which, he claimed, was how we work in software. Unfortunately, waterfall “is an obsolete implementation of a multi-stage process.” The process he described, at a very high level, had four “stages”:

· Big Idea — requirements, vision, needs, etc.

· Design — high-level analysis (and architecture)

· Engineering — preparation for construction in process, QA/QC planning, tooling, lower-level design, etc.

· Construction — coding and testing (all forms of testing)

Mary Poppendieck’s talk on Plank Roads (some thoughts by Ronica Roth and Steve Stolt)

Mary Poppendieck provided a software history lesson in an effort to address the question, Is Agile the latest ‘trend’ or ‘silver bullet’ that will go away?

[What follows immediately are Ronica’s thoughts, but she could not stay for the whole session, so Steve filled in later.]

Mary began by explaining the history of Plank Roads. In the 1800s plank roads were invented. Supposed to be a vast improvement in transport, since these roads didn’t get rutted and muddy. Idea was to get people to build them, and investment would be returned in 10 year. PROBLEM: No one expected that these roads would actually last half that long. No one could get their investment back because roads didn’t last long enough.

Mary then took us through a history of software Plank Roads — solutions to the ‘crisis of software engineering’ — that were ultimately short-sighted and didn’t work. Throughout she also identified some gems — ideas from the history of software industry that now appear in Agile.

That ‘crisis’, identified at a 1968 NATO Conference, was that software was getting more and more complex and thus harder and harder to create with no “breakthrough,” no “silver bullet” envisioned at that time.

There were solutions proposed on a New York Times project:

• object-oriented (structured programming)
• continuous integration (structured programming)
• chief programmer teams — lead programmer designs, codes, peer reviews, simultaneous testing, libraries. Common code ownership. Technical leadership.

· BUT, people didn’t think we could count on replicating chief programmer teams, because we could not count on a super-coder existing and because we need fungible resources.

Then some historical Plank Road ideas were offered:

• Barry Boehm’s work on costing software projects.
• Focus on finding problems early to reduce costs
• McCracken & Jackson in 1982 imposing a project management structure on systems development. However, one restrictive process made no sense because it was
• Impossible to predict requirements fully up front, and
• The process itself changes users’ understanding of what can be done.

Further Plank Road moments emerged:

• 1980: Relational Databases / Query Languages
• 1982: Applicaton Development Without Programmers (James Martin) with 4th generation languages believing this would solve software engineering crisis, because users will be able to write software. Obviously, that didn’t happen [but has been a continuing theme over the years].

More Plank Roads included:

• More project management life cycles to model systems development (i.e., mismatch). Spiral, RAD, etc
• Perfect Storm of 1995: The Internet “is not software” but is growing, and Y2K.
• …

[Here is where Steve’s notes pick up.]

However, sSome things in the world of software have continued to work:

• Technical Vision: J.C.R. Licklider
• Robustness: Distributed, independent agents
• Standards emergence through broad-based discussion

· PC’s with separable Architecture and small, focused programs using staged deployment: early releases, regular updates.

Then, there was the Pittsburgh Airport. Mary told a great true story about the talented County Engineer who was in charge of opening the Pittsburgh Airport. He demonstrated excellent project management to open a well-designed airport on schedule:

• He negotiated a 5-year contract with the Unions to prevent strikes — stay on schedule;
• He determined that people like escalators that go up only one floor at a time so that is what was built — attention to thecustomer experience;
• He implemented an automatic baggage handling system with manual back-up — fault tolerance.

This airport has been ranked one of the best for over 15 years.

Her main point was that you need a good Systems Engineer to be successful.

The following are questions to ask to help keep you on the right track.

Purpose

• Are technically skilled people deeply in touch with the overall objectives of the system?
• Do technical team members “Go and See” what the real problem is?
• Is there a technical leader who is responsible for achieving the overall system purpose, and who provides technical guidance as necessary?
• Are there built-in learning cycles to discover, verify, and improve suitability for purpose?

Structure

• Does the team have a good overall ideal o what they are producing, it’s organization, and how their work fits into the overall system?
• Are there learning cycles that engage designers’ implementation and feedback from actual use?
• Do junior people have the raining and oversight to assure that they produce well-factored code which incorporates learning from earlier work?
• Is work reviewed by an appropriate reviewer?

Integrity

• Is the integrity of the system built into the design or is it “tested-in” at the end of the development?
• Is the system developed such that minimal time is devoted to any final merge and testing?
• Are failures rare and investigated deeply to discover design patterns that can be used to prevent similar failure modes in the future?
• Is such learning captured, consolidated, and disseminated in and effective, actionable manner?

Life Span

• Is the lifespan and future change to the system a key consideration in its design and development?
• Are the people who will operate, maintain, and support the system deeply involved in its design?
• Does the development team remain involved with the system over the long term?
• Are the rewards structured so that developing a robust system that performs well over time is the most strongly encouraged behavior?

Results

• How well does the system achieve its purpose; how easily and quickly does each stakeholder derive anticipated value from the system?
• Does the system meet its overall economic goals within its valid cost and schedule constraints?
• Does the system perform without failure and is there confidence that it will continue to do so?
• Does they system delight those who operated, use, support, maintain, and derive value from it?