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