Agile 2009 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 in this post, I am combining my observations with notes from others whose identity, I am ashamed to say, I have lost over the past 12 years since the conference.

This was also the first conference where I felt so much was going on that I had to miss sessions I would like to have attended. Subsequent conferences just increased this.]

Design of Simulations and Games (Elizabeth Hendrickson and Chris Sims)

Some of the main ideas that came from the session as a whole (some offered directly and others arising out of the session itself) were:

1) The debriefing around playing the game(s) is where the main value occurs, not in the game(s) themselves.

2) Using the term ”simulation” rather than “game” might make the experience of using games more acceptable in some organizations.

3) It’s better to layer complexity on a simple game than to try to remove it from a more complex one.

4) Consider the incorporation of obstacles, choices and randomness in games.

5) Interesting results come from players not sharing the same mental model of what the game is about. (Two examples were a sentence-building game and a balloon passing one.)

6) One good goal of a game is to see how participants achieve alignment, perhaps by evolving the game and its rules themselves to reach a goal they determine to be the point of the game.

7) Game debriefing is like a retrospective for which some suggested questions ideas were asking what happened (in game play); what did players do and feel; what surprised people? In this regard Elizabeth and Chris suggested being very observant as game facilitators, noting what people did and how the game changed, then using these observations to ask what the participants thought about the things observed.

8) Ask participants to “map” what the learned/observed in game play to real world situations and how they could take action in their environment to implement what was learned.

Keynote “I Come to Bury Agile, Not to Praise it” (Alistair Cockburn’s Keynote)

Alistair’s presentation began with a recitation of a revised version of Marc Antony’s speech over Caesar’s dead body from Shakespeare’s Julius Caesar. He said he did not feel Agile was really dead, but that it had [begun to] become absorbed in the mainstream of how many groups do software. Like a large, melted iceberg, he said, Agile was now part of the ocean. As such, Agile has begun facing classic software development problems related to large team design efforts. To address this situation, Alistair made three main points related to (1) software development as a cooperative game (a classic theme of his), (2) craftsmanship (a recent “movement” in the Agile community), and (3) lean concepts.

Alistair noted that software development had two goals which could conflict: delivery the software [on time and on budget with acceptable quality] and “setting up for the next game.” The latter meant making sure the work done made it possible to do the next work. This involves effort that will pay off in the future, but not necessarily now. Thus, there will be a cost added to the current work that may show no immediate value and, thus, be hard to justify in the short-term.

A significant problem in software is that “positions don’t repeat” (often), so strategies for the future must be adaptive. Being adaptive, however, means being able to communicate and understand effectively. Alistair described how the best communication is face-to-face and how distance between people who need to communicate has a significant cost that is often not accounted for in project structures. Distance, he said, affects whether people can detect the need to communicate, care enough to do so, and be effective in making it happen.

Alistair listed 7 major crafts: deciding what to build, managing people and projects, modeling, designing an external view, large-scale (architecture) design, fine-scale (programming) design, and validation. At this point, Alistair reviewed another of his classic themes, the shu-ha-ri learning stages where one learns technique, collects more technique and finally invents/blends techniques.

Finally, Alistair talked about work flow and bottlenecks, noting that software’s “inventory” that moved through the development process is “the unvalidated decision.” Lean aims for “continuous flow” and people waiting on decisions create the bottlenecks. [One problem with such waiting is that, to move along the expected schedule, people will often “make up” decisions that either go unknown or are learned of late and require expensive rework.]

Unlike manufacturing, software development requires feedback/learning as design is knowledge acquisition. Alistair spoke about waterfall as a late-learning approach to developing software since, until a coherent system delivery for testing occurs, there is not much information about the actual state of what will be delivered. Agile methods, in contrast, incur cost earlier to learn earlier through continuous integration such that a good idea of the state of the work occurs early enough to make risk-reduction decisions. This allows business to “trim the tail,” that is, make a decision to deliver on time (or early) or delay delivery to get more (or better) functionality.

“Tips & Techniques for Implementing an Agile Program Across Distributed Teams” (Tamara Sulaiman)

Most of this talk was based on ideas from John P. Kotter’s book Leading Change in which he identifies 8 change concepts:

