One of the "Something Old" Variety

Back in 2007, I started a blog called just “Software Qualities.” Not long after, I needed to change jobs and ended up in a rather restrictive IP situation which caused me to stop blogging after hardly any posts – 2 to be specific. So while I collect myself after Agile 2009 and having caught up on 4 days of meeting notes, I thought I’d repost at least one of the original posts. I've posted it as it was to avoid being revisionist since I don’t think that differently today. So here it is, over 2 years later.

--------------------------------------------------------------------------------

There are a lot of places where people can, and do, write about quality and about software quality in particular. What I hope to do with "Software Qualities" is write about (and have people write back about) ideas on what quality (mostly related to software, but not exclusively) means from a product, process, personal, professional, whatever perspective.

Why yet another place to go on about quality? Because I think it's very important and not just some theoretical subject (though there's plenty of theory out there).

What (finally) prompted me to start this blog was a fortune cookie message that said "Give to the world the best you have and the best will come back to you." Though it sounds a bit 60's "instant karma"-ish, I think this is quite a practical idea, though not always easy to do on a day-to-day basis.

I wrote a letter to the ASQ's Quality Progress editor a few years ago (and may someday expand into an actual article) which suggested that, in all the years of training, consulting, and speaking, I have never run into anyone who believes they consciously head to work intending to do a bad job. However, I've run into very few people who claim they go to work intending (or at least really knowing how or expecting) to do an excellent job. I also suggested that I thought most people end up do "the best they can" to "get by" that day as various pressures begin to weigh on them.

Then, recently, I was at a local ASQ section talk about management and leadership, which was actually quite good. In the course of the talk, the speaker stated that -- influenced by the style of management and/or leadership -- people will largely do just enough on their job to "stay out of trouble" and that more than 50 percent of people are "disengaged" on their jobs. The speaker stated this was based on formal research and it seemed to match my experiences with people's answers during my training, consulting, and speaking.

Again, nobody intends to do a "bad" job, but whether they really feel they can do their "best," whatever that means to them, let alone do an "excellent" job, whatever that means to them, seems to be a real question.

On the other hand, Deming suggested people "doing their best" was insufficient to achieve quality as he meant it.[1] I've worked several places where that was, indeed, the performance value and suggesting that it was insufficient would produce a reaction somewhat like, "Well, if we cannot rely on people doing their best to get the quality we want, what in the world can we rely on?" I would claim that this approach suggested that, if we were failing to get the quality we wanted, it was because, somewhere out there in the organization, there were people not "doing their best" and this pushed pursuit of quality into a "moral" rather than "engineering" direction. Maybe this is why people just work to "get by" because failure says something very disturbing to them personally give the moral approach to quality that, I believe, it does not have to.

Just some initial thoughts to get this rolling, then.

Do you agree with any of this? Do you experience this yourself or do you see it in others? What do you think "doing your best" has to do with achieving "quality"?

[1] Deming's original statement was “It is not enough to just do your best or work hard. You must know what to work on.”

Agile 2009 Notes - Thursday

The following material describes the sessions I attended.

Thursday AM –

Dan Mezick – “Boundary, Authority, Role and Tasks”

As I note in my Tuesday summary, Dan had said this session would be an expansion of some of the ideas from the more general Group Relations talk on Tuesday. Specifically, he spoke about four key elements in team/group performance and how “negotiation” about them (due to lack of clarity) creates/is waste. Vagueness about them causes anxiety and competition as two examples of wasteful energy. I found this session more strongly rooted in ideas I feel could be used and Dan made a point of discussing the clarity or vagueness around Scrum ideas as examples.

One by one, the four elements were addressed:

Boundary – defined as the “container for work” and was a topic Jurgen Appelo also mentioned in his Tuesday talk on complexity. Boundaries can be defined in terms of time (e.g., deadlines), physical space, territory, roles, resources, responsibilities, tasks, and resource access. Dan stated that the latter, resource access, can have a great deal to do with project success or failure. Waste can occur when boundaries remain fuzzy, though certainly flexibility in boundaries can be helpful. That is, rather than a hard line for a boundary there may be an area of broader boundary definition that can be tolerated and used effectively. But, ultimately there will have to be a point which is “outside” the boundary in order to use the boundary to define the work parameters. There is also what Dan called a “boundary culture” defined by how rigid or flexible the boundary is.

Authority – defined as “the right to do work” which can be formal (i.e., delegated) or personal (i.e., how one steps into and take more formal authority). Lack of clarity about authority can result in postponement of decisions (and Alistair noted in his keynote that this causes waste as people wait to see who will decide or what will be decided). This lack of clarity was described as “what you think they think” and “what they think you think.”

