Draw Me a Picture!

The "Dialogue Room" at last week's ScrumGathering in Munich was intended by conference organiser Tobias Mayer to create more space for high-bandwidth learning, in contrast to the many "talking heads" sessions planned for the Gathering. Activities there included a Haiku workshop with Liz Keogh, Innovation Games with Lowell Lindstrom and Paul Culling (video here), Tobias' self-organising Scrum Clinic (The Doctor is IN), and my own Retrospective Exercise workshop.

I invited conference participants to try a non-verbal retrospective exercise I call "Draw Me a Picture," which brings right-brain, intuitive information into team conversations. I first ran it in 2006 with team members drawing separate images, but this time I returned to Norm Kerth's original "Art Gallery" exercise, and ran it as a group effort on a single sheet of paper.

After doing a first drawing together (see instructions), we incorporated feedback from participant coach Rachel Davies (using fewer, fatter markers) and did it again, also swapping in a couple of new group members. This second drawing they entitled Chaos <--> Order. Interestingly, both this and the earlier drawing included "flow" shapes similar to the one I blogged about in 2006, (also made in answer to this question). For YouTube fans: you can see both drawings in Paul Cullen's video of Olaf Lewitz talking about the exercise.

After each drawing, participants asked "What else do we need to do?" as though they expected further steps. For me it's clear that the drawing and ensuing conversation are themselves the ends we seek. There is no great "Aha!" required, and there is no "what's next" step involved. The team simply discusses their drawing long enough to give it a title - in the process exchanging important and possibly new information.

After looking again at the drawing we created, I would say that the mechanistic way we attempted to implement Scrum in 2004 is much more obvious [in the drawing] than in the tales that I was telling people about this experience.
-- Jurgen Hoffmann, Agile Coach and Trainer

In his Retrospectives book (p 195) Norm Kerth briefly explained how this creative right-brain/left-brain activity tends to produce unexpected new insights. This new information and way of interacting can enhance relationships and provide important background for other retrospective activities, which will likely include more left-brain modes such as speaking, writing and analysis.