1) Establish a sense of urgency by “going for emotions” and being clear about the passion for change.

2) Create a guiding coalition of people from across the whole organization who are credible and committed to change. They should be willing to model agile behaviors for the rest of the organization, i.e., being cross-functional, running their meetings/work with one another in an agile fashion, being visible in the coaching/training given to other people in the organization, and maintaining a backlog of transition tasks with a Product Owner. [Audience member suggested forming, not a PMO but an AMO: Agile Mentoring Office.]

3) Develop a vision and strategy by showing what success in the new way would be/look like.

4) Communicate the change vision through slogans, graphics, posters, wiki pages, a glossary of new terms and how they relate to older ones. [There could clearly be some argument about this as it is how every “flavor of the month” program gets done in companies. Having point 2) clear would make this “marketing” acceptable and likely effective. Otherwise, it will be ridiculed.]

5) Empower broad-based action to allow change impact to go beyond development teams and IT as well as to provide an environment where it is okay to fail as long as the learning is clear and progress continues.

6) Generate short-term wins [to show progress] and use a wiki where teams can write about their experiences.

7) Consolidate gains and produce more change using lean, process flow, etc.

8) Anchor the change in the culture, producing a high-trust organization.

Overall, though the material was interesting, the talk was not that much about agile-specific issues in distributed teams. It was more a focus on organization-wide change management, which could be applied to any methodology, for example.

Luke Hohmann — “Leveraging Collaborative Tools with Distributed Customer Teams”

While it offered some interesting ideas and pointers to other resources, this talk did not address substantive distributed team issues. Some important concepts mentioned, however, were:

- Collaboration is always about the goals, so being clear about goals matters. [Collaboration is not simply ad hoc “cooperation” among people.]

- Effective goals are expressed in verbs, i.e., action.

- Understand how fast a customer can accept the output of agile teams. [Cannot collaborate well if the work cannot be shared effectively.]

Hohmann pointed the audience to a Harvard Business Review article entitled “In Praise of Hierarchy,” noting that there are many effective uses for hierarchy, authority not being one of them but being the one most often associated with hierarchy. Hierarchy can be very helpful in handling complexity, for example.

“What (Else) Can Agile Learn from Complexity?” (Jurgen Appelo)

Jurgen’s emphasis was on social complexity because of its complex, unordered, and human-centric focus. This led him to some discussion of self-organization which is key in agile development philosophy. Interestingly, he asked whether an agile team, being coached, is really self-organizing, pointing to the Wikipedia definition of self-organization as including the phrase “without being guided or managed by an outside source.”

Jurgen then described various complexity-related principles, including:

Darkness Principle — systems elements are ignorant of overall system behavior since all system complexity cannot be present in each element; thus no single person (e.g., project manager) can monitor and control a whole system since they cannot know everything [and should learn to make use of self-organization and self-management in teams to help manage the complexity].

Law of Requisite Variety — to have a stable system the states of any control mechanism must equal or exceed that of the system under control and one (project) manager is less complex than the project being managed.

Boundaries and Conditions — self-organization requires that it operate within a boundary which defines the “self” being organized, thus agile management is an important part of agile development in setting such boundaries, i.e., teams do not get to make all decisions about everything.

Hierarchy Principle — “complex natural phenomena are organized into hierarchies wherein each level is made up of several integrated systems,” harkening back to Hohmann’s statement about the value of hierarchy and using a Scrum of Scrums as an example of one that can grow naturally rather than being imposed. Jurgen also noted a “patchwork” approach to Scrum relationships without hierarchy (and referenced Mike Cohn’s Mountain Goat Software site for further discussion of this).

Group Size — where it was noted that some research has pointed to ‘8’ as the most likely group size to lead to deadlock.

Specialization — many advantages accrue in complex systems when there is some level of specialization/division of labor.

Power Laws — which are related to that fact that there is a high chance of small issues and a low chance of large ones, suggesting that prediction of velocity into the future “includes an (impossible) estimate of the size of unknown problems.”

Dependence on Context — “the method to manage the project is embedded in the context and one must allow the emergence of such a method through interaction between the actors and the environment,” which led Jurgen to say that “ScrumButs are natural and necessary.”

