Posts Tagged ‘retrospective’

Is Agile a mystery?

Agile & Lean, Musings | Posted by Doc
Sep 02 2009

Over the past few weeks, in between preparing for Agile2009, I was preparing to deliver some Agile training to a company’s product owners and project managers. I was told that they’d been doing various Agile practices for as much as a year.  This made me curious as to why we’d be delivering a course on Agile Fundamentals.

After all, if they’ve been doing stuff for a year, I thought, shouldn’t they have some of the fundamentals firmly in mind?

Nonetheless, skepticism firmly in hand, I prepared myself to deliver to what might be a knowledegable and, perhaps, challenging group.

Much to my surprise – although it shouldn’t surprise me – these folks have piecemeal knowledge of certain practices, and seem to mostly lack a solid grasp of the underlying principles of Agile. While I don’t think that the Agile Manifesto is a bible, I do think that it’s both required reading and deserves some thought. The implications are profound, once you start thinking about them and trying to understand what they mean for an organization.

How can it be that people have been doing standups and iterations and estimating and story cards for 6 – 12 months, and don’t have a firm grasp of the why of what they’re doing?

Maybe it’s just me.  Maybe most people don’t have any need to understand the philosophy or principles or subtleties of what they’re doing, and are happy to just learn the what and the how.

I’m still a bit baffled. The subtleties of what makes Agile be what it is are what excite me. Yes, I do get excited about pairing and standups and iterations and IPMs and retrospectives and all the other stuff we do. And I also get excited by the understanding and the “cultural shift” (as one attendee put it) that goes along with Agile adoption.

After all, Agile is clearly not just about the practices and methodologies. It’s about the discipline and the attitude changes and the mental shifts in things like code ownership and transparency. How can you go from the dark ages of Waterfall, individual code ownership, controlled communication, and defensiveness to Agility without being affected by all of those changes in profound ways? How can you make the shift from maybe-doing-unit-testing-a-little-bit-after-the-fact to TDD/Test-First and not see that there’s more going on than just the practices?

Sigh.

I guess the opportunity to share that excitement that comes with the transformation is part of what drives me to do coaching and training and facilitation.  If I can see just one person get it, then it’s all worth it.

It seems that you can take the man out of motivational speaking, but you can’t take the motivational speaking out of the man. ;)

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Distributed Retrospective

Agile & Lean | Posted by Doc
Jun 07 2009

A couple of days ago, I facilitated my first-ever distributed retrospective.  I was pretty anxious about it, since much of the value I’ve experienced in retrospectives comes from the interactions between people.  Here’s how it went:

I was facilitating from my home in Austin. My colleague was in Chicago. The project manager/scrum master was at work, but off site. Several of the team were in the client’s offices, but not necessarily together. And several were in Bangalore, India.

From my perspective, this created a wonderful variety of challenges.

We used a sharing application that allowed participants to sign in as “guest #”, for those times when we wanted anonymity, and also used a WebEx. The PM shared the anonymous app via WebEx, so we could all see what was being entered.

We began with a Safety Exercise, which was supported by the sharing app which was revealed in the WebEx window. It worked quite well, and I was delighted to see all fives and one four (meaning that everyone felt quite safe).

We followed this with a Mad/Glad/Sad, still using the anonymous window. This was interesting, in that we were using virtual stickies, and had to do reading/clustering verbally. It’s clear that there’s an opportunity for a sharing app that actually presents something like stickies, and can be manipulated in real-time (something like cardmeeting.com, but more oriented toward this purpose).

I thought about using Mingle. Here’s how I think it might work (and I might try this next week):

  • Create a card type of “sticky”
  • Create a card attribute of “feeling” and give it a list of values: mad, glad, sad (or whatever is appropriate)
  • Create a card type of “cluster”, with the intent of connecting Stickies to it in a tree or hierarchy, as with epics, features, stories, and tasks

I’m experimenting with this now, and will share results as I get them, and what I learn in the process. While nothing that’s done electronically will replace face-to-face retrospectives, I’m hopeful that this will reduce the pain.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Circle of Questions strikes again!

Facilitation, Musings | Posted by Doc
Apr 19 2009

I facilitated a retrospective for a client’s product development team (s/w dev, product manager, QA) recently.  They had never done a retrospective before, so I had to choose my activities with some care.  That was challenging, because I had two hours, and wanted them to experience a variety of things during that time.  Here’s what we did:

  • Introduction and Welcome
  • Fun (the game I refer to as Count-Off – does anyone have another more common name for it?)
  • Prime Directive
  • Working Agreements
  • Starfish – I really wanted to do a timeline, but given the time limitations, opted for the Starfish
  • Break
  • Fun (Untangle or Human Knot) – facing inward, then facing outward
  • Take Temperature again
  • Circle of Questions
  • Appreciations
  • Closing