Role – definition depends on boundary, authority and task definitions. However, as with authority, there are formal roles (e.g., job descriptions) and informal ones taken on to fill gaps that formal ones do not indentify. What roles a person chooses to take depends a great deal, as one might imagine, on their personality and/or self-image.

Task – is defined, as Dan sad, by being unique to the current state of work, influenced as it is by time and personal difference. This is because, no matter how similar in name or general concept a task may be, it likely has never been done before exactly as it needs to be this time.

After this discussion, Dan went over Scrum’s roles, artifacts and ceremonies and we discussed how clearly or vaguely they are defined. For example, there are 3 defined Scrum roles: Scrum Master, Product Owner, and Team. The first two have specifically defined responsibilities, though exactly how they carry them out (and what else they may do) is not defined. The Team is a collection of many people with specialties and knowledge (and probably job titles), but Scrum does not define any of these. Thus, the Team must come to some understanding of how more specific definition will be accomplished and done in terms of boundaries, authority and tasks. The same is true for Scrum artifacts and ceremonies: there are some specific ones identified, but a large part of what they contain and how they are done is not specifically defined in Scrum.

Dan used a good word throughout this discussion of Scrum in describing what the official Scrum literature says. He called the information “canonical” and avoided the word “pure.” I liked this since the former carries with it the sense of being authoritative or accepted from a particular source which can be defined. The term “pure,” on the other hand, implies being free from impurity and somewhat restrictive, even carrying some moral tone. (And when one speaks of a person being a “agile purist,” there is a decidedly negative sense in which that is used, implying impracticality and unnecessary rigidness.)

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

This was another workshop-style session addressing the forces that contribute to adoption and rejection of an agile approach. The room was divided into two teams: one to address the driving forces (in favor of adoption) and one to address the restraining forces (holding back adoption). There were also a pair of “judges” (not Rod or Doug) as we would be preparing presentations which they would rate on impact of the selected force and style of presentation.

I ended up on the team addressing the drivers for adoption. Each team spent some time coming up with a set of forces. Ours had 7-8, but we eventually had to choose the 3 top ones in our estimation and present each one, in turn, alternating with the restraining forces team. Forms if presentation included a limerick and then various forms of skits illustrating the forces. There were a number of clever ideas fort representing the forces visually, almost allegorically in some ways.

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.”

Thursday PM -

Christian Gruber & Lisa Moore – “Coach Aikido: Lessons and support for abused coaches in hostile environments”

This session was another workshop format with 6-7 people in a group and consisted of group discussions around so scenarios we were given. While we were discussing, Christian and Lisa circulate among the groups, made notes on what they heard, and offered some suggestions on occasion. Then there was a bit of debriefing by each group around the scenarios which, at the start, were the same one, but then each team selected another from the remaining set.

Before we began however, Christian and Lisa described and demonstrated, in slow-motion, basic aikido concepts which are based on “control of the opponent’s violence for the sake of their spirit.” So it is an approach which does not involve combat, but rather a way to diffuse/redirect force by “blending” with your opponent. From a coaching perspective, the goal was to come up with ideas for how to use this non-confrontational approach to overcome negativity and resistance in agile settings.

Aikido’s “approach” is to understand your attacker and try to “guide them into a new posture or situation…dissipating their violence (for their sake)…while also exiting cleanly and safely” yourself. This requires taking “the correct stance.” We were also asked to consider four “mental postures” a person may take: beginner, deeply rooted, leadable and no-mind.

The first scenario describe a single, senior member of a team who criticizes all aspects of the agile approach and proceeds to do as he wishes irrespective of the team. The Scrum Master is not his manager and he is “protected politically” by his actual manager. His knowledge is also needed by the team. We started out discussion in the abstract, but a couple people had such issue (or had them in the past) and we ended up focusing on the real-life situation, which had more details that could be brought to bear on how to handle such a situation. There was some discussion in our team about flattery, when various ways to reach out to the person and bring them into the group were discussed. One or two people felt the attention they would get might be seen as catering to their, possible, attention-getting behavior by others on the team. In one of our real-world situations, it was noted that others were wondering why they could not be allowed to behave as independently as this person. Some of the recommended ideas, in the workshop notes, involved eliciting information from the person about what they see as the usefulness of their work methods. It as also noted that a coach would need to look broader than just this person to see if there is some encouragement coming from elsewhere in the organization suggesting doubts about an agile approach.

The next scenario our team selected involved a team where several members felt negatively about pair programming and how it “invaded their space” and wasted individually productive time. These people did pair, but didn’t engage well and made those they paired with “miserable.” One idea offered within our team had to do with trying to provide information/evidence of how this approach had benefited others (hopefully in that organization but from other companies if need be). Another idea was simply not to push on this issue, offering other forms of pairing and cooperative work or, if all else failed, not requiring the people to pair. This approach was suggested as it was felt there were larger, more critical practices to worry about in all likelihood. Our real world examples suggested the latter was true and needed more attention than pairing.