"Draw Me a Picture" is probably most useful at the beginning of a Retrospective, especially when emotions run high; when there are undiscussed undercurrents; when team members speak different native languages; or when relationships need to be built or repaired. It should be followed by activities that let the team discuss, analyse, learn and then also look forward constructively to "what's next". (To find such exercises, see these books). And given that each picture contains at least 1000 words, Rachel and I suggest that, in general, images should not be shared outside the group doing the retrospective. (The ScrumGathering drawings were displayed, with participant approval. These differed from most team retrospectives in that the drawings didn't delve into sensitive team relationships or controversial events).

Was it worth the time and energy, dragging all my art supplies to Munich and back, to run this workshop with a handful of people? If it truly improves the product and experience of even one team, my answer is "yes." Jeff Sutherland's more abstract "by making your Stories truly "Ready" for Sprinting, you can achieve 4x productivity" is broadly inspiring; my workshop was very personal, practical and specific. We need both, in my opinion. As it happens, the exercise has helped a team: this week I received this thank-you note from one participant:

When I came back from the gathering, my team was in a bad mood, people were unhappy and they didn't finish any story this sprint. I used the drawing method during the retrospective and I was really amazed how it allowed people to express their feelings -- I believe, more openly than when I had asked them to write stuff on index cards. It helped us talk about the bad team atmosphere and the reasons for it, and they came up with a lot of ideas for improvement. Without that method, this would have been "just another retrospective" with people discussing technical issues instead of the root cause of the problems.
-- Ute Platzer, Software Developer and ScrumMaster

Postscript: While reviewing the feedback from this event, I realised that doing this excercise at a conference had an unexpected side-effect: we discovered that, in addition to using it with established teams, it can quickly introduce strangers and help them connect! The key, of course, is a truly common experience. The question cannot be abstract, like "What is Scrum like?" It must be something specific and personally experienced: in this case, the group settled on: "What was my first contact with Scrum like?"

What I liked ... is that it gave us an easy and fast-forward way of getting to know each other much closer (in that one direction) than it would have been possible with words (only).
-- Olaf Lewitz, Process Consultant

The exercise created relationships between the four of us - and after the Gathering I am still exchanging emails with Olaf and Ute. There was no previous relationship - but somehow, a common history.
-- Jurgen Hoffmann, Agile Coach and Trainer

I am doing my thesis, please answer my survey!

Ah, it happened again today. One of those mildly annoying mailing list posts, you know: "Please help me with my thesis! Just follow this link to fill out a survey on Agile and xxx". I deleted it.

When the second email came, with the title "Agile developers.......... Please help,,,,, I have to complete my thesis ," I was annoyed. The note included "Why IT professionals don't have 5-10 minutes to help a poor student ,my degree is on risk ,now ". I decided to answer her question. I'm posting it here, in addition to my private mailing list reply, hoping it is useful to others, since we all see these requests a few times a year.

Hello, (Grad Student)!

When I saw your first request for responses, I immediately deleted it from my inbox. I'd like to tell you why, by way of supporting your studies.

You seem to have received few replies. Now, most of the people on this particular mailing list are westerners and Agilists, and I wonder if there might be some cultural differences at play here. I'd like to tell you a bit about how we tend to operate, perhaps it will be helpful to you.

Before asking people to spend time helping me, it's considered polite that I should first build some relationships. At very least, introduce myself, who I am, my interest in joining the group. Even better: join some conversations. Find out what we think of your subject. Coming in as a stranger and asking or begging people to help you with your homework is considered by many to be, at best, a nuisance.

I notice that you did include a paragraph stating your objectives and how you will use the information. There's potentially another cultural problem there, which you may not have considered. You are talking to people whose mantra includes "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." (see http://agilemanifesto.org/principles.html). For some of us, the terms "offshore" and "Agile" clash, because we have seen too many projects with half a team in India (for example) and half a team in the US, trying to do Agile, and it makes our brains hurt. Sure, it can be done, but it's fraught with problems and some (many?) of us recommend against it.

So, when you mention "offshore" you hit a nerve that made me immediately think: "the topic is an oxymoron" and I deleted the email. However: looking at it again, it's entirely possible that what you meant was an offshore company doing work for a client in another place (the whole team is offshore). This is a scenario I still don't like, but it is workable, and not so offensive to my Agile values. Is this what you meant? Had you started a conversation around this topic, this subtlety might have come out, changing my response.

Beyond culture, there's also the issue that those of us active on Agile lists have seen many of these kinds of requests. The first few times I went to investigate, and found the questions poorly formulated, indicating no understanding of Agile, or else formulated in a way that I could not see how my answers would in any way provide data that would be useful to our community. (For example, there's no option for position = dedicated Agile Coach/ScrumMaster; it requires my company name, which I won't give out; and how can simply "select a success rate" be meaningfully aggregated, with no context?). Some are simply too long! Those of us with the information you need are also, typically, *very* busy and careful how we spend our time.

Now I just ignore such requests. Which makes me sad, as I like to support people doing good work to further Agile, but so far my experience says that answering surveys isn't the way to do it, as Agile success/failure is highly context dependent, which seems difficult to capture in a short survey.

I invite you read what Scott Ambler wrote about surveys, including why so many of us don't answer them. He said "...This wouldn't be such a bad thing if the surveys provided value, were designed well, and the results were properly published. However, this often isn't the case and as a result fewer people choose to fill out online surveys because they feel that their time is being wasted (and sadly it often is)." You can read this near the bottom of this page, which also offers hints on creating surveys: http://www.ambysoft.com/surveys/agileSurveys.html

If you feel you could convince us of the value of your survey for increasing healthy Agile adoption, and would like to tell us more about it, please do!

All the best for your studies
deb

PS: My intention is not to embarrass you or chastise you - I hope you see this email as helpful, I put a lot of time into writing it. We are big on learn-and-adapt here, so please do try again if it seems appropriate. (I included some concrete feedback on the survey in question, but have deleted here). By the way: that doesn't look like a 5-minute survey :-)

--

Deborah Hartmann Preuss
Agile Process Improvement Coach
Team and Personal Effectiveness Coach
Open Space Conference Facilitator
Editor, InfoQ.com/Agile

"Life can only be understood backwards, but it must be lived forward."
-- Soren Kierkegaard


Readers: I've made some generalizations here. If you disagree, please join the conversation!

The REAL Agile Coaches Pub

Agile Coaches!

Forget this Skype business - let's all meet for a REAL drink in Toronto, on Monday August 4th, the night before the Agile2008 conference gets underway! All agile coaches, mentors, leaders are welcome - and bring a friend! Collective-Edge invites you to join us on Monday night to kick off the conference with jazz and good conversation!

It's simply a social time for coaches to meet and get to know one another before we get swept away by the vast sea of choices at the conference. Not a vendor event. No agenda. No free food :-D

We will meet at the Rex Hotel jazz bar, 3 blocks west of the conference hotel, on Queen Street. Drop by, order a drink or some finger food, and enjoy live jazz at 6:30 and 10:30. Conversation is encouraged but can't be too loud – there is an outdoor patio adjoining the room if we need to be louder :-)

Location, Directions and other details are in the Google calendar event, see:

http://www.google.com/calendar/embed?src=1aaevite9iulkfeu9cvu2ot348%40group.calendar.google.com&ctz=America/New_York

or use this to add the event to your own gcal:

What Would Happen if you Asked a "Powerful Question"?

Well, I think I've found my passion! I've ventured into the world of professional coach training, starting with Co-Active Coaching, taught by the Coaches Training Institute (CTI).

A key Co-Active practice,called "Powerful Questions," (though far from new), blew me away - here is a way to create new possibilities in my retrospectives! The trick lies in NOT asking the weak question, particularly the "yes/no" question which pre-loads my assumptions into the conversation. The "why" question is no better: it can feel like an attack, prompting a "justifying" answer, rather than encouraging reflection and honesty, which would be more constructive.

Now that I'm watching the questions I ask, this Skype exchange pleasantly surprised me this week. I intentionally tried a powerful question, which my colleague sidestepped, so I tried it again - to my delight!

[4:07 PM] He says: me...I'm completely burnt out at the moment
[4:08 PM] I say: Oh dear. How do you feel?
[4:09 PM] He says: mostly sleeping for about 2-3 hrs for the past few weeks
[4:09 PM] He says: some days I had to skip
[4:10 PM] I say: But how do you feel? Sad? Mad? Disappointed?
[4:10 PM] He says: I feel excited
[4:11 PM] I say: oh! that sounds good! about what?
[4:12 PM] He says: about some of the stuff I'm working on ...

Now "how do you feel" is a rather ambiguous question, so the second time I clarified, by indicating I was interested in his emotions (although I definitely revealed my assumptions there!). And yet, he stopped to check in and surprised me with "I feel excited," which led to a short conversation becoming a new Product Owner, and how much satisfaction it brought him! A month earlier, it might have gone differently on my part - this fictitious alternate path, leads to a rather "down" conversation, in which my assumptions may have reinforced a hopeless mood for my colleague:

[4:07 PM] He said: me...I'm completely burnt out at the moment
[4:08 PM] I'd say: Oh shoot! Are you getting enough sleeping?
[4:09 PM] He said: only 2-3 hrs for the past few weeks, some days I had to skip
[4:09 PM] He said: too many things and the damn day only has 24 hrs ;)
[4:10 PM] I'd say: I know what you mean. Can you get some sleep soon?
[4:10 PM] He'd say: Not really :-( the baby is teething again
[4:11 PM] I'd say: Rats. You must be frustrated
[4:12 PM] He'd say: yup
[4:12 PM] I'd say: Well, let's get this business done quickly then...

It seems to me there's really no opening for new conversational directions when the questions have "yes/no" answers. And by projecting my assumption about his mood, I missed the opportunity to celebrate a great new thing in his career! Fortunately, this wasn't the conversation we had :-) .

So next time a team member is rehashing, yet again, the story of something that happened months ago, instead of asking: "Why are we talking about this again?" try asking an open-ended question, like: "What do you make of that?" Listen carefully: it might surface some underlying issue that people have felt uncomfortable talking about. A "safe" workplace would, of course, maximise the effectiveness of this question - providing motivation to rout out the unnecessary "Why" (blaming) questions!

More on Powerful Questions:

THE ART OF POWERFUL QUESTIONS: Catalyzing Insight, Innovation, and Action
by Eric E. Vogt, Juanita Brown, and David Isaacs.

Powerful Questions for Agile Teams
by Lyssa Adkins

Qcon: for better software team performance