Fitness Landscapes — is about how we “create the environment,” it is not “separate from us,” or, quoting a Spanish phrase, “My friend, there is no road, You make the road as you walk.” (This all relates to how a released system will affect, and change, the environment into which it is released.)

Incomprehensibility — states that “there is no accurate representation of the system which is simpler than the system itself,” so any model of it will be wrong, though, as George Box has said, “all models are wrong, but some are useful.”

“Group Relations and Social Systems” (Dan Mezick)

This was basically a talk about group relations theory and how it could be applied to agile teams (to some extent). Dan noted that he had a talk Thursday AM covering the ideas (of boundaries, authority, roles and tasks) in more detail and I’ll cover that talk in Thursday’s summary. This talk began by noting work by Wilfred Bion and his book Experiences in Groups (1961) which covers the main theories in this area. In particular, Dan stated that true groups demonstrate “interdependence of tasks and fate” since survival is a key group driver. For example, he noted that wolves, on their own, must survive on meager food sources (i.e., small animals) while those in packs have richer sources (i.e., moose, caribou). A key issue in maintaining this survival and accomplishing tasks is avoidance of distractions since distractions = waste. Unfortunately, group relations can produce a great deal of waste, but agile methods, like Scrum, employ various “ceremonies,” “artifacts,” and “practices” to “short circuit inattention and drift.” This is done by leveraging “inattentional blindness” which research has indicated means people with a clear focus on activities of immediate concern can block out other things which might place a claim on their attention. In a sense, this supports the idea of “we see and hear what we expect.”

Dan then discussed planning which he said is a prediction, but “prediction is a judgment” and “judgment is a belief” and “belief is a filter” and “filters can distort reality.” All belief demands attention, which can produce waste if the attention is not on the reality of what needs to be done at the moment. Impediments in Scrum are one kind of distraction.

Dan continued by noting several resources/references related to group relations such as LeBon’s study (1895) of loss of individual identity in crowds, making them more easily influenced. Crowds exhibit “system-level emotions that are inherently primitive” as well as seeking dependence on leadership. Indeed, a group will usually seek out leadership that “voices” its main desire. Work by McDougal (1920s) focused on smaller groups who were task-oriented (not the unorganized crowds LeBon studied). Work by Kurt Lewin (1940s) on field theory influenced Bion and was the pre-cursor to modern group relations work. For Lewin a field is “the totality of coexisting facts which are conceived of as mutually interdependent” such as Scrum’s goal of co-location, its roles, its artifacts, and its “ceremonies” (e.g., stand-ups, planning meeting, review, retrospective). Dan also noted Tuckman’s (1965) “forming, storming, norming, performing” model of small group development to which Tuckman added “adjourning” (1977). Tuckman’s work frequently mentioned Bion’s.

Dan nexted spoke about attention and comparing Scrum to more waterfall approaches. In Scrum, “you cannot drift very far from stated task[s].” Waterfall approaches are “not an ‘attention harness’ in any sense of that word” since “all sorts of attention is diverted away from stated task[s], lengthening” their duration. In Scrum all distractions are treated equally, “they are waste.”

Dan finished up by discussing group relations “conferences” (which sounded more like intensive week-long workshops). He also pointed us to the Washington-Baltimore Center for the Study of Group Relations which he said has a variety of good resources on group relations.

“Coaching and Producing Agility” (David Hussman)

This was an all morning workshop on the role of the Agile coach and how to improve one’s coaching capability. Most of the time we worked in pairs (though “promiscuously” since we changed for each exercise like canonical pairing suggests). David divided the session into four (not necessarily equal) sections, which, in case you wonder, were using a music production theme as David’s former life was as a record producer and musician:

We were all asked to create/identify a persona for ourselves with a short phrase summarizing our style, a possible graphic to illustrate it, a series of words describing ourselves and a series of words identifying values we hold. Mine ended up being Socratic, Story-Telling, Scorpio with a graphic of my blog logo. My descriptive elements were: (Talkative), Organized, Inquisitive, [Musical], Teacher. My values were: Synthesis, Experimentation, Openness, Learning, Self-Direction.