Jesse Fewell – “Growing PMI Using Agile”

Jesse has been at the forefront of building an agile community within the Project Management Institute (PMI). This talk described how this was accomplished, using an agile approach to the community’s work with the PMI headquarters staff. His slides have notes which cover his talk, so I won’t try to summarize all of that. Indeed, as an example, it was interesting to listen to, but the real payoff is what lies ahead as this community can now begin to approach local PMI chapters and bring agile speakers/instructors to them. The one phrase Jesse used that has stuck with me is “contagious culture of commitment.” This describes the dedication and effort he and others have put forth to make this all happen and how that attracted support from PMI headquarters through example.

Jesse also spoke on Wednesday evening at the ThoughtWorks office not far from the Conference hotel where many people showed up to hear the formal announcement of the PMI-Agile effort being launched. There were other talks/discussions at this event and I actually spent a good bit of time in a room with 10-15 people and video hookups to ThoughtWorks office in India and China. We discussed various aspects of widely distributed teams, the challenges this presents, and ways people have worked to address those challenges.

Brian Marick – “4 Challenges, 5 Guiding Values”

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.]

Agile 2009 Notes - Wednesday

The following material describes the sessions I attended.

Wednesday AM –

Daryl Kulak (of Pillar Technology) – “5 Symptoms of Mechanical Agile and Being Change Ready”

Got up early to hear this talk since it was a vendor presentation scheduled for 7:30am in the breakfast area of the Hyatt and I was staying about 8 blocks away and it was raining and ….
In any event, Daryl identified “mechanistic” signs and, later, ideas to make an organization more change ready (that I have associated with the mechanistic practices though they were discussed separately):

Agile Expert Syndrome – people continue to do things because the expert brought in to help at one time did so. (Later on in the talk Daryl said “If you see a Best Practice by the side of the roads, kill it” and referred to Mary Poppendick’s “good practices in context” quote.

Separation of Decision-Making from Work – Daryl used an example of decisions made by a process group (SEPG) separated from the teams which resulted, not surprisingly, in much overhead and resulting in “seepage” as the pronunciation for the process group acronym. Daryl’s advice, of course, was to close the gap between decision-making and work.

Blame the [other people, team] Person, not the System – here, the advice was to remove boundaries and encourage connectedness between teams.

Just Tell Me What to do, Boss – the material on this topic basically recommended learning to value unstructuredness.

Competition Between People and/or Teams – didn’t fine a direct “answer” to this as the last change-related point was to “avoid over-engineering your requirements, people and processes.”

David Hussman – “Coaching and Producing Agility”

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:

Coaching Personas (Your Coaching Style) – In this section, 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 37 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. Davbid 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.

Wednesday PM –

Esther Derby and Diana Larsen – “Esther and Diana's Excellent Retrospective Adventures”

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, of which there were ~7 in the session. We were all charged with building an “objet d’arte” with materials such as sheets of paper, colored pipe cleaners, stickers, etc. (but no tape). The “specs” for the project were that the result needed height, stability, and beauty. We were allowed to ask Esther to come over and ask her questions, as our “customer.” When we asked about height, she pulled out a sewing measurement tape to about 24”. When we asked about beauty, she mentioned she liked “motion.” Stability we took for granted as understanding (and perhaps lucked out there). 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.

Agile 2009 Notes - Tuesday

[Sorry I am behind on these, but I'll be catching up today and tomorrow.]

The following material describes the sessions I attended.

Tuesday AM –

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

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.

Game – Alistair showed his matrix of competitive and cooperative game types along the scale of finite, open-ended and infinite time periods. Software development is a cooperative game which is finite (in length) and goal-directed. Alistair note 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 as a game is that “positions don’t repeat” (often), so strategies for playing the game must be adaptive. Being adaptive, however, means being able to communicate and understand effectively. Alistair described another of his classic themes: 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.

Craft – 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.

Lean – 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.

In closing, Alistair said that 21st century development will use the game, craft and lean ideas he noted.

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

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”

Again, while 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.

Tuesday PM –

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

Jurgen has one of the most popular blogs in Europe (related to software development and management) and his talk was an interesting exploration of ideas related to complexity. Basically, Jurgen took a series of quotations about complexity and related them to various ideas in agile methods. He began, as might be expected, with some quotes from Ken Schwaber, Jeff Sutherland, and Jim Highsmith discussing very direct links with agile methods. He then displayed a detailed graphic of the history of complexity science from people like Norbert Weiner through work being done to explore web/e-science ideas.

During the talk, he referenced numerous books and articles, including one in particular on social complexity and management. Jurgen is, himself, working on a book related to management in an agile context as he is CIO of a software development company in the Netherlands. Though the article describes 4 types of complexity, 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.”

Stephen Palmer – “Working with Large Backlogs”

Palmer discussed a variety of methods for backlog “triage” and management, including epics, themes, hierarchies, pruning, demand management, and extended kanban. He directed the audience to http://www.limitedwipsociety.org/, in particular, with regard to the last approach and mentioned some ideas from David Anderson on time-to-market psychology, e.g., on a 6 week project with 2 week deliveries, there is not much schedule concern, but on a 3 month project with 1 month deliveries, schedule will matter.

Dan Mezick – “Group Relations and Social Systems”

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.

Agile 2009 Notes - Monday

The following material describes the sessions I attended.

Monday AM –

Research Stage

Research reports started Monday at 9AM before other sessions, but were located out of the way of all other session areas. Also, some people at information areas claimed sessions didn’t start until 11AM.

I spent the morning at two research presentations because the format this year drew in a great deal of audience participation as opposed to just a series of 45-60 minute talks. Dr. Jael Dublinksy explained that a goal of the Research Stage this year was to solicit a lot of input from industry folks. I believe it worked for those industry people present, but, again, being a out of the way(and mind) of people did diminish attendance.

The first presentation was by Rosalva E. Gallardo-Valencia on “How Agile Teams validate Requirements.” Team activity was observed and artifacts were collected for ~2 days, including stand-ups and Sprint Planning sessions. Overall, the study showed that, while standard validation approaches were not used (or even possible) in an agile environment, there as substantial validation performed at various points during team and team/PO interaction.
Interestingly, it was noted that the PO and written up a “checklist” of details about story information which was not shared with the teams. Instead, at the Planning Meeting, the PO would talk about this information and respond to team questions while the ScrumMaster worked to write the stories to match the discussion. I asked why, if all this material had already been written (even in brief form), did people feel index cards had to be created. There were a variety of audience opinions, but there really was no answer from the study why this occurred.
It was noted that the teams wrote jUnit tests before coding and that Fitnesse was used for acceptance testing.

After the presentation, there was a period of feedback to the presenter on work of the study. But then, the audience was asked to form into groups and consider research topics that they might like to see pursued. Our group had the following ideas submitted by various members of the group:

1) Classification of team sizes and recommendations for what team sizes/characteristics might be appropriate for different development situations. Dimensions to be examined were: trust, distribution of team, new vs “rewrite” type work, and degree of team integration, including senior management.

2) What concrete benefits does agile provide an organization, e.g., lower costs, higher customer satisfaction, improved time-to-market, market success (revenue).