Professional development has many facets: reading books, keeping up to date with news and journals, and working with colleagues to learn from one another. In the field of IT, we need to keep up-to-date and fresh.

InfoQ and JAOO have joined to offer another resource: the Qcon conference. The first edition will be held this spring in London, UK, and includes two tracks of interest to practitioners of Agile approaches. Agile Foundations is for teams just starting out. The other track, combining lectures and an all-day Open Space event, is called The Agile Journey - How do we Reach Mastery? and targets more advanced practitioners, though novices are welcome.

I'll be hosting these two tracks, and I've just finalized the lineup. I'm pretty excited about the event: there are talks for both technicians and managers, and the Open Space event will be led by Diana Larsen, who will also present a one day tutorial for leaders: Moving from Management that Controls to Management that Facilitates. Steve Freeman, winner of the 2006 Gordon Pask award for Contribution to Agile Practice will speak twice on testing, and Jeff Sutherland, co-creator of Scrum will share lessons learned implementing Scrum at Google.

If you'll be in Europe this spring, join us for a customized 3, 4 or 5-day Enterprise Software event. Pick the tracks that scratch where you itch: Meet the experts, work directly with them in Open Space, and enjoy the good food and social events of this new conference with us!

Further details about Agile tracks are outlined in this InfoQ news post.

Tags:

• InfoQ
• conference

OpenSpace benefits both beginners and experts

I recently facilitated an OpenSpace event in Montreal, and some simple changes from previous similar events made it a much more satisfying event for all. What did we do?

First, we "opened the space" with all conference participants, whether they intended to stay in OpenSpace or not. This allowed people to flow in and out of the OS event, confident of the rules and free to fully participate if and when they wanted to.

Second: inadvertently, we found ourselves in a wonderful room layout. The large room had two entrances, on south and east sides of the room. The tutorials were taking place on the south, and the coffee was beyond the east door... inviting non-OpenSpace participants to wander through the space. I think that two doors for the OS space may be a key pattern: allowing curiousity without committment :-)

I noticed something interesting happening at one session, and wrote it up for my publication, InfoQ.com. I interviewed the participants at one session to better understand the dynamics of a session which included both total newbies and very expert participants:

Experience Report: Beginners and Experts All Benefit in Open Space
Agile events are receiving an influx of novices - should new conferences be organized for beginners? A report from XPday suggests that mixing up expertise levels creates a valuable experience for all.

Enjoy! (We did! :-)
deb

Tags:

• openspace infoq

Measuring What Matters

Robin Dymond and I enjoyed making our presentations at Agile2006. As promised, here is a link to the files related to our topic:

Appropriate Agile Metrics: Knowing What and When to Measure

Tags:

• agile metrics Agile2006

Process is Inevitable - Embrace It, Then Change It :-)

A fellow agilist asked a question about Scrum and process - wondering why an Agile methodology would be rather rigid about basic practices. Here is my answer, from the ScrumDevelopment yahoo group:

Re: Are SCRUM and XP actually Process Oriented?

Hi Vicky.

I do not think we need to divorce the term "process" from Scrum. However, Scrum is not, in my mind, "a process" but rather a way of thinking about process.

Alistair Cockburn's point in Agile Software Development (well, he probably made more than one point, but the one that seemed to start it all rolling :-) is that in his research, successful teams generally were not doing what they "thought" their process "ought" to be. In fact, their process really was whatever they were actually doing. People working together have process. People working with Scrum have process. It's just not *defined* process.

I think what keeps me sane as a Scrum coach is this: Scrum reminds us that this process belongs to us, and teaches us tools for making it better over time. What Scrum does prescribe is an *empirical approach to process*: decide what to do, do it, inspect the results and reflect on them, decide what to do next...

In my understanding, the empirical approach requires that some things be held *constant* while others are varied, to allow us to measure results and draw conclusions in relation to what went before. To allow this, Scrum Masters teach a set of practices which have worked well for many teams, and suggest that, at first, teams hold these practices constant while they observe the effects of all the other variables - personalities, politics, room layout, hardware, and especially the elusive "self organization" that must take place in the interstices intentionally left between these few recommended practices.

If everything is varying, there is no basis for comparison, and the team is back into ad-hoc-ism, or perhaps chaos.

I would call a team a Scrum team if it uses the basic Scrum practices, or can explain why they don't use them and how they have compensated for their absence. Imho this latter kind of explanation requires an understanding of process patterns and subtleties that novices are not likely to see, being caught up in the maelstrom of the paradigm shift. So I'd expect a new team to use the basic practices for many iterations, while they learn the real patterns of Scrum, which are not about the practices at all, but about values and thinking and collaborating and truthfulness. In fact, another name for these patterns might be "common sense" or "wisdom"... For many of us, Scrum is an attempt to teach a return to common sense.

I'm very visual: I think the practices must be practiced in a "wax on, wax off" manner for a time, to allow teams develop "process improvement muscle" while the underlying truths emerge. (do you know the film Karate Kid? :-)

So, yes, there are a few rigid aspects to Scrum for beginners - consider them training wheels, or roller-blading knee-pads. As a coach, I see that there is a time for these, no matter how frustrating. If teams were not frustrated over the practices, they'd be frustrated over something else. In fact, they probably were, before we began Scrum. It's human nature.

When teams whine, I ask them: do you think you know enough about Scrum to understand the implications of removing this practice? Do you know why it is there, and how to compensate for its absence? If not, I recommend they continue with it for a while and focus on changing something else.

Best of luck in your Scrum adventures!

deb

Deborah Hartmann
Agile Process Coach
CSM/P
Toronto

PS: I still use knee-pads... but not training wheels. Make of that what you will :-)

Tags:

• scrum agile process continuous-improvement

Fitting Agile into your Ecosystem

(On June 14th, a colleague posted some objections about getting Agile to work in certain environments. This is my answer to some of his points).

Hi Alex.
You are definitely not alone in noticing:

... that managers and bosses have the real problem moving to agility.

I believe this is one of the reasons that some Agile practices have got such a bad rap - teams are rushing ahead without engaging management, without getting them onside, and without providing to them the information they need to do their jobs. Naturally, when management then feels the stress of change, they respond out of old habits - incompatible habits. Too often a power struggle ensues.

This has, in fact, become a major focus of thought and practice among senior Agilists, so I'm surprised that you also say:

Most of the discussions around agility are centered on what and how the developers must/should do.

As you know, you can pull up information on InfoQ.com by tag. In fact, *I* couldn't use the tags if you hadn't coded that InfoQ back-end :-)

So: using this tag: www.infoq.com/leadership/ you can find many items specifically aimed at managers and those in leadership positions. Follow the links - you'll see there is a lot out there! This has been a major theme since the "unlaunch" of InfoQ, because it is a major theme among the Agile community, which is made up of more than developers - there are more managers and CxOs joining our ranks weekly.

So, on what do you base your assertion that: "most of project managers and bosses will not embrace agility" ? Most of whose project managers and bosses? Yours? What tactics have you tried?

In my own experience, when managers are approached respectfully, with real solutions, it's not hard to get their ear. It takes time... patience is required. What does respectful communication consist of?

• speaking with the goals of the listener in mind (upper management probably doesn't care about design patterns when the date is slipping. Talk about that date);
• asking questions ,and listenint carefully to the answers - they'll tell you what they really need if you simply ask (and then you can couch your proposal in terms they will hear);
• not bothering them with programming-level benefits like "it's fun" (unless employee retention is an important problem);
• providing good background information from sources they can trust and understand. This means that philosophical articles like How Long Is a Piece of String must be balanced with practical information like Planning 101 for Agile Teams or Craig Larman's book Agile and Iterative Development: A Manager's Guide, if they express interest.
  

In addition, you mention:

I haven't met many managers that would spend time explaining their thoughts
and
... it's hard to believe that all clients you will meet are agile

Yes, the Agile culture change works best when it reaches throughout the organization. Wise organizations train teams *and* managers, customers, etc. I've seen numerous organizations do this: Business Analysts taking Certified Scrum training, managers attending Agile interest groups, CxOs walking through XPday asking questions.

On a recent contract, the team's manager made it clear, in no uncertain terms, that the shift to Agile had to be entirely invisible to their customer departments. By the end of the second day of training, he was optimistic that perhaps one or two of his customers would be interested. In their planning meeting for iteration 3, an engineer said "It's really interesting to see how long you guys think this will take", as he left the planning session. He has been one of the team's biggest supporters, and always arrives prepared. A few weeks later, a senior manager (not related to development) publicly commented on the interesting things going on in that team. And at the 14-week pilot retrospective, when I asked "what surprised you?" the answer was: the positive response of our customers!

You are right: Agile is not a panacea. It does not fit all teams or organizations. However, Agilists don't see "they won't like it" as a reason to abandon hope. Why? because it's not terribly helpful (or respectful) to assume that people will answer negatively. We say: ask them. Show them. Engage them. Find a way to deliver some value, and use that to open the door to conversation. If they let us, we will take them by the little finger, and next thing we know, we're holding hands and collaborating, cranking out more value than ever before. When they resist, we try to be creative and create bridges, hoping that they will be temporary.

Sometimes it doesn't work. That's life. But I think you'd be surprised how much easier acceptance can be than we fear. This is why Agile work requires Courage. I say: "you have not, because you ask not". When we act with courage and respect, amazing things do happen. One of my goals is to collect on InfoQ the stories and case studies that tell such stories :-)

Wish me luck!

Tags:

• Agile InfoQ

Teamwork in Real Life

I'm sitting patiently in the waiting room in the Women's Hospital maternity ward. It's been a long labour, and everyone is tired - most notably the star performer. In the delivery room, important and difficult decisions are being weighed.

I'm doing what, I suspect, a number of other geeky maternity-support-persons are doing elsewhere on the planet, while waiting for the happy announcement: working, while a FIFA match whispers away in the corner. In my case: working on ideas related to metrics and how to appropriately measure our work. Ok, it IS a little hard to focus :-) I'm cherry picking the easy work. My mind wanders.

It's an odd juxtaposition: my work, as it happens, has never been life-critical... if I make the wrong choice and screw up at work, no one dies. Here, today, a bunch of people are collaborating to make something life-changing happen (one very small and inexperienced, another other near exhaustion, the rest largely spectators). The decisions being made in that room are relentless: there will be no change of scope, quality must be maximized for all involved, and we're already paying for a little slippage in the due date. There's actually a bottleneck right now, and no way to share the burden. Compared to my 'important' work decisions, the difference is stark: these decisions are of a completely different order, and they must be made. They will be made.

It reminds me that we make critical decisions frequently, in relation to our lives and the lives of others. Is this the right nanny for my kids? Should I risk the side effects of this medication? Is Lisa really old enough to drive responsibly? Will moving grandpa to a care facility avert a house fire or break his spirit? We have figured out how to make these decisions, because we must: focus on our values, do the best we can to achieve them, stop frequently to evaluate, recalibrate. Why does this skill somehow evaporate on the commute to the office?

Oh, an update: we're apparently playing the "decide at the last responsible moment" card. Tick, tick, tick. More waiting. So...

Why do we spend so much energy getting 15% savings in our colour photocopy usage, while our customer support costs soar unchecked through the roof? Why do we work overtime on features that no one has asked for? In short: Why do we silently watch the corporate train head over a cliff? Is it that we've learned to be "good (i.e. obedient) corporate citizens"? It makes me crazy: this is NOT teamwork.

Teams, over time, align their goals so they are all running in the same general direction. Narrowly defining the concept of "team" at a departmental level does not accomplish this: the Facilities team "wins" when we save on photocopying, the Development team "wins" when the software demo goes smoothly. But if nobody's minding the store, we all lose - in fact, we could be losing the whole time we are "winning".

I like to think in pictures: in keeping with the theme of the week (and the expectant father's occupation :-), which of these soccer balls will speed toward the goal first? No matter how well-aimed or artfully executed, these six consecutive kicks on ball A will not send it very far up the field. The analogy breaks down about there, I think (I'm a swimmer, forgive me if it fails entirely :-) But it brings me back to the workshop Robin and I are creating, called Appropriate Agile Metrics: Knowing What, and When, to Measure. Our title graphic is the lovely drawing of Alignment recently published here. It's a call to common sense, in the hope of fostering aligned values in our workplaces, so we can all pull (kick?) in the same direction.

Still waiting. Some time today, order will emerge out of chaos. Time to stretch my legs...

Update: Brandon Choumbe-Niles was born on Father's Day, June 18th, 2006 at 12:56 PM, with an absolute minimum of intervention :-) and mom and baby are calm, happy and well. Hurray!!

As I left the still-dark room this morning to find coffee, my sleepy friend said: "thanks for the great teamwork!" Well, I'm pretty sure I didn't do the hard part... apart from driving and sustenance, my job is to send daddy some photos. (PS: it really does take a village :-))