So, to explain this, my approach to teaching and consulting has been to ask questions and guide people to answers rather than tell in as many cases as it seems reasonable to do so (a “Socratic” approach). I employ a lot of stories as examples since I’ve been around software development of various kinds and industries for over, now, 49 years. And, though my astrological sign is Gemini, with Capricorn rising and moon in Ares, Scorpio is at my mid-heaven — I used to be in a band where one person’s wife was into astrology and she did my chart. So the Gemini represents the inquisitive, experimenting, open, change-ready aspect of my life. Capricorn represents my organizational inclination (which is often what people see over time). People’s mid-heaven sign usually represents their success mode, so Scorpio represents my synthesis approach where I try to take ideas from many places and produce some whole out of it that takes pieces from each. My logo represents this (see my first blog where I describe it).

The other elements of the persona I’ve covered more or less. Talkative has parens around it since I see that as something I need to contain as a coach and Musical is bracketed because I have a band/recording background and it just popped in there but I’m not sure how it fits exactly other than the band metaphor working better for me than team sports ones so common in business similes/metaphors.

Preproduction (Getting Ready to Produce) — This section addressed interviewing, which we practiced with one another by using real world project examples from our own experience. During this part of the session, David recommended a descriptive approach (”This is what I have seen work”) rather than a prescriptive one (“This is what you should do”) in doing our coaching. He also briefly touched on the Satir change model then collected typical agile practices together to show valuable, related groupings:

For Community-Teams: Chartering, Common Workspace, Information Radiators, Iteration 0

For Iterative Delivery: Burnup / Velocity, Acceptance Tests, Test Driven / Refactoring, Continuous Integration

For Products-Planning: Product Backlogs, Personas, User Stories, Release / Iteration Planning

For Tuning -Improving: Stand Up Meetings, Product Reviews, Retrospectives, Continuous Feedback

We completed this part of the session with a coaching plan development exercise to (1) take practices (what do you want to do?), (2) identify the value of each (why?), and (3) give an example of each (how might it work?). The goal was to arrive at a base approach each of us could use for coaching.

Finding Your Groove (Getting Productive) — David started this part of the session recommending a couple books: The Black Swan and This is Your Brain on Music, quoting from the latter:

“Groove is that quality that moves the song forward”

“When a song has a good groove, it invites us into a sonic world that we don’t want to leave.”

Five things help build “groove” in agile coaching: iteration planning, story-telling, stand ups, acceptance tests/reviews, and retrospectives/indicators. We spent time telling one another, again in pairs, stories to illustrate situations from real projects. David emphasized that each story told should be about somebody doing something of value. He also commented on the traditional story-writing format for agile requirements: he doesn’t like it because, I believe, he sees it as constraining ideas about expressing value, being ritualistic if treated dogmatically.

(Regarding story estimation he noted an idea I have heard before, which he said comes from ThoughtWorks, that people use a paper-rock-scissors approach to sizing since, you always have your materials with you.)

Keeping the Band Together (Staying Productive) — The final part of the session was about sustaining what is built through earlier coaching work. David mentioned the traditional “5 whys” used to do root cause analysis, but recommended a “5 whats” approach since, psychologically, “whys” can lead to blaming of individuals. Of course, retrospectives were noted in this part of the session, including doing retrospectives on one’s own coaching using the coaching plan format of practice-value-example. Finally, David mentioned The Beginner’s Mind and the need to maintain curiosity about the work.

“Esther and Diana’s Excellent Retrospective Adventures” (Esther Derby and Diana Larsen)

This was another long workshop, taking the entire afternoon. Most of it was based on Esther and Diana’s book Agile Retrospectives: Making Good Teams Great. The session began with an activity for teams of 5–7 people to build an “objet d’arte” with materials such as sheets of paper, colored pipe cleaners, stickers, etc. (but no tape). Lots of “structures” resulted, but, as you might guess, the exercise was all about having something to use to practice retrospective technique.

Before we started doing so, however, we were provided with a proposed outline for a retrospective, beginning with Setting the Stage which included (1) identifying the focus/goal of the retrospective, (2) congratulating the team on their iteration, (3) checking in by getting everyone to say a word or two that described how their felt/reacted to the iteration, and (4) defining the agenda. The agenda would consist of: gathering data, generating insights, deciding priorities, and coming to a close. For each of the agenda elements, we performed an exercise.