3) Quantify an organizations degree of “agileness”

4) Effective approaches for introducing agile – path to adoption.

The next presentation was by Dr. Stuart Mitchell based on the work of Rashina Hoda regarding “Agile Undercover” where some organizations wanted to use agile but customers “couldn’t have cared less about what methods were used.”

Dr. Mitchell noted that a grounded theory approach (Glaser rather than Strauss style) was being used for data collection. Observation, without making conclusive statements was a characteristic of how this study was done.

Some outsourcing teams in India were studied. They wanted to use an agile approach, but most of their customers did not care to adapt to such an approach. Ms. Hoda interviewed a person from each of ~8 teams. It seemed that many ended up with customer proxies to allow their teams to try to function in as agile a manner as they wanted. Some teams did do periodic demos to actual customers, but some did not.

I suggested that the most interesting research work related to this might be to observe how the proxy role made it easier for the team as to behave as they wanted while the customer did not have to be aware of how the team was getting work done.

Monday PM –

Elizabeth Hendrickson and Chris Sims on Design of Simulations and Games

This was an all afternoon session that asked attendees, in teams, to design “games” of various kinds that could be used to allow help groups learn (presumably about agile methods, values, etc.). There were board games designed; some involving pure interaction among participants; one involving joint creation of sentences; etc. Each, however, was developed around a different goal. One being “Truth and honesty in planning.” Once teams had been given some time to design a game, members of other teams would come by to “playtest” and provide feedback. Teams could revise their games and get further feedback.

Many fascinating observations occurred about what the games “taught” as well as what contribution to that learning the participants brought compared to the games as originally envisioned. 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.

All in all, it was a very interesting day.

What’s your agile methods “elevator speech”?

Sorry I missed a post for yesterday, but I had a bit to do to complete getting ready to leave later today for Agile 2009.

Today’s post will be short, but deliberately so as it is about asking you to submit your favorite agile “elevator speech.”