As is often the case with groups that have never done a retrospective before, it started with nervous laughter, silly jokes, a lot of shuffling, and nervous and expectant looks.

As I described the purpose of a retrospective, there were nods and some smiles and lots of interest.  This is a good group that works well together.  There were a couple of loudly self-professed introverts (is that an oxymoron?), and the usual variety of personality and communication types.

The Check-In helps to gauge the emotional atmosphere. I just asked “How are you feeling about being here right now? Give me a thumbs-up for good, thumbs-down for not good, and middle for neutral.” I got mostly up and neutral, with a few down.

Using Norm Kerth’s “Create Safety” exercise (from his book Project Retrospectives) helps to judge how safe the group feels in talking and sharing. Fortunately, the group I was working with was mostly in the 4 – 5 range, with a few 3’s.

When we got to the fun, it was – well – fun. ;) My intent was as it is with most icebreakers – get them up, moving, stirring up some positive energy, sharing with each other, but no pressure other than our own native competitiveness.

While some disagree with it, I like Norm Kerth’s Prime Directive. For me, it sets the tone as non-judging, non-blame-searching, non-fault-finding.

Working Agreements, learned originally from Diana Larsen and Esther Derby in “Diana and Esther’s Excellent Retrospective Adventure” at Agile2008**, is a powerful and enduring tool. Once created, the team maintains them and continues to use them.  They become an embedded part of the culture. The activity of creating Working Agreements (or Ground Rules) is also covered in Diana and Esther’s excellent book “Agile Retrospectives” and in Norm Kerth’s “Project Retrospectives“.

Then we got to the Starfish. I love the looks on the first-timers’ faces. Blank, confused, unsure… and then the first person writes on a sticky and puts it up on the sheet of flipchart paper. And then the next. And then the dam breaks, and there’s a flood.  I love that.

We did clustering and discussing, and then mined it for information. The biggest thing to come out of it was that the team, as a whole, felt that they didn’t have an ongoing grasp of the overall product vision. They’ll be scheduling something to work on that.

After the break and the fun, I decided to check safety again. Not surprisingly, the numbers had shifted upward, with more 5’s and 4’s, and just a couple of 3’s remaining.

Now we get to the Circle of Questions.  Thanks for bearing with me.  The long lead-up was important.

You can imagine it. This group sitting around, with me explaining how Circle of Questions works. Oh, my. Blank looks, some looking distinctly uncomfortable, even just a touch of hostility, perhaps?

I finished explaining, and then chose one fellow to start it off. Wouldn’t you know that I’d picked perhaps the most introverted of the folks there, with the next most introverted sitting to his left! There was a long pause, after which I said “If you’d like, I can start you off.” He declined my offer, and got things started.

As always, it was a bit slow at first. What was wonderful was that the questions quickly became very deep, insightful, and important. They talked about their process. They talked about their organization. They talked about their frustrations and fears.  All done with great respect and mutual concern.

It was glorious.

After the first time around, ending with Mr. Introvert, I suggested that we continue, but going in the opposite direction. The other introvert said “I was going to ask if we could go in a different direction!” while Mr. Introvert said “Oh – I didn’t think of another question.” Long pause, then he got it started again.

Ultimately we got around one more time before I had to call time.

After the close of the retrospective, several of the participants came up to me to talk about the Circle of Questions: how surprised they were, how much they got out of, what they learned from it.

On the surface, Circle of Questions sounds like it’ll be kind of boring. It isn’t.

I’m really glad I actually read through all of the exercises in “Agile Retrospectives” – this one is one of my favorites.


* BTW, a great site for team building and ice breaker games is Wilderdom.

** I’m delighted to say that, as Stage Producer for the “New to Agile” stage at Agile2009, their workshop will be offered again. It’s a winner, and well worth attending if you have the opportunity.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Best and worst retrospective experiences

Agile & Lean, Facilitation, Musings | Posted by Doc
Mar 31 2009

Having been both a retrospective participant and facilitator (mostly facilitator, these days), I’ve experienced some very good and some bad retrospectives.

In some cases, the key factor was the facilitator. In others, it was the specific activities, or the way in which the participants contributed (or not).

For instance, I facilitated an Iteration retrospective once in which we did a Mad/Glad/Sad exercise, and used the results of that activity to drive having the team come up with a SMART goal. One of the problems was that I was the team’s boss, and shouldn’t have been facilitating (in retrospect ;) ). Then there was the problem that the participants were having trouble coming down from 10,000 feet to specific, actionable goals. At the end, a number of the team members felt very frustrated, and the SMART goal they came up with was only partially embraced.