For Gathering Data, each team generated a radar chart covering things like use of resources, customer satisfaction, quality of work life, etc. Each member of the team was asked to rate (0–10 scale along the arms of the chart) their experience with each element of the chart. We were then asked to identify the variances and commonalities among the results, discuss what we heard and saw, and recognize the high and low points for each element.

To Generate Insights, we were asked to identify what we felt were underlying causes for the major results (pro and con) using a four section matrix: what we felt good about, what we did not feel good about, what were ideas & insights, and what “bouquets” we wanted to give anyone. Each of us created stickies with things which could go in any of the portions of the matrix.

From this we moved to Deciding Priorities by listing actions in a table with the columns labeled: Action, Impact, Effort, Energy and Commitment. The last two deserve some clarification since they require people to indicate how dedicated they are to taking the action as a group and as individuals. The process was to list all the actions, then all the impacts for each action, then the effort expected for each action, followed by the energy people felt they had for the action. In case of apparent ties (since not all actions could reasonably be done in a single iteration), the energy column was to be used to break ties. However, people have to be willing to “sign up for” (commit to) doing any action, not just place votes and estimates on them. Of course, if people were not willing to ultimately commit to an action, what did their energy statement really mean? Finally, it was emphasized that we should end up being able to “take a card into the planning” for the next iteration that described the task to be performed (not as a story).

Coming to a Close involved doing a brief retrospective on the retrospective itself, revisiting commitments, and thanking the participants for their involvement.

Following this, there was some open discussion and question time. One question was who should facilitate retrospectives. A number of ideas were suggested: team coach, trained facilitator from outside the project, and rotation of team members. Esther and Diana recommended the latter and said it could help participation in the retrospectives since people would not want to withhold from participating since they would want others to be active when they facilitate. So this would help establish a more constructive retrospective “culture.”

One final idea about retrospectives and team interactions was that the absence of conflict is not harmony, but apathy.

To close, we were directed to a Yahoo group (retrospectives-subscribe@yahoogroups.com, mentioning this class) as it is a moderated group. Also a book by Sam Kaner (and others) called Facilitator’s Guide to Participatory Decision-Making was recommended.

“May the Forces Be with You, Exploring the Forces Driving and Restraining Agile” (Rod Claar and Doug Shimp)

This was another workshop-style session addressing the forces that contribute to and reject adoption of an agile approach. A few comments made during the session, sometimes in response to presentations, were:

“Will any methodology work if it is not possible to find/identify the needs of the customer appropriately?”

“Is every force restraining Agile really about lack of/inability to collaborate” (which depends on communication)?

Regarding distributed teams: “Latitude hurts; longitude kills.”

“Sharks work alone; dolphins, in teams” and can take on sharks that way.

“Everything thrown into a shark tank dies.”

“4 Challenges, 5 Guiding Values” (Brian Marick)

This was a clearly well-planned and practiced presentation as Brian delivered it clearly and succinctly.

His 4 “challenges” were:

Open Workspace — or rather the lack thereof which represents an impediment to remove. The typical agile workspace may be viewed by others as messy, noisy, undisciplined, uncontrolled and, in general, “unprofessional.” Brian told a story of a coach that, when the organization refused to move cube walls, came in over a weekend and personally reorganized the space by disassembling and re-assembling the walls. On Monday, they stated that they’d keep doing this, if the walls were reassembled, until they were fired.

Courage — The prior example Brian gave illustrates when it can take and the challenge presented in doing so. But Brian noted that as the transition to agile improves, less of this sort of courage becomes needed.

Naiveté — or, again, lack of it. Brian note the need to hold on to this “beginner’s mind” trait to fight objections over new ideas by withholding judgment about practices not tried (e.g., pairing, TDD).

Infrastructure Design — There is always some tension between building as robust base for functionality and getting to the functionality. Features may come in a way that ends up with the architecture being inadequate if too little thought goes into initial concern for it.

Regarding Working Software, Brian noted that if one can deliver this, people may be more willing to give you some slack in other ways to work as you wish. The goal is to deliver something better than the last time, i.e., “last week I could not do ‘X’, but this week I can.” In this way the value becomes clear and concrete.