Tags:

• teamwork babies delivering_value

InfoQ.com Online Community Launched!

We went live, over at InfoQ.com yesterday! It provides news and content to the Agile, Java, .NET, Ruby and SOA communitites - particularly for managers and team leaders of all sorts.

Come over for a visit, and if you like what you see, you can register and customize your view of the site, to eliminate news and content in the queues that don't interest you - for example, perhaps Ruby doesn't impact your work - you can make all the Ruby news disappear!

Since we opened the site for preview three weeks ago, we've already had over 15,000 unique visitors... and more than a thousand individualized RSS feeds have been created by members.

I'm pretty excited about what this site can do to help teams - there's so much information out on the web, we can bring things to your attention in time, that you might otherwise miss! Registration deadlines for great conferences, significant blogs, podcasts and articles on the web that you'd hate to miss, and exclusive content - books, articles, interviews - that you can really use. Join us!

Tags:

• Agile News InfoQ

(Just enough) Order out of Chaos

I recently ran a retrospective with one of my teams, for a 14-week Agile pilot project. We had a few extra minutes before lunch, so I tried an optional exercise I had on my agenda: Please draw a picture of how you feel about the Pilot. It could be realistic or completely abstract.

Now, this team had had the usual Scrum rollout trials, but also a few good surprises: some things had gone far better than they'd anticipated. Some of their main concerns had been job satisfaction and earning respect within the organization. At the point that we did the retrospective, the team acknowledged that they were in a bit of a slide back into old bad habits, which didn't worry me (I know they'll pull out of it), but it did concern them.





So I was pleased and surprised with Val's drawing: if I can help many people feel this way about their work, I will have had a valuable and rewarding career. We didn't talk much about what the drawings meant, so I leave you to draw your conclusions, as I did mine :-)

By the way: the team nominated Val to be their next ScrumMaster. Her optimism seems to be contagious!

Tags:

• Agile Scrum Retrospectives

InfoQ site "unLaunched" and available for early bird review!

Well, Floyd Marinescu's labour of love is finally ready - InfoQ.com is in pre-launch beta testing and we'd love for you to have a look and send us your comments! And feel free to blog about it - the more the merrier! Official launch is set for the end of the month. Cross-posted - apologies to those of you subscribed to all 3 lists :-)

http://www.infoq.com/news/InfoQ-Unlaunched

We hope this will become both a resource for local agile communities, as well as a platform for discussion and for publishing quality written works, perhaps by you!

I'm really pleased to be part of this team... well, two teams really: editors and developers, since our team has created its own publishing platform with features not seen elsewhere. It's still under development, I can't wait to see it when the full featureset has rolled out!

enjoy,
deb

Tags:

• infoq news agile

Agile Spirits Discovered at Web 2.0 un-Conference

The sold-out Mesh Conference began today in Toronto: the hordes have descended for what's predicted to be Canada's seminal Web 2.0 event.

Web 2.0 is a buzzword coined by those who believe there is a paradigm shift going on in the way people will interface with the world wide web. It has continually incorporated (and spawned) the latest web innovations (podcasts, hacks, tagging), innovations commonly called "Social Computing" applications. All agree that the meaning of Web 2.0 is still in flux, but the general gist of it seems to be this: the web as a computing platform, by the people, for the people - perhaps having started with the original wikiwiki, and now extending to a plethora of commercial and open-source applications, including well known apps such as Google Maps, Flickr, del.icio.us, digg and Technorati.

Not surprisingly, for a crowd whose watchword seems to be "disintermediation", the creed produced by some of their members looks much like an artsy version of the Agile Manifesto. And why not? The more the merrier! Here is an excerpt of a much longer Mesh Manifesto:

In this 2.0 world, transparency is the new black.
And it’s an enduring trend.
With transparency, authentic branding isn’t an oxymoron.
With transparency, organizational courage is expected.
With transparency, social media reigns.
With this, we’re living in a new space of openness.
A paradigm shift toward honesty.
An existence of integrity.
A time to be frank.
And I am Frank. It’s not my name. It’s who I am.

A number of Mesh speakers and attendees headed over straight from Toronto's second successful BarCamp event, which ended just last night, called BarCampTdot. Mesh is, in fact, partially an outgrowth of the BarCamp un-conference movement that's been gaining strength internationally since last autumn. Or perhaps BarCamp and Mesh are both outgrowths of some common precedent. It's hard to tell: organization is purposely decentralized, memes spread and morph freely... who know where any idea really comes from? (BarCampers will tell you: it doesn't really matter).

These people are worth watching - their energy is enormous, and infectious. Their OpenSpace-inspired un-conferences are unleashing fresh ideas and unexpected partnerships,and are garnering attention from government and mainstream media. The potential for synergy (or competition) with the world of Agile Software Development is tough to ignore: we'll be reporting more about Web 2.0 in the coming weeks, and encouraging Agile developers to be aware of this important movement among our design- and useability-oriented colleagues.

Tags:

• Agile Web2.0 TorCamp BarCampTdot BarCamp

TorCamp 2.0

A great weekend - that once again proves that great teams are where you make them :-)

Here is my Flikr slide show of some of my favourite photos of the event, courtesy of our BarCampTdot photographers, including Matthew and this luminous photo by Bryce.

More later!
deb

Tags:

• TorCamp BarCamp BarCampTdot

What's Deb up to?

I've been busy in Toronto, doing a little coaching and looking for the enterprises that want help tuning up their development processes... it's slow work, but they are out there! I really want to work at home, if I can - though attractive jobs are more plentiful in the US right now.

I'm also working these days with Floyd Marinescu (formerly of TheServerSide.com) on his latest venture, the InfoQ Enterprise Software Development Community, online. It will serve 5 different communities: Java, SOA, Ruby, .NET and Agile, and it will have interesting customization feature, so people see exactly the kind of news that interests them. InfoQ launches later this month, and I'm pretty excited about it!

I'll be the editing the Agile community area of the InfoQ site!! The launch is coming later this month - right now it's taking up a fair bit of my time, but eventually it will be a fun part-time job.

