thekua.com@work

My last post triggered a few comments, with having a common goal for a team to rally around somehow also implied groupthink, and thus, Wisdom of the Crowds is a better alternative. I want to clarify a few things:

The point of the original post?
Organisations where I’ve seen them have successful delivery, they also had, what I would consider, true teams. People working together towards a common goal. I’ve also observed many other organisations struggling to deliver, and often, because of multi-project context switching, they had what I would describe as “groups of people” instead of a true team.

Not all teams have groupthink
When I think back to great teams I’ve worked on, the individuals complement each other strengths and, at least in my experience, respond better to unplanned events. Talking about the “taboo” topics is fine because everyone is already comfortable working with each other. I compare this experience to what I see around committees, newly formed teams, or even teams that remain unbalanced (due to a particularly strong member or something) where other participants are too polite, or don’t want to cause a commotion even though it may be the right thing to do.

Understandably, when Felix saw my diagram, he (rightly) feared groupthink. In my experience, I feel it is symptom of poor performing teams, and is more likely to happen with “groups of people” (think of all those traditional project managers who make a decision for the team!). I do acknowledge it can still happen in a high performing team.

I believe the trick to making this work is having a leader in the team that ensures that conflict is handled in a safe environment, not simply quashed, silenced or bullied away as these eventually lead to group think.

Wisdom of the crowds don’t necessarily mean all crowds are wise
When I see many groups of people, I don’t automatically see a lot of wisdom. It takes another step before you can benefit from wisdom of the crowds. Often it means asking the right question, the right amount of diversity, and a lot of independence to actually benefit from it. I see the right question the same as having the right goal shared amongst people. It doesn’t necessarily mean everyone is doing exactly the same thing to get there, it just means that everyone is pointing in the right direction.

An example: Brainstorming using sticky notes is one way that I’ve worked in that avoids groupthink and tries to harness the wisdom of crowds. In my last team, we used it to come up with different solutions to tackle a key design problem (note the shared goal!) We each wrote ideas down independently on sticky notes before presenting them to each other. We even spent some time investigating and proving out a number of solutions to gather some hard data about the pros and cons. What made it work was that we all understood what it was we were all trying to get to (the shared goal), not necessarily how we get there. I felt that this was an example of a real team, a situation where everyone was comfortable disagreeing with each other, and openly discussing each option. It certainly didn’t feel like a committee or a random collection of people. I can only imagine what the outcome would be if we did though.

Once again, your comments welcome.

Comments(3)

When I go into different organisations, I see many of the people doing the work (analysis, development and testing) split across multiple projects. In my experience there are plenty of reasons why this is just a bad idea, and probably the biggest one that I see is that the split priorities for an individual conflict with a model for ideal teamwork.

What does your organisation have more of? Teams or groups of people “working together”?

There’s a big difference between the two, particularly if your organisation is interested in tapping into the benefits of teams. Unfortunately most of the time organisations miss the mark.

How can you convert groups of people into teams?
Split priorities create natural conflicts between groups. A lot of management theory I’ve read describes how to get the most out of teams by rallying them towards a shared goal or set of goals. At the individual level, setting different goals for different people establishes a dynamic that, at some point, individuals’ priorities will conflict and without a broader shared goal, will go unresolved. Setting the same priority for everyone is, in effect, putting everyone into the same team. Leaving people split across multiple projects, is in effect, setting different sets of priorities for an individual.

Comments(10)

I’ve previously written an article for InfoQ about how agile coaches act when working with teams. For this particular entry, I want to investigate what jobs or roles you might consider trying to either focus on part-time or try full-time to develop the habits and skills necessary to be an even more effective agile coach.

At the XP2008 conference I spoke with both Liz Sedley and Rachel Davies, two other agile coaches, who ran a workshop about agile coaching. We talked about the different skills an agile coach might need and some of the duties they might perform. We talked about overlaps with other jobs and concluded that an agile coach may do some training, yet only being a trainer doesn’t make you an agile coach (there’s more to it). Below is a diagram that hopefully makes it clear some of the responsibilities that overlap with a number of other roles.

As you can see in the diagram above, an agile coach may do many of the things you see full time facilitators, full time trainers, and full time coaches do. Yet doing each of these roles by themselves without the real experience garnered from agile projects does not make them an agile coach.

Using this as a model for career development

Even though I just put this diagram together to help others visualise this model, this is exactly what I’ve been using to further improve my skills as an agile coach. More recently, I’ve been in the role of a full time coach and trainer both internally and externally, and especially fortunate to work closely with other full time trainers to benefit from their experience. That experience has given me a better understanding of how people learn and a broader set of techniques to draw upon when helping others understand the concepts and principles.