His 5 values were:

Reactive vs Proactive — in this case being “reactive” was more about adaptation than allowing poor work to be done and than scrambling to “fix” it.

“Irritation” (leading to) Ease — something will drive the desire to improve and Brian discussed a “ready-to-hand” approach (which focuses on the goal) compared to a present-to-hand one (which focuses on the tool). He used the example of a hammer which we do not think about as we focusing on the act of hammering compared to a hammer with, for example, a loose head which we have some concern over lest the head fly off while hammering. In this context, Brian also talked about the practice of “shaving yaks” which represents starting out on a task only to find something else it depends on and then something that depends on, trying to find the perfect way when a good way right now will do. (The Yak’s hair enters the picture as a last step driven to though starting out with nothing like that in mind.)

Solidarity — Brian mentioned the well-known Golden Rule of “doing unto others as you would have them do unto you.” The problem, he said, is that other people are not you and that a Platinum Rule seems better where you “do unto others as they would have you do unto them.” At this point, however, he turned back to the story of the open workspace disassembly and noted that it would have been a far stronger example had the whole team joined in and stated they would quit. That would show solidarity.

Decency — Brian stated this quite simply as “treating others uncommonly well,” which ties back to the Platinum Rule.

Joy — Finally, Brian spoke of bringing true joy to work and noted how everyone can speak about the “one great project” they were on. These days, he said, what he hears more often is that they do agile because “at least my project doesn’t suck as much as it used to.” Hardly an encouraging sign for agile methods and their value.

One final idea that I noted was Brian’s statement that “if you are doing agile well, you can afford to be wrong” as the consequences of a decision are easily corrected.

[This ends my formal summary of the Agile 2009 sessions I attended. I may have more to say about my reaction to some of these ideas in other posts in the future, though.]

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.

Distributed Agile Development — Experiments at Microsoft Patterns and Experience (Ade Miller — Senior Development Manager — Microsoft)

The P&P team at Microsoft was located ½ in a team room in Redmond with the rest in 2–3 countries worldwide. They would ship to customers every 2 weeks with projects lasting 3–8 months using Scrum plus XP.

Types of team distribution:

· Not distributed characterized by being in the same room with high bandwidth and symmetric communication.

· Distributed but in denial where people think they are together but act distributed preventing them from trying things they should (since they really are distributed).

· Completely distributed where there is no one in common location causing symmetric barriers to communication; however, many people say this works pretty well with Open Source as model for this.

· Distributed by function with asymmetric communication barriers which builds walls between people and loss of trust, especially due to lose bandwidth.

· Ad-hoc distribution with asymmetric communication barriers such as the worst case where one person is remote.

· Distributed across time zones which adds temporal asymmetry and lowers bandwidth again.

Being remote is an excuse for a dysfunctional team. If you listen to the conversation, it is the same kind of conversation. Just take the word “distributed” out of conversation and it will sound like a dysfunctional team.

The communication challenges include lost meaning (e.g., over a voice only line), lost trust, and establishing true core hours across time zones.

There are also problems with practices that do not exist when people are not distributed such as use of story cards as a placeholder for a conversation, pair programming, daily stand-ups, white boarding (e.g., you end up sending a lot of pictures), coaching (e.g., especially in difficult situations both personal and technical). There is a need to step back from practices and work the underlying principles and recall Conway’s law that “software structure will reflect your (communication) organization” (“if you let it”). The problem is that the customer doesn’t care about this structure.

The goal should be to minimize the difference in experience between being in the room and not in the room. Some ideas mentioned to support this were:

· Have “always on” video between the two locations

· Bring everyone on the team together for an iteration [which we can hopefully do again not too far in the future]

• Have a team room representative to represent the distributed people/locations who works to prevent/solve issues of technical failures (e.g., the build doesn’t work which could lose a whole day) or rotation of work since it could take 1–2 days for a turnaround on something. And this Idea can be applied to single person as well (e.g., a “team buddy” in the room whose job it is to remember the person who is remote).

Follow the sun development is something that Microsoft has not tried yet. This is the idea of shifting code from one development shop to the next. A whole user story gets moved to the next time zone.