We are targeting leaders in enterprise development: team leads, architects, managers, educators. It will disseminate news, articles, interviews and presentations on subjects of interest to our community. Floyd has the benefit of lots of "lessons learned" from his TSS experience, and he has some interesting ideas for making this site relevant and easy to use. I'm also impressed with his committment to values that I also hold dear: focus on community, emergence, simplicity, and on delivering real value to customers - our readers.

We want to foster dialogue, promote quality within the community, and seed the development of new ideas by getting the good stuff out there for cross-pollination. Essentially, get people talking to one another in different ways than they do now - focused on individual articles and issues. (This is not a replacement for existing forums, but could direct people to forums when interesting threads come up in the news). We have an impressive lineup of articles and presentations already, for the launch, from senior people in their respective communities - you can check out our editorial lineup, if you like.

I'm open to content from Agilists... if you've been wanting to write but don't know where to publish original material (an article, a minibook, or a video of a talk) please get in touch with me and I'll tell you more. I make no guarantees, but my mandate is pretty broad :-)

We'll be at www.infoq.com - I'll be sure to get word out when we launch!

OpenSpace for Collaborative Conferences

For the life of me, I can't recall how I heard about OpenSpace... as far as I recall, my first OpenSpace was the one I sponsored in Toronto in 2004! OpenSpace is a way to facilitate an unconference, created twenty years ago by Owen Harrison, who now uses it for The Practice of Peace.

It's an amazing way to put people in motion fast... they arrive with nothing but their burning passion to discuss the theme topic... and within an hour they've created an agenda containing all the topics closest to their hearts and are already sitting down, talking to strangers with similar interests!

How does it work? Half of the OpenSpace facilitator's work happens before the event - crafting a provocative Theme and producing the Invitation. It's not as easy as one might think - OpenSpace works best when there are multiple points of view in the room, even outright conflict, which means the Theme must be neutral to draw people from all camps, otherwise it's just a mutual admiration society! The facilitator works with the Sponsor to make sure the venue is suitable, and that there will be nutritious snacks available to fuel the intense conversation that will fill the day.

Then, on the day of the event, the Facilitator comes in with some signage, and puts the chairs in a single big circle. The Sponsor invites participants to sit in this democratic arrangement and sets the theme. Then the Facilitator starts the process by inviting them to leave their preconceptions outside - asking them to adopt the 4 principles and 1 law of OpenSpace:

• 1. Whoever comes is the right people!


• 2. Whenever it starts is the right time.


• 3. Whatever happens is the only thing that could have! and


• 4. When it's over, it's over


• and The law of mobility: If you find yourself neither learning nor contributing, MOVE ON! which means that people are free to attend the sessions they signed up for, or not... sometimes the best session happens in the coffee area, which is intentionally set up to invite conversation!

The facilitator then helps the group collaboratively create an agenda - anyone can stand up and name the topic they want to discuss... and in about 30 minutes the group will organize the topics into a schedule on the wall and sign up for items they like. And now they are ready!

The rest of the day is run by the participants - they start their respective sessions and bring notes back to the faciitator, who photographs or collates them or helps them enter their notes in a wiki... so that participants can have a record of all sessions by the next day!

It's amazing the connections that get made - simply because people follow their passions. Likeminded people meet and spawn new ideas, plans, business relationships... it's wonderful to watch, and memorable every time.

At the closing circle, participants are invited to share their reflections - what will be different for them, going forward from this event? OpenSpace is simply a jumping-off point... it galvanizes groups to resolve long-standing issues or move into new avenues of action.

Note: No A-V equipment required! No banquet to plan! (food is kept buffet style in case sessions run over). No expensive keynote speaker! Computers optional, if you want a wiki.

We've heard Regis say: "ask the audience, it's never wrong!". OpenSpace harnesses the wisdom of crowds and simply gives permission to create and act back to the crowd. Hurray!
(one day, we will no longer need permission... oh, that's a "fourth" thing! :-)


Here's a terrific video of OpenSpace at recentchangescamp
And a report from OpenSpace at XPday Montreal 2006

Read more about OpenSpace, on Larry Peterson's site.
Resources for creating an OpenSpace Event: from Chris Corrigan, and Michael Herman.

Reflections on facilitating Open Space by Chris Corrigan: The Tao of Holding Space [pdf]

In my Lifetime

Leila pinged Mark, who pinged me...


In My Lifetime, three things I would like to see...

• all individuals treated with equal respect, regardless of skin colour, beliefs, abilities, language, or wearing the right labels


• housing made affordable for families at all income levels


• workplaces filled with passion and laughter, as we encourage each other to discover and contribute our best abilities.

What do you say: Jen, Chris, Mike, and Tobias? Or anyone else?
Please tell us what you'd like to see, on your blog or in a comment here :-)

Groups Perform Better Than The Best Individuals...

A new study in the April issue of the Journal of Personality and Social Psychology (published by the American Psychological Association) indicates that "Groups Perform Better Than The Best Individuals At Solving Complex Problems". No surprise to those of us teaching collaborative work practices!

BlogHer

Jen, who I wrote about in my last item, also drew to my attention BlogHer | Where the women bloggers are, asking: did I want to be involved in a Toronto BlogHer conference in 2006? You bet!

Ladies, you can list your blog on this site - there are already over 2000 of us! Yet another online community that may spawn great things!

It's a Small World

I call it "networking". Linda Rising calls it "Tell Everyone". In her Patterns for Building a Beautiful Company, Linda has a pattern called "It's a Small World":

You’re an entrepreneur who wants to create a Beautiful Company. You’re trying to practice Beautiful Leadership. What’s the best way to get what you need?

Organizations, like all human groups, operate through conversation. [Senge 99]
    Therefore:
Tell everyone you meet about your current projects.

The people you meet everyday are the quickest way to get what you want. If you’re unemployed, they’ll help you find a job. Most jobs are found through friends or personal connections. If you’re looking for an employee, personal contacts will help you find the right person...

It sure works for me!

An acquaintance, Chris Nolan, pointed me toward TorCamp last November, where I met a whole new community of passionate geeks :-). Last night at Molly Bloom's pub, networking with the DemoCamp crowd, a familiar-looking woman sat down (who is she? why does she look so familiar? oh yeah! it's Jen, Chris's lovely wife!). Jen is an app architect with IBM, and she told me about her current passion, Web 2.0. I told her about my latest escapade, editing an online publication, and it turns out she can provide the article I'm looking for on how Web 2.0 intersects with enterprise application development - Cool! And, as it happens, Jen is looking for a place to publish... looks like we can help each other out!