I’ve talked with other folks about what makes for good and bad retrospectives, and I suspect that we each have a set of experiences, biases, and criteria in our heads.

Another example from my own experience: I was facilitating a retrospective for a client’s team. They were having some communication challenges. In particular, their three-person development team was dominated by the tech lead, leading to some resentment and frustration by the other two developers. And then that same tech lead was overbearing and perceived as emotionally abusive by the team’s business analyst. In order to address this, I included the Circle of Questions activity in the retrospective. One of the best things that happened was that the tech lead was sitting next to one of the other developers, who was sitting next to the other developer, and the tech lead asked “How do you think our development team meetings are going?” The developer replied “Well, one of the participants tends to dominate the conversation, leading the others to feel frustrated.” Then, that developer turned to his left and asked the other developer the same question, and got pretty much the same answer. After the retrospective, the communication on the team improved significantly.

What I’d like to do is to gather up some stories and criteria from my readers.

If you would, here’s what I’d like from you:

  • A story (not too long, but enough to get the idea across) of your best or worst retrospective experience
  • What factors contributed to making it as good or bad as it was?
  • Your thoughts about what makes for a good – even exceptional – retrospective

Please – name no names, point no fingers – share the circumstances and even the details, without specifically identifying company/organization or people by name.

I know it’s a lot to ask. I think that when we’re done, we’ll have a powerful tool for teaching and learning about retrospectives.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

A model for understanding retrospective impact (from Patrick Kua)

Agile & Lean, Facilitation, Musings | Posted by Doc
Mar 25 2009

Steven List asks the question, Are Retrospectives an Anti-pattern? Of course, retrospectives are a topic close to my heart so I naturally wanted to share my view of them. The conversation apparently started on the Kanban Development mailing list and Steven’s post already captures some great discussion. I won’t repeat it here, but I find the dialogue echoing the same sentiments about other agile practices and whether or not they’re useful. For me, it’s too extremist and not particularly helpful. They make it sound like you need to choose from two positions: Either you run retrospectives, or you don’t.

I think the more interesting question is, “When are retrospectives most useful?” To help explain my thoughts, I’ve put together the following: A Model for understanding Retrospective Impact (click on it for a slightly bigger view).

via thekua.com@work » A model for understanding retrospective impact.

This is very connected to my earlier post, and well worth reading and commenting on.  Patrick has done some excellent work (hence his inclusion in my blogroll) on retrospectives, team building, training, and agile methodology. Go, read his whole post, and join the discussion of his model.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Looking…

Agile & Lean, Coping and Communicating, Musings | Posted by Doc
Mar 21 2009

Okay, so my last post about retrospectives brought up a lot of interesting stuff, much of it from comments. In fact, it stimulated more comments than any other post I’ve done.

I thought I’d take some time to revisit the issue of looking backward, looking around, and looking forward.

I’m not going to deal directly with retrospectives, but rather look at the question of how we go forward.

One of my favorite comments comes from Scott Bellware:

…when what we’re actually doing is “interventions” but calling them “retrospectives”, it’s time to call much more into question than retrospectives colloquially allow.

So what I interpret Scott to be saying is this: look around, and as you see something that needs addressing, address it now with all of your skills. If I wait until later, then I have done myself and my team a disservice.  If my interpretation is correct, then I agree.

Earlier, another Scott – Scott Andersen (”The Other Doc”) – said:

So, can looking back ever take you forward?

My gut says that motion backwards will always end up stalling a meeting rather than keeping the flow.

I’m not sure how he got “motion backwards” from “looking back.” What I can’t figure out is how to go forwards without at least (a) knowing where I am now and (b) how to distinguish forwards from backwards. I mean, forwards just means I’m looking towards my front – I could be going in circles, or just marching off a cliff, or effectively going backward by continuing to loop around until I get back to where I was.

Without backwards, there is no forwards.

So my premise is that I have to have consciousness of where I’ve been and where I am to know how to go forward.

Patrick Kua says it quite nicely:

I think there is still value in looking backwards. Part of implementing change requires people to see a problem that needs solving. Without looking backwards, it’s hard to understand what impact the problem has, how people view it, and often, what the root causes were.

More importantly doing this as a group is sometimes an essential part to gain a shared understanding of the problem and consequences. Without this, conversations break down into four different solutions as everyone perceives the problem differently.