Earlier to that, my focus had been towards better facilitation practice, reading books about good facilitation skills, and eagerly applying this during the projects that I’ve worked on. This has been particularly useful in executing the Retrospective practice. Beyond that, I’ve been lucky enough to work on many different agile projects in a development role, benefiting from others’ experiences through observation.

I’d be keen to hear what other full time or part time roles other agile coaches have attempted for short amounts of time in order to develop the skills that will make them a better agile coach. Please leave a comment if you have a suggestion.

Comments(1)

George Ambler’s blog entry titled, “Agility Means Simple Things Done Well, Not Complex Things Done Fast“.

Comments(0)

Not much to update other than I’ve returned from Canada and have been busy running a couple of presentations around the place, most recently heading up to Manchester for a night to help Alex Scordellis out with the Manchester Geek Night he’s running regularly. I ran a session called The Agile Primer, essentially an introduction to agile methods. We had a great turn out and I particularly enjoyed the discussion that ensued both during the session and at the pub afterwards. It still seems that, at least in that one pub up north, they shut relatively early. My only regret about the trip was that I didn’t get to stay longer and see Manchester because the weather was so nice.

Yesterday I helped out an analyst group with their Master Class on Agile. Liz Keogh and I pair-presented on ThoughtWorks’ experiences and lessons learned with distributed development, titling the session Distributed Agile: An Oxymoron?. We then followed this up with the XP Lego Game that helped people keep awake after plenty of talking and a heavy lunch.

All the slides and resources, you can continue to find on my page of presentations and papers.

Comments(1)

It’s easy to execute a particular practice. The difficult part is executing the practice well. This applies with any trade, any profession and anything we do. That’s why we have professional sports people, professional tradespeople, and professions in general. It takes a long time to get good at anything.

One thing I’ve learned from observing great leaders and less than great leaders is that those that make a big difference follow the words they say. Less than great leaders talk in one way, yet act completely incongruently with what they said. Some leaders don’t realise this, believing that what they say is enough to motivate people. The result is that people get confused, defaulting to the behaviour they see, not the words that are spoken.

The lesson here: It’s important understand what people hear because that can be different, and to ensure that what you do follows what you say if you really want the message to get across.

Comments(0)

May not be what people hear… Therefore it’s really important to listen to people, asking probing questions to ensure the intent of your message got across. I’ve seen many people (including myself) fall into the trap of focusing on delivering the method, that we never test to see if it made it across.

Comments(1)

In considering a leaner approach to software development, many people in the agile community are starting to turn towards an iteration-less approach. Wayne Allen talks of trialling No More Iterations, while Amit Rathore talks about an iteration-less agile process. Heck, I’ve even given it a go with a couple of my projects. On the other hand, there’s a whole movement in Italy devoted to the Pomodoro (Tomato) Technique that focuses on time-boxed activities.

So who’s correct?
The short answer: They both are.

Photo of a “time box” from Great Beyond’s Flickr stream under the Creative Commons Licence

The long answer: When you compare people not working in an iterative fashion (i.e. one phase of analysis, one phase of development, etc), to those agilists now turning away from iterations, there’s a noticeable difference, and is what I will call, discipline.

Those arbitrary time boxed units that we call an “iteration” creates cadence for teams. Cadence in turn creates rhythm, where teams can focus better on developing the healthy habits associated with agile software development. Much like the way that beginning martial artists repeat katas, it helps the Novice, Advanced Beginner and the Competent (Dreyfus Model) understand each practice individually and develop the discipline to make them effective. They don’t need to worry about which practice combines best with other practices, and yet, still see some benefit. It helps the team synchronise, predict and potentially even enforce when activities happen, giving people the stability they need when they are learning. It forces people to make important decisions that, without the associated discipline, end up deferred.

In absence of iterations, you need a guide to achieve a similar effect to encourage people to use the practices in an appropriate order. I argue that those people who are Proficient or Expert (Dreyfus Model) don’t need the iterations because they understand when to use what practice and the value it brings. They move towards what looks like an “iteration-less” approach because they are instinctively doing things iteratively without the arbitrary time box. They have enough discipline to ensure all the activities happen at the right time without causing disruption. Unfortunately, in my experience, many never make this jump to being Proficient or Expert.

What to do about it?
Iterations are useful, with that usefulness limited to a certain context. The learning level of the people involved heavily influences this. Respect the needs of the people you work with, and understand that jumping into “no iterations” requires a level of discipline you won’t achieve without people reaching these later levels of mastery.

Comments(7)