We need to get good at this as we are going to get more distribution, not less. [Rather prophetic considering the last two years, but I am sure he just meant expansion of already distributed efforts.]

His blog has slides — http://www.ademiller.com/tech/talks

First, Kill All The Metrics! (Niel Nickolaisen CIO at Headwaters & Chris Matts)

Some examples of metrics with unintended side effects:

· In an attempt to try to automate more tests, and reduce the hours spent on testing, a company measured the time spent on testing. With the result that time spent on testing was reduced, nothing was automated and the amount of bugs released to the customer skyrocketed.

· A brick company had two types of bricks: straight, and corner where the corner bricks took 4 times longer to produce than straight bricks. The company rewarded the number of bricks being produced with the result that a chronic shortage of corner bricks emerged, which in turn caused constant delays in customer shipments, while the turnaround time for straight bricks grew to several months.

· A software company based their release criteria on the number of bugs fixed in the last few weeks before release with the result that the developers kept all the duplicate bugs open until the last few weeks before release.

Any metric can (and will) be game’d when people believe they are going to be judged by the numbers produced.

Meaningful metrics measure process, not people, but a metric might be meaningful in one place, but not in another.

Keynote “I Come Not To Praise Agile But To Bury It” (Alistair Cockburn)

Alistair started by delivering his take on Shakepeare’s Marc Antony soliloquy “I came to bury Caesar, not to praise him” [Which you can see at https://www.infoq.com/presentations/cockburn-bury-not-praise-agile/].

Agile wasn’t new — just a way of anchoring what was known and being done. But it is not just about small co-located teams any more.

As a definition of software development he offered that it was people making ideas concrete in an economic context. A lot team design activities fit into this definition.

There are two conflicting goals: “delivery the software” now and “set up for the next game [i.e., project/release]” (this is where quality, refactor etc)

The speed of a project is determined by the speed ideas are passed between minds. Distance, attitude, etc are important because of this. The unit of inventory is “the unvalidated decision” [e.g., code not yet fully tested].

Software always has feedback which is called re-work. Thus, there are two input queues: rework (bugs) and new features. Programmers are the only people that can get this down to one queue by producing no [long-lasting] bugs.

Focus on continuous flow of small batches. Target nano-incremental development of code. Draw out decision dependency network to see where bottlenecks are.

Design is knowledge acquisition. Pick work to maximize learning as knowledge runs ahead of cost. Waterfall is a late learning strategy.

Alistair recommended the book “Slack” by Tom DeMarco [and I can suggest looking into it as well].

Risk and Risk Management Theory and Practice (Chris Matts)

Never commit early unless you know why. The default behavior for most management is to make decisions now. This should not be the default mode.

Its not about removing all risk; there is a point where the return drops off. Considerations include risks, assumptions, and constraints. Have discussions about these things frequently.

Delivery risk reduces linearly the more you know (not exponentially). This is why BBig Up Front Design does not [always] work. The true way to reduce risk is to deliver.

Uncertainty — to get to “Don’t know what we don’t know” — business analysis should focus on this.

The cost of projects is more about the time a project takes rather than the number of people. Therefore, focus on things like getting things moving faster.

Agile Project Metrics (Dave Nicholette)

“Everything that can be counted does not necessarily count and everything that counts can not necessarily be measured.” — Einstein

One metric can have multiple uses. Beware of unintended consequences.

Forms of metrics:

· Informational — tell us what is going on

· Diagnostic — what can we improve

· Motivational — influence the behavior

· Leading indicator — what is likely to happen

· Lagging indicator — what happened — inform our continuous improvement

Measure outcomes not activity, and measure the bare minimum you need, and nothing more.

If you have not used them, consider their use as they can show:

· time and at any point in time (e.g., work in progress),

· different states of work,

· evenness of process flow, and

· lead and cycle time measures.

How to Develop Your Leadership Power Daily: An Agile Approach to Growth (Chris Avery)

Chris said that “responsibility” is the way you respond to a problem. He listed six phases in the Responsibility Model:

1. Denial — ‘Problem? What problem? There’s no problem.’
2. Blame — ‘I don’t have a problem working with you. You seem to have a problem with me. That makes it your problem. ‘
3. Justify — ‘I guess it’s possible that I’ve become insensitive to other people’s feelings and needs. I can’t help it though. After all, I’ve been doing this job for a long time. It’s who I am.’
4. Shame — ‘What have I done? I’m going to look such an idiot in front of the people at work. How am I going to live it down? Why should they help me after the way I’ve behaved?’
5. Obligation — ‘Tell me what you think I should do. I have no choice but to do it (even though I don’t want to). I’ll do whatever you say. It’s only a job after all (no one can expect to do a job they love).’
6. Responsibility — ‘I can wait for them to change but that could take forever. No, it’s up to me. I want to fix the problem. So how am I going to be a better colleague? I know! I’ll listen more. And be more considerate towards others. It’s a start.’

Facilitation Patterns and Antipatterns (Steve List)

List stated that anyone can choose to adopt a facilitation role of facilitator in a discussion. He said a good facilitator:

• Creates an open environment so others can make decisions during the discussions.
• Recognizes disruptive behavior within a group and does something about it (using The Facilitation Four-Step — see below for more details).
• Has no authority.

The Four-Step is useful dealing with negative behavior by taking these actions:

1. Interrupt — Stop the speaker in mid-flow in as polite and as respectful a way as possible.
2. Ask — Ask the speaker to sum up or clarify their point.
3. Redirect — Ask others to share their points-of-view.
4. Commit — Return to the original speaker and double-check with them that they are happy to move in the direction of the rest of the group.

List described a “meeting game” made up of 13 personas:

• The Benevolent Dictator: ‘I know what’s best for all of you.’
• The Guide: ‘I’m here to hold the lamp and show the way.’
• The Gladiator: ‘It’s all about the combat!’
• Curious George: ‘I’m here to ask not tell.’
• Professor Moriarty: ‘The end, if it’s what I want, justifies the means.’
• The Conclusion Jumper: ‘I don’t need to hear everything you have to say — I’ve got it!’
• The Orator: ‘I’m worth listening to.’
• The Superhero: ‘I’m here to rescue you.’
• Sherlock Holmes: ‘With enough information, we can reach a conclusion.’
• The Repetitor: ‘It’s worth repeating. It’s worth repeating. It’s worth repeating.’
• Switzerland: ‘It’s not up to me.’
• Be Yourself: [Insert your own motto here]
• The Facilitator: Persona who facilitates a practice meeting.

In playing a first round, each player drawis a card and plays that persona during a meeting on a given topic. The group tries to guess who is playing which persona. A second round involves everyone drawing two cards and playing both personas. This gives each player an additional dimension making determining the characters much more difficult.

Workflow is Orthogonal to Schedule (Mary Poppendieck , notes by Jake Scruggs)

In September of 1929 construction of the Empire State Building began by clearing out previous buildings. On May 1st of 1931 the building was finished and open to the public. It was on time and 18% under budget. They accomplished this by focusing on flow.

Mary listed these key success factors:

• The owner, architect, and builder worked as a team
• The building team was highly experienced.
• There was significant focus on the key constraint of Material Flow. Some 500 trucks arrived each day, but with limited onsite storage for materials everything to go into constructing the building immediately.
• Systems (e.g., windows, floors interiors) were designed to be independent (decoupling the work).
• The design was put in place to meet the constraints of the schedule, not the reverse (i.e., the design did not drive the schedule).

Mary presented this as an of Lean development suggesting a software project could achieve reliable delivery:

• Understand what we really need [i.e., the high-priority items].
• Involve experienced people early in the process [especially QA].
• Build trust (self-focused contract thinking increases costs 30–50%).
• Reduce complexity through design decoupling
• Understand and manage the largest constraint(s) [i.e., Goldratt’s Theory of Constraints with Pareto analysis].
• Big features but small stories [taking1–3 days at most to complete].

Some additional thoughts shared were:

Ask for feedback so you’ll get it. Only commit to 50–70% of what you want since feedback occupies the rest of the time.

Small batch size slows 80–90% utilization. Above this range you get thrashing and waste.

Optimize throughput, not utilization [and look into DeMarco’s book “Slack” which is all about the tendency to keep people “busy” focusing of efficiency over effectiveness].