The only problem I have with this is the word “problem.” Going forward (whether in a retrospective or otherwise) is not always or solely about problems. If we take “going forward” to mean “evolving, getting better, getting more efficient, or otherwise changing for what we mean by ‘the better’”, and replace Patrick’s “a problem that needs solving” with “a status quo/situation that could be better,” then I agree.

It’s Patrick’s second paragraph that makes the point for me – achieving a shared understanding, a shared pool of meaning – that is essential. And where does that shared understanding come from? Common history, which comes from either looking backward together, or from looking around together over time and having achieved a common understanding of what we see.

Any discussion of looking forward or moving forward, regardless of context, cannot be complete without distinguishing then from now from future.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Are retrospectives an antipattern?

Agile & Lean | Posted by Doc
Mar 20 2009

My friend Chris Matts stirred me up with the following:

One for you to think about for your Blog.

I consider retrospectives to be an anti-pattern. If you are learning great stuff in your retrospectives, it means that your communication is blocked. They are “batches” of “feedback”. I prefer single piece flow of “feedback”.

Last summer there was a big discussion of retrospectives on the Kanban list. I asked the question….. “Has anyone learnt anything as a result of a retrospective that at least one member of the group did not know about before?” So far, no examples.

Last year, my tech lead wanted to address an issue with one of his developers. He wanted to leave it to the retrospective.

If your team members are saying I’m sorry, I love you, Thank you in the moment rather than leaving it to the following day, then you may find that retrospectives are of little value.

My experience of retrospectives is that they are a place for developers to find their voice, and managers to ignore them. Managers like them because “The developers get it off their chest”.

Thoughts?

Intriguing.

Needless to say, I agree a bit, and mostly disagree.

Chris and I discussed this on the phone. First qualification from Chris: he is thinking about highly developed teams. Okay – I can see that with some highly developed teams, they may indeed learn to express themselves well on an ongoing basis. Of course, based on the folks I know – even the most highly developed – there are some things that are hard to deal with directly, one-on-one, or in an unstructured group environment like a team room.

Then there’s the idea of retrospectives being an antipattern. I just disagree. I suppose it could be, when used as a crutch or when turned into routine. If a team does something they call retrospectives, but every time they throw up two pieces of flipchart paper and do smiley/frowney or smiley/double-smiley or any other activity/technique every time, then I’d say they are not really using retrospectives to improve their process and team functioning. Is that an antipattern? Or a smell?

Chris and I tentatively agreed that it’s a smell.

Needless to say, I’m all for effective communication on a daily basis, and on not harboring negative feelings any longer than necessary. At the same time, I believe strongly that there’s a place for structured and facilitated activity, no matter how highly developed the team and individuals, to allow for the team to deal with those things that just don’t come out.

Finally, if done well/properly, retrospectives help a team be more effective, which means delivering better software on time and under budget. What manager wouldn’t be happy with that?

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Looking forward

Coping and Communicating, Facilitation, Musings | Posted by Doc
Mar 17 2009

Read the rest of this entry »

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Retrospecting on ITARC Atlanta

Events, Facilitation, Musings, Open Space | Posted by Doc
Mar 06 2009

Each new Open Space and variation on Open Space is a learning opportunity. ITARC Atlanta was no exception. Of course, there was the added note that in order to do ITARC Atlanta, I had to pass on ALT.NET Seattle.  I’ll come back to that.

ITARC Atlanta was another hybrid event – a day of workshops, a day and a half of presentations (including me ;) ), and a half day of Open Space.

Presenting: Facilitation Patterns and Antipatterns

I presented my new-and-improved version of Facilitation Patterns and Antipatterns (PDF). I’d finished reading Presentation Zen (also see Garr Reynolds’s blog of the same name), completely revamped the visual aspect of the presentation, reordered it to make it flow better (thanks to valuable input from  Patrick Kua and Glenn Kapetansky of ThoughtWorks), and was all ready to wow ‘em. I started off, got through the first 4 – 5 slides, and one of the attendees raised  his hand to ask a question. And that’s the way it went – one or two or three slides, then another question. Somehow, I made it through all my slides (although very briefly, for some), as well as answering questions and carrying on some very interesting exchanges with the participants (who shifted from attendees to participants very rapidly ;) ).  Needless to say, I came away with fodder for some new antipatterns and patterns.

Embedded Open Space

There is a pattern emerging in the technology and technology-related events I’ve been involved with. I’m referring to it as “embedded open space.” At these events, the organizers embrace the ideas both of Open Space Technology (OST) and eyes-front presentations.  The MDCs were an example of this, as was Microsoft PDC – at these events, they tried to do it in parallel (as my twitter friends (”tweeps”) say, FAIL). Folks in the OST community will assure you that parallel doesn’t work. There is no sense of community, no consistent body of people who share commitment, and competition between the two different parallel events.