In case you haven’t heard the term before, an “elevator speech” is a brief explanation of something to get the listener interested in hearing more or reasonably informed about the subject in a short time. The “elevator” part comes from someone asking some thing like, “What if you were on an elevator with your boss and they asked you ‘I’ve been hearing a lot about . What’s it about?’ What would you say in 60 seconds, so your boss would walk away with a reasonable idea?”

So what if you were in the elevator and your boss said, “I’ve been hearing a lot about agile methods. What are they all about?” What would you say to explain agile methods in 60 seconds?

Here’s one sample (but by no means great) idea:

"Agile methods are an approach to development and delivery of software in smaller, shorter increments. They do this by using techniques that improve communication bandwidth & frequency using direct contact among customers, developers & the product to get continuous feedback. They also employ development approaches that try to be open to and prepared for change by facilitating change rather than trying to prevent it and developing incrementally so change is easier to manage."

What would you say in about that many words?

Quotes (from Twitter)

The the past 2-3 months that I've been on Twitter, I've been saving Tweets that, at the time, struck in particular when they appeared. As the list was getting long, I thought I'd better post these now, before it got ridiculously long. Some are quotes, not from Twitter users, but quotes other Twitter users thought were interesting from authors, philosophers, etc. There's even a few here of my own. :-) [In some cases there are follow-ups combined with the original which are not, therefore, in alphabetical order by the author's name.]

Abraham Maslow (via ASQ) - "Secrecy, censorship, dishonesty, & blocking of communication threatens all the basic needs."

Alan Shalloway - Doing meta thinking is good (see my book design patterns explained). "going meta" means doing meta thinking w/o validation ;)

Alan Shalloway - practices followed as solutions are dangerous. Practices followed as examples of understood principles are a basis of learning.

Albert Einstein - Not everything that can be counted counts and not everything that counts can be counted.

Alistair Cockburn - The center of agile development is to deliver running, tested features to users and collect feedback.

Alistair Cockburn - We need shared understanding at this point, not shared common sense.

Alistair Cockburn: OH "a large dev team has a voracious appetite for requirements". Food for thought.

Andrew Clay Shafer - In a mechanical system, friction is the most common cause of lost work. Friction seems like a useful metaphor.

Ari Tikka - Standardized work... in Finnish I like word "vakioitu". Has the flavor of being constant instead of forced to standard.

August Turak - Maximum motivation emerges from the peer pressure of a team working toward a common mission.

Bas Vodde - I'm a positive person, but gradually losing hope that large companies can get rid of their self-destroying habits. Esther Derby - plus structures and policies reinforce current behavior, sometimes punish new behavior. Bas Vodde - Yes, and people reinforce each others behavior all the time. A nice system build to keep it in status quo.

Ben Simo - If you learn from /waste/ and /rework/, is it really waste?

Ben Simo - SW doesn't handle ambiguity like people but SW systems definitely can be complex. Plus, human users r part of those systems.

Benjamin Mitchell - A new team has set up a Kanban board with an explicit column for 'blocked'. Amazing how quickly kanban boards provide useful information.

Bill Graham - “It’s only work if there’s something else you’d rather be doing.”

Bob Marshall - Locating Sw Dev in IT seems dumb to me (these days). But the wider point: who owns Product Dev?

Bob Marshall - The one and only question you need to ask agile teams: "What measures are you using to understand and improve performance?

Bob Martin - Scrum+XP+Lean+Kanban+CSM+DSDM+TDD+BDD+CSP+... = murky Agilebet soup. Maybe it's time to rethink this.

Brian Marick - like to think of AR⊗TA as part of new wave: "economy of trust", "smaller co's w/ intense collaboration", products instead of finance, etc.

Brian Marick - Courage isn't needed for those things once you've constructed an environment where making mistakes isn't scary. So I'd put courage as a temporary value, a stepping stone.

Brian Marick - I detect a certain tendency for craftsmanship to become narcissistic, about the individual's heroic journey toward mastery.

Brian Marick - I think of arxta as a back to basics movement, where basics are pretty much XP attitude & the original scrappiness of Scrum.

Brian Marick - Interesting to think about changes required by "Done means it's in the user's hands. Nothing less."