Jen took off to find sustenance (or wings, whichever she could locate first) so I chatted with my good buddy Derek. We were trying to figure out how we'd met... we couldn't recall, but it was surely more of this sitting-around-over-food! (that's a different Rising pattern we use, "Do Food" ) I told Derek about my current passion for "emergent documentation" and my quest to integrate tech writers into my software teams' collaborative processes. Lo and behold, Derek is a single-sourcing geek! I've been looking for someone who knows both single-sourcing and Agile software development, particularly Agile testing tools like Fitnesse. Who'd have thought I'd find him in Molly's attic? I was thrilled! Stay tuned for the book!

Never understimate the power of "hanging out". I can testify: tell EVERYONE what you're up to, and make opportunities to do so. They will in turn tell you. And, before you know it, you'll be doing more of what you're passionate about!

:-D

DemoCamp and Community

The buzz is building... TorCamp's DemoCamp5 was held last night at U of T's Bahen Centre for Information Technology to a full house of 141 attendees, the largest DemoCamp yet.

DemoCamp is the place to demo *working* software - we've seen things alpha release state to yesterday's mature 6-year old HP authentication app. But the real star is the crowd, and the real venue was upstairs at Molly Bloom's pub - where we gatherered afterwards for wings and GREAT conversation - and where I made a couple of excellent connections. It's this informal networking that is yielding all kinds of new collaborations... suddenly Toronto is on the radar, because TorCamp is growing organically at a rapid rate, principally on the energy and effort of its participants. At David Crow's invitation, we started in November with 50 people and have met at least monthly since them, each event bigger than the next. Makes me wonder how many will join us at TorCamp2 in May? Two hundred? I can't wait.

Joey DeVilla took some photos, and writes more about DemoCamp, including the great news that we'll be meeting at MaRS from now on, a permanent home for DemoCamp that can handle our growing crowd! You can also read about DemoCamp in Profit Magazine.

I'm all about community - can't help myself! I have formed ScrumToronto with Mike Bowler, helped hatch the ScrumAlliance with Ken Schwaber, recently formed the Toronto Agile Coaches group, and will facilitate at TorCamp2 in May. These groups show that great, productive teams can form anywhere - not just at the office. I definitely consider myself a member of the great TorCamp team.

Don't wait for community to happen where you are... get out there and make it! It
s easier than ever - people who think like you are blogging and tagging, so you can find them easily enough. Who knows what you'll get into... all you need to start is to invite some like-minded strangers to meet you at your favourite cafe for supper... then watch to see where it goes! For heaven's sake, TorCampers are starting to get involved with government thinktanks on ">culture and technology! Create a community and watch it go!

What is a Coach worth?

Coach Kevin Rutherford and I have been musing on this subject: what meaningful measures can we propose to clients to evaluate the results of our work?

Kevin's made a start in thinking about this...
silk and spinach: process improvement metrics - some questions
Hopefully we can discuss this with other coaches at Agile2006 in OpenSpace.

Coaches: by what measures do you evaluate your work? It's tough, isn't it? What are your frustrations?

Further reading:
Value-Based Fees : How to Charge—and Get—What You're Worth
by Alan Weiss (on Amazon)
(caveat: I've not read this yet, but it's well reviewed)

Wanted: Cat Herder

One of the methodologies in which I am trained, and which I teach to others is Scrum Project Management. The team lead in this approach is called the "ScrumMaster" (tongue firmly in cheek) or sometimes referred to as "the sheepdog" because he or she must care for the team, keeping out intruders and distractions. At the beginning, some folks have a hard time wrapping their mind around this role, because it feels to them like the old Project Manager role, but with strange twists. Here is an excerpt from an email conversation with an apprentice, in which we discuss how the ScrumMaster can be accountable without having authority. It starts with something written by the co-creator of Scrum, Ken Schwaber:

> Subject: Day in the life of a Scrum Master, according to Ken
>
> 1. Ensure everyone is doing what they have agreed to do;
>
> 2. Determine where this iteration is compared to where it could be
> and update your work-remaining tracker ( & task board, if used);
>
> 3. Work the product backlog (list of work for next iterations);
>
> 4. A dead Sheepdog is a useless Sheepdog; and,
>
> 5. Use all of your senses, including common sense, and remember
> that you have no authority.
>
> (from the CSM methodology v5, with Scrum-specific terms translated for clarity :-)
>

after which the apprentice asked:

> No authority sounds rather scary!...in what context?:)

My reply:

The Team is FULLY responsible for the outcome of the work, the product, what is demonstrated to the Customer at the end of the iteration. It is in this context that the ScrumMaster is not a performer, and has no authority (i.e. to say 'we should do this' or 'here's how to approach it' or 'you missed that'.) The ScrumMaster must keep the team aware of this fact, so they have motivation to solve problems themselves in a 'whole team' manner, and not a CYA manner.

How to deal with this? Try 'I've noticed...', 'have you missed that?', 'I have an idea - what do you think?' 'It's up to you', or asking an OPEN question: 'I've noticed we have Requirements in 5 places. Do we need all of these?' At first people find this threatening, assuming I am passive aggressively saying we DON'T need these. No, it really is an open question, and you can assert that all you want, but the best way is to show it - ask them and REALLY let them tell you - no answer is wrong. For example: During the Requirements discussion, I saw BL tense up when another team member asked "do we really need to write JUnit tests?" So I asked "BL, what do we lose if we get rid of them?" and from his answer, the questioner quickly realized that quality and thrashing is at stake, and the issue died right there. Now that they have discussed it THEMSELVES they will hopefully continue to manage that issue themselves. If not, another question may be in order.

The ScrumMaster is the remover of obstacles (looking ahead, taking them out of the way, but not too far ahead in case of YAGNI: you ain't gonna need it). This includes getting things ready for the team, in time: room, needed materials and tools (computer, markers, paper, whiteboards, chocolate, DBA, lunch, meeting rooms, onboarding etc.) This is why the ScrumMaster should start work before the team, so they can hit the ground running.

The ScrumMaster is responsible for facilitation (getting people to play nicely together - oh my gosh, is this a challenge some days!! :-) But it is also rewarding, when you look and everyone is quietly collaborating and putting their best skills into the work.

The ScrumMaster is responsible for having the big picture (not of the work itself - the team is responsible for that) but the big picture of the Working of the team - the process. This includes stakeholder relations: getting things off on the right foot and letting the team handle it from there.

The ScrumMaster IS responsible for herding the cats in the right general direction (have you seen that wonderful EDS video ad about cat herders? It's hilarious!

Thanks for the good question. Hope this is helpful, or raises more good questions.

ciao
deb

Catching the right stuff

"I am often mad, but I would hate to be nothing but mad: and I think I would lose what little value I may have as a writer if I were to refuse, as a matter of principle, to accept the warming rays of the sun, and to report them, whenever, and if ever, they happen to strike me."

E. B. White

One of the things a coach does is "sit outside" the team, keeping watch. Why? Because culture change is hard, and sometimes it's impossible to see what's really happening from inside the team, because there are no reference points. The coach offers a point of reference outside the team, and can beneficially "catch" things happening and point them out, to enhance learning.

What kind of things do I catch? Well, obviously I'm watching for behaviours or language from the old paradigm that creep into the new patterns we are trying to adopt, diluting the experience. But you know, one of the most enjoyable things I do as a coach is to catch people doing the right thing. When people are caught up in the moment, when they've "got it" and are finally doing naturally what we've been teaching... when they do the right thing for the first or second time - take a moment to notice it.

I'll wait for a break in a discussion and say: "Did you notice what Jane (a designer) did? She's pretty sure she knows the answer, but she made a point to ask the Product Owner to confirm her thoughts, because the Product Owner is responsible for the direction of this product. That's great! That's just what we want to be doing!"

There will be lots of time to discuss what we wish we'd done better - over lunch, or at the retrospective. But we'll forget the things we did right, because they just came naturally at the time. I mean, who remembers what Fido looked like at 4 months of age? He grew a little each day, and suddenly he's not a puppy any more!

So, do it when you notice it happening. It's like taking a snapshot - freezing the moment for a second, to enjoy it. Your teams are doing things right all the time - and working hard to make it happen. Give them the reward of heartfelt praise and encouragement in real time - they deserve it!

GridBlogging

I think I first heard of intentional concurrent blogging on Hal Macomber's excellent blog. Obviously it stuck in my mind... it's resurfacing now, more than two years later.

It's called gridblogging: "a group of bloggers tackling a specific topic on a specific day" and what attracts me about it is the concurrency aspect: everyone is writing fresh, so the perspectives are very personal, not derived from each other's entries as with the blog-and-comment pattern. Have a look at one such entry by fellow Agile practitioner Laurent Bossavit.

"Grid blogging aims to investigate the potentials of a distributed media production model spread across blogosphere nodes. It seeks to ignite attention on specific topics at set times through variegated voices. A kind of decentralised flash mobbing for the mind, if you like.

Decentralisation is key here. Unlike single collaborative blogging structures that unite discussions under the same URL, Grid blogging is about synchronized guerrilla publishing attacks carried out across a series of online locations. It respects and heightens the individual voice within a media-wise choir. It allows for idea-jamming and mosaics of diverse perspectives to emerge unfettered".

from *the initial invitation to Grid Blog project by Ashley Benigno. november 7, 2003

Bloggers use a common prefix on blog titles to allow them all to be found with one search. I've added Technorati search to my Firefox search bar, so all I need to do is type "[grid::fatherhood]" to find the other blogs in this ring (don't forget the quotes).

Sounds like tagging, actually... perhaps it would be better simply to create a tag and use technorati or del.icio.us? GridBlogging predates tagging as it is used today... but I wonder if is there still some benefit to using the prefix instead / as well? Are there gridblog aggregators?

This post seems interesting, using blogs to actually get work done - a BlogPosium!

Article: Whither GridBlogging?

TorCamp

Ok, you'll probably need to follow the links to keep up here :-)

TorCamp is Toronto's own Barcamp. TorCamp 1.0 took place last November in the offices of Teehan+Lax, and was a blast.

I've been a member and leader in the Toronto Agile community for a few years now, and it was really nice to meet smart, passionate people from outside our own community. The more, the merrier, I say!

On the heels of TorCamp came the first DemoCamp, a different kind of event spawned by a discussion at TorCamp. So, got working software, that you'd like to share with other geeks? This is the place - you have 15 minutes, GO! There's been one a month since then, see the TorCamp page for links to DemoCamp event pages. Its future is uncertain, in that it's growing exponentially, which is at odds with its grassroots feel. Last time there were about 150 in attendance!

An unfinished conversation at TorCamp spawned the CostVsValue supper discussion, where a dozen of us discussed pricing our services.

And the desire to once again do something more interactive probably triggered TorCampSlamCamp, an interesting Saturday afternoon where about 30 strangers worked in teams on a non-computer problem, just for the fun of it!

And now we're planning TorCamp 2.0! As with other BarCamps, it will be organized along OpenSpace lines. Feel free to sign up and join us! But remember: NO SPECTATORS! Come prepared to contribute!

On Passionate Discourse

Life is too short to pull our punches. This article by Ron Jeffries really resonates with me.

What are you doing?

You've no idea how often my apprentices saying: "but wouldn't it be more efficient to..."

Agile work focuses on effectiveness. I recently asked my coaching colleagues: what is the difference between efficiency and effectiveness?

Efficiency: saving time, money or effort.

Effectiveness: producing powerful effects.

and

Efficiency: doing things right

Effectiveness: doing the right things

No wonder it's such a challenge to bring about the Agile paradigm shift. Depending on what you value, efficiency or effectiveness, your objectives, means and measurements will differ.

Think about that for a sec :-)

Blink and BNET

In Blink, staff writer from The New Yorker Malcolm Gladwell reveals that great decision makers aren't those who process the most information or spend the most time deliberating, but those who have perfected the art of "thin-slicing" — filtering the very few factors that matter from an overwhelming number of variables.

Hmmm, sounds like a great skill for a ScrumMaster, doesn't it?

Note: BNET is a great aggregator of free information on leadership and organizational behaviour, much of which is compatible with Agile principles. I subscribe to their newsletters, so I don't have to read all the ads on their site :-) but the site is searchable, which is useful.