At KaizenConf and ALT.NET Seattle, they were structured to have workshops first, followed by “pure” Open Space – sequential.

At the Microsoft Strategic Architect Forum (September 2008, San Francisco), it was structured as split days – mornings were presentations, afternoons were Open Space.

ITARC Atlanta was done as a sequential – first they did workshops, then they did presentations, and finally on the last afternoon we did an Open Space. There was good and bad about this. As always, a substantial number of the participants had never been to or heard of Open Space Technology. They had some loose preconceptions, but nothing that matched to reality.

The context was that this was Friday afternoon at the end of a very valuable conference, it was raining and chilly in Atlanta, and many people didn’t stay for the Open Space. I’m guessing, and would say that their thinking was something like “I don’t know what this is – I can stay for what might be a waste of time, or start my weekend early.” Out of around 160 people who attended the whole event, about 40 stayed for the Open Space.

As always, those who stayed were surprised (”Be prepared to be surprised!“) and got way more out of it than they expected.

The organizers were Joseph DeCarlo of Turner and Paul Preiss, founder and CEO of IASA. Joe and I have known each other for about a year, and Joe had been at the Microsoft Strategic Architect Forum, which was his first experience of Open Space. He became a convert, and was the driving force behind adding OST to the ITARC. Paul was a skeptic, and therefore wanted to limit what he saw as an experiment.  I’m happy to say that Paul is now a believer, too. :) .

Passing on ALT.NET Seattle

I got my start as an Open Space Facilitator at the first ALT.NET Open Space in Austin in 2007. It was a wonderful experience for me, and formed a bond between the ALT.NET community (and the individuals that comprise it) and me. I frequently think of them as “my family” or even “my chldren”. It’s a special relationship, both because of the community and because of the blend of technology and OST and agile that occurs there, all of which delight me.

I facilitated last year’s Seattle ALT.NET Open Space, and it was good.

We had talked about this year’s, but a date had not been set when I was invited to ITARC Atlanta.

When Glenn Block contacted me about this year’s event, I learned that it was to begin on Friday evening, February 27. That was when I would be finishing up ITARC Atlanta. Needless to say, there was no way to be in Seattle to open the conference. Glenn asked if it would work for them to open and create the agenda without me, and then have me arrive on Saturday morning.  Ignoring the logistics of taking a red-eye to get to Seattle, I still had to say no. The facilitator must be there for the opening – it’s part of the spirit of the event.

After considering his options, Glenn got Diana Larsen to come and facilitate. I was both delighted and dismayed. Delighted because Diana is a friend and a highly experienced and skilled Open Space Facilitator, so I knew she would take proper care of my family. Dismayed because I feared “what if they like her better?!?!?!?!” After all, I have facilitated most of the major ALT.NET events in North America, and most of them have never experienced anyone but me. What if…?

Having survived my attack of insecurity and anxiety, I’m delighted to say that Diana was as good as expected, and my family still loves me nonetheless. :)

One of my favorite comments was this: “I’d say that Diana embodies ceremony, while you embody essence.” I’m still not quite sure what it means, but I like it!

Next time, hopefully they’ll pick a date farther in advance so I can commit.

I’m planning on facilitating ALT.NET Houston in April, unless I go to China. Really.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Patrick Kua: A time and place for everything

Facilitation, Musings | Posted by Doc
Feb 24 2009

…as a facilitator, you need to be constantly aware of what the situation at hand is. I explained that if I’m facilitating a meeting for someone else, particularly retrospectives, I’ll normally prepare by interviewing a few people first (informally, sometimes formally if need be). I like to know who’s going to be in the room, and what problems might surface, or what situation I might be stepping in to. I learned this tip from Kerths’ original book. I like to prepare the room before everyone enters, set up posters, whiteboards, flip charts, etc. It’s courteous to the participants, and I’m always hopeful they appreciate the effort that I made an effort, with the end result being better quality discussions. I’ll observe people as they enter, and watch the body language of people through the activities.

via thekua.com@work » A time and place for everything.

Patrick Kua is a fellow ThoughtWorker (our name for employees of ThoughtWorks). He has been facilitating and writing about facilitation for some time. I’ve used his materials as reference, learning from them as I go.

In this posting in Patrick’s blog, he reflects on the essentials of facilitation, as well as a specific incident.  It’s well worth reading.

I liked the quote above, because it deals with the preparation that a good facilitator puts in to ensure a successful meeting (in this case, a retrospective).

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Twitter links powered by Tweet This v1.6.1, a WordPress plugin for Twitter.