Brian Marick - Much social thought today is about making sure no one gets something for nothing (welfare queens!) and bad ppl suffer (smokers: perish). (Esther Derby - Those seem almost like tribal values.) What gets lost is persuading/allowing ppl to give something for nothing (open source, social capital) so that ordinary people benefit. Being jealous of resources is human reproduction model (small # of children, huge investment in each). Alternative is our maple: huge # of seeds, waste cheerfully accepted. Maple doesn't care that some seeds wasted on undeserving ground.

Brian Marick - People who think they're on a hero's journey tend to disregard the ordinary schmucks around them.

Brian Marick - The idea that working with other people is risky, that it requires lowering some sort of barrier or thinking differently (becoming humble).

Brian Marick - Thing about waterfall for programmers: you only have to acknowledge your gross lack of skill every few months. With Agile, it's *every day*. Ron Jeffries - true but i can't do much harm in a single day.

C. Northcote Parkinson - “Delay is the deadliest form of denial.” (Not from Twitter)

Charles Kingsley - We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.

Chris Sims - People think agile introduces uncertainty when it is actually just uncovering the uncertainty that has always been there.

Classic #quote - A user is somebody who tells you what they want the day you give them what they asked for.

Courtney Benson - "People don’t fail because they make mistakes. People fail because they don’t learn from their mistakes.” Chuck Musciano

Dan North - talk on learning at Better Software conf: "Use metrics as indicators, not targets."

Dave Pembs - Do not argue with an idiot. He will drag you down to his level and beat you with experience.

David Alfaro - "Individuals and interactions over processes and tools" So true! Docs=Potential Knowledge [hardly unleashed], People=Kinetic Knowledge.

David Alfaro - You will be amazed how powerful is to switch the immediate reaction "I disagree" to "I don't see it, help me see it"

David Anderson - TPS yes! Lean (Womack, Jones, Daniels) No! A theory of variation is missing from core Lean literature. So not Deming.

David Hussman - "what do you call a stand-up meeting with too many people? A stand-there meeting"

David Platt (via Michael Bolton) - “Your user is not you. Most people don't want to DRIVE somewhere, they want to BE somewhere."

Derrick Bailey - if you don't learn fr waste/rework, it's not only waste/rework, its complete failure. i expect learning fr waste/rework.

Doug Shimp - A well formed team often can solve problems faster than the surrounding business is able to apply.

Doug Shimp - Build your team protocols one at a time. Pay attention and adapt based on realities encounter and don't assume what is needed.

Doug Shimp - Great individual talent is often not enough. We need teams that are talented & humble enough 2 work together.

Doug Shimp - If you think it's expensive to hire a professional to do the job, wait until you hire an amateur.

Doug Shimp - Scrum often reveals that the business is not able to figure out which problems to solve.

Ed Yourdon - David Stephenson makes key point (at #e2conf1): "make customers co-creators"

Elizabeth Hendrickson - Seems to me that prof testers do 4 things well: observe, notice what can be varied, predict risks, & explore methodically.

Elizabeth Hendrickson -Trying to test the depths of the code thru the UI is like peering through the shower head to examine pipes in the basement.

Esther Derby - primary work of managers: establish conditions for teams to work in. develop people. work on the work system.

G.M. Weinberg - CENTER means know your own agenda and motivations. Get control of yourself first, so you can genuinely be of service to someone else. ENTER means you must enter someone else's system to help them. You can't bash your way in, and you can't force them to see things as you do. TURN means that we think in terms of making a nudge here and there. We can't expect to transform someone. They self-transform, if at all.

G.M. Weinberg - Instead of thinking, 'irrational', think 'rational from the perspective of a different set of values.

George Dinwiddie - "Talk to the card" We found that focus on the card wall helped bring focus to the standup.

George Dinwiddie - Yes, it's a pity. With mechanical products, the customer can admire the design and workmanship. Estimate long term value.

Gia Lyons - Marketing = Matchmaker. Sales = Dating. Services = Marriage. Support = Marriage Counseling.

Greg Vaughn - Agile offers more control. But you have to give up the illusion of predictability.

Henrik Kniberg - In Scrum, the Scrum Master's role is to create a great Team, and the Product Owner's role is to use that team to create a great Product.

Herm Albright - A positive attitude may not solve all your problems but it will annoy enough people to make it worth the effort.

Igor Macaubus - "Rules and procedures can be an insurance policy against disaster, and they prevent disaster. But they also assure mediocrity."

Immanuel Kant - Immaturity is the inability to use one's own understanding without the guidance of another.

J.B.Rainsberger - I find that the more authority I have over my own habits, the more I care about outcomes over dogma.

J.B.Rainsberger - Perhaps if more craftspeople worked more closely together, the narcissism would subside.

James Bach - Testing under no circumstances shows that the product will work. So we test mainly to discover how it will not work.

James Bach - When you see someone "resist change", realize from their point of view they are just applying self-discipline to do things right.

Jason Yip - If you had to scale down Agile to a few core skills that can be learned and applied without a huge commitment. What would that look like?

Jason Yip - The problem is not concentration of power; the problem is thinking based on authority rather than responsibility.

Jeff Patton - popular quote at yesterday's agile round table [Colorado somewhere] on good management: "organize their goals, not their work." - can't remember where I got it.

Jens Ohlig - pizza with the radius z and thickness a has the volume pi*z*z*a [Life is good]

Jim Highsmith - Agile managers understand that demanding certainty in the face of uncertainty is dysfunctional.

Jim Highsmith - Calculating value points. If the product mgr has no time to calculate value, the dev team has no time to calculate cost.

Jim Highsmith - Documentation is often the solution to a communications problem that can't be corrected with documentation.

Jim Highsmith - The best way to get a project done faster is to start sooner.

Joshua Kerievsky - An improvement is something that "enhances value or excellence." Don't ship features. Ship improvements.

Joshua Kerievsky - To release frequently, discover and build "acceptably incomplete" features that can ship today and evolve tomorrow. re: "acceptably incomplete" - one Customer deferred a good number of stories (8-10) that would "flesh out" a feature. In the end, those stories were never implemented - Customer realized that they didn't really need them after all. Dave Rooney - So, "acceptably incomplete" was actually "perfectly acceptable". Joshua Kerievsky - Completeness is overrated. We get more done faster by finding what is acceptable in its incompleteness. The core issue may be that we don't know what "complete" really is all the time (perhaps 'most' of the time). That's why the hardest and perhaps most valuable skill to master is Evolutionary Design.

Keith Braithwaite - No. I'd call src ctrl a good practice so good that it's mandatory until something better comes along—and I hope for something better. Ron Jeffries - so your concern with "best" is that someday something might be better? Keith Braithwaite - My concern is that a stated belief in the current way being best will lessen the likelihood of a better way being recognised.

Kent Beck - by "aspirations" i mean "who we are trying to be": software will improve when we aspire to be accountable, transparent, reliable. Ron Jeffries - well, yes, that and when we act in accord with those aspirations.

Kent Beck - Disagree that xp1e glorified programmers. Talking code when addressing the industry built on code isn't glorifying. The kind of thing i notice is when i say "the team" in 1e i mean "the programmers". In 2e we meant everybody influencing dev. "respect" as a value hasn't been widely accepted. Michael Feathers - The thing that was key in XP1E was the emphatic message "with these constraints, this works.” Up to that point, everyone was trying to solve the "general problem" of software dev. Rachel Davies - for me - XP1E was about listening to customers without compromising code quality - a way to achieve balance.

Kent Beck - i would be very glad to see a dramatic increase in aspirations for outcomes accompanied by a dramatic decrease in dogma.

Kent Beck - not quite a definition but... "quality results in a steady flow of value" or "a steady flow of value indicates the presence of quality".

Kent Beck - shu ha ri is generally a power trip for the teacher. empathy, engagement, and modeling work much better if you can deliver them.

Kevlin Henney - Use of "general" and "flexible" are design meeting smells.

LinusTorvalds - Real men don’t use backups, they post their stuff on a public FTP server & let the rest of the world make copies.

Luke Hohmann - Surveys are about getting answers to questions. #innovationgames are about shared exploration of complex issues to gain insight.

Malte Foegen (via Hillel Glazer) - "Replace 'process' with 'work' everywhere you see it & ppl will not get so hung-up on process."

Mark Graban - Toyota people taught me to shift my mindset from "we can't do that" to "we haven't figured out how to do that YET."

Mark Twain - The best way to cheer yourself up is to try to cheer somebody else up.

Martin Fowler - I'd rather someone thoughtfully does something counter to my advice than someone blindly follows it.

Martin L. Shoemaker - If you want to get things done around here, you have to learn to think outside the boss...

Matt Podwysocki - @KentBeck now what about the anti-for campaign? I could get behind that one too. Composable functions over explicit loops.

Michael Bolton - Serendipity is the discovery of something in the absence of a goal to discover it.

Michael Bolton - Testing is not quality assurance. Testing provides information to those who make decisions about quality assurance (programmers, managers).

Michael Bolton - That which is ubiquitous without being influential is in obsolescence. (from Mark Federman @ #Agile 2008, and maybe from McLuhan).

Michael Bolton - There is no test that is guaranteed to be needed only once. True; as is the converse. A test of some kind will help us tell the difference.

Michael Bolton -To me, "going meta" means "going above the current level of conversation to try to figure out what we're really talking about".

Michael Bolton: We get into BIG problems when we confuse MEASUREMENT which can be qua [l nt] itative with METRICS, which are functions, quantitative.

Michael Feathers - The test of a philosophy is the state the world would be in if it were followed fully. Most philosophies posit impossible worlds. Human nature is the one bit that many philosophies don't account for. Some pay lip service to it, but then conveniently ignore it.

Mike Wesely - "Statistics are often used as a drunken man uses a lamppost; for support rather than illumination."

Napoleon Bonaparte - Ten people who speak make more noise than ten thousand who are silent.

Nicole Radziwill - Alex just invented a new word: "for-gonna-get" - when you haven't forgotten about it yet, but you will forget something in the future.

Ohno - “Do not codify method" [because improvement is never-ending, and by writing it down, your process will ossify].

Paul Seibert - Are you agile? Look for adaptation in the face of things you did not expect?

Paul Seibert - The right people don't need to be managed. if you need to tightly manage someone, you've made a hiring mistake.

Randy Nelson (of Pixar) - Core skill of innovators is error recovery not failure avoidance. [Is agile more about the former compared to traditional approaches that may emphasize the latter?]

Ricardo Semler - "It's unfair to expect all employees to feel passionate about their work."

Rob England - Open content standards those I know of have failed. Open OK, but need money and editors. COBIT 5 might fly.

Ron Jeffries - an estimate is a guess in a clean shirt.

Ron Jeffries - OK. Here's the deal. The fact that you think you need tools to support your distributed development is a sign. Read the damn sign.

Ron Jeffries - There is a big difference between "I don't know a better way" and "there is no better way".

RonJeffries - @jwgrenning well put. TDD style finds mistakes, preventing defects.

Scott Bellware - That decay that plagues community efforts (agile, alt.net, etc) is only inevitable if the community fears principled community organization. With a values statement of code of conduct, a community becomes an *intentional community*. A community with defined values and protocols can afford more diversity than a community that eschews definition for the sake of diversity. A community's core values necessarily creates a core group. as long as that group doesn't devolve into a clique, it strengthens the whole. On top of creating definitions that permit a core, the group needs values and protocols to recognize and address cliquishness of the core.

Scott Duncan - I think we should talk about (what I think is) DeMarco's main point: focusing on the goal of creating software that changes/transforms and the conception vs construction aspect of software. Note also that he does not reject the idea of engineering software, so understanding what that may mean still seems important, though control, predictability & consistency are not most important to him.

Scott Duncan - My reading of the article suggests the pt is to focus on building transformational sw, not expect cmd & ctrl will be the best way to structure doing that, and rethink what the engineering of sw needs to mean in doing so.

Scott Duncan - Perhaps why some at #agileroots felt "real" agile is about code & coding techniques, feeling social "stuff" is a distraction. Alistair noted that people saying this weren't around when the Manifesto was crafted. Kent Beck - how odd. the social stuff is the point. technique supports relationships. Ron Jeffries - Yes, many techies think "social stuff" is distraction. But no: valuable skill. At same time, one puts effort where one's heart is. George Dinwiddie - Many business people also think "social stuff" is distraction.

Scott Duncan - Stability seems relative: depends on how much change one can absorb/comprehend in some period of time. Could it be that acceptance/concern over an agile approach is about one's relative sense of stability?

Scott McKain - “What gets measured is what gets done” is true but also “What gets measured gets emphasized by management.”

Seiche Sanders (ASQ) - I've never been a fan of the shooting-a-mouse-with-a-shotgun problem-solving approach. Propagates more problems/costs.

Shigeo Shingo - What is the Toyota Production System? When asked this question most people (80 percent) will echo the view of the average consumer and say: “It’s a kanban system”; another 15 percent may actually know how it functions in the factory and say: “It’s a production system”; only a very few (5 percent) really understand its purpose and say: “It’s a system for the absolute elimination of waste.” Some people imagine that Toyota has put on a smart new set of clothes, the kanban system, so they go out and purchase the same outfit and try it on. They quickly discover that they are much too fat to wear it! They must eliminate waste and make fundamental improvements in their production systems before techniques like kanban can be of any help. The Toyota production system is 80 percent waste elimination, 15 percent production system, and only 5 percent kanban. This confusion stems from a misunderstanding of the relationship between basic principles of production at Toyota and kanban as a technique to help implement those principles. – Shigeo Shingo, A Study of the Toyota Production System

Thomas Cagley - The world is not rational and expecting people or even groups of people to act rationally is confirmation of the thesis.

Tobias G Mayer - If teams are not collocated, are they dislocated?

Tom Gilb - DeMarco is really saying we must control value not merely cost and time.

Vadim Zaytzev - “Formal rules for comments are difficult enough to be easily forgotten to be included in a language standard” Michael D. Hill - aren't comments for precisely the stuff we can't express formally? if we could, they'd be called "code".

William W. (Woody) Williams - Agile development requires continuous planning. Waterfall requires constant re-planning.

William W. (Woody) Williams - Despite rumors to the contrary, Scrum is not a project management practice, it is a software delivery method.

William W. (Woody) Williams - It is infinitely better to mentor and train people - risking they leave - than to do nothing and risk they stay.