Antony Marcano's Blog - Latest Comments

Re: Software Teams can Jump

Antony Marcano — Mon, 30 Apr 2012 01:46:51 -0000

Yes, I've spent over half my time in the last 5 or so years working as a coach (the rest as a practitioner – keeping my skills current and relevant). The idea is very common on Agile development teams. I first read about the idea in the early 2000s in Kent Beck's book "Extreme Programming Explained". I experienced it on a couple of teams I worked on and found it invaluable.

How does it differ from a pro-sports coach? Well, I suppose I see myself a bit like a cross between a sports-coach and a life-coach. I gain my personal satisfaction by seeing peoples' work-lives improved through the gratification they get from excelling and extending the ways they excel.

The worst coaches I've worked with act like the boss. The best coaches I've worked with create a trusting atmosphere for the teams to draw on the coach's knowledge, experience and insight. The most awesome coaches I know can take a team on a journey of discovery about their untapped potential and help them continuously exploit more and more of it. These especially awesome coaches adapt their style depending on the team[1] and are skilled and versatile enough to work with any member of the team showing them how to do new things as well as learn new things alongside the team.

If you are interested in learning more there are several books on the subject of "Agile Coaching" [2]. I'm also more than happy to have a chat. Get in touch[3] and we can set up a skype call.

[1] http://agilecoach.typepad.com/...

[2] http://www.amazon.co.uk/s/?fie...

[3] http://antonymarcano.com

Re: Software Teams can Jump

Philip Hamilton — Sun, 29 Apr 2012 22:46:30 -0000

Very interesting the concept of a coach in a work environment. I guess you've been hired as a coach for a software dev team. How does a coach integrate into the team? and its a little different than a sports team because I would imagine you are not the boss whereas in sports the coach is the boss. So how do you define your role versus the boss/manager?

Re: This is not a manifesto: Valuing Throughput over Utilisation

Antony Marcano — Wed, 15 Feb 2012 01:37:34 -0000

Hi Squirrel,
These are great questions. Whatever you do, it's probably more about what people see as their responsibility. Individual flexibility and team autonomy will only help if the individuals and teams feel that their responsibility is to get features from concept to (production-ready) capability. If they see their responsibility as doing their bit (e.g. writing code or finding bugs) then flexibility and autonomy probably won't make a lot of difference.I'd explore ways to influence the culture of teams so they feel a shared sense of responsibility for getting working-features into production as well as looking for people who are open to being flexible and building trust to enable autonomy.With the hiring process, I think it's more a case of looking for people who are open to being flexible. This can be explored by posing questions to people that set a context where the candidate has to make a choice – do the thing most relevant to their job title or the thing that is most relevant to the team. If they choose the thing that is most relevant to their job title, explain the consequences – e.g. the release is delayed by 2 weeks. If they still don't choose to do the thing that is most valuable in completing the feature, I'd ask them why. If in the process of talking themselves through their reasoning they still are fixated on what's in their job description I'd be reaching the conclusion that they aren't flexible. That doesn't mean I wouldn't hire them because they may bring skills to the team that the flexible people can learn from and eventually use.

Autonomy is about trust. If management expectations are that people will do the bare minimum they can get away with to get paid then the biggest problem will be building that trust in a way that doesn't give the impression that 'command and control' is the reason for people working hard. Building trust is largely about transparency. Give people easy access and visibility of everything they could possibly want to know and they'll have no reason to mistrust. This is partly what end-of-iteration demos, visible charts etc. are about. Some of it is also about trusting in the skill of the people. I've had many conversations where, even C-level execs, try to tell teams how they should do things. A good CTO is like a good scrum-master. They protect the teams and steer others towards prioritising 'what' people deliver and fiercely guard the team's autonomy on how to deliver. In the same way that a CFO wouldn't appreciate the CTO saying what accounting methods should be used, the CFO isn't really in a position to tell the CTO what delivery methods should be used.

Some people may experience fear of having autonomy if they're used to being told what to do all the time. This is another thing to consider. So, introducing autonomy can be done in small experiments with small and increasingly frequent change.

One key thing to look at is organisational values. I'd be asking: What are the actual values today (not the ones written down but the ones people actually share in)? What do we want them to be tomorrow? How do we state those values? Are they a list of expected behaviours or the values that drive those behaviours? How can we influence people to care more about the things that will make us more effective? How can we find more people who already share in our values?

Thanks for sharing the questions that crossed your mind... I hope some of my thoughts have helped anyone wondering similar things and I hope I've added, in some small way, to your own thoughts on the subject :-)

Additional resources:

On company values: http://antonymarcano.com/blog/...

On making small changes: http://antonymarcano.com/blog/...

On autonomy: http://www.youtube.com/watch?v...
I recommend the related book "Drive" by Dan Pink

Re: This is not a manifesto: Valuing Throughput over Utilisation

Squirrel — Tue, 14 Feb 2012 18:02:58 -0000

Food for thought Antony. I wonder what hiring practises (filter for flexibility?) and cultural messages (exercise autonomy vigorously?) one might use to enable a team to adopt the changes you describe when needed.

Re: This is not a manifesto

Antony Marcano — Fri, 10 Feb 2012 13:13:05 -0000

I'll explain how I value quality relative to quantity. I'm not sure if that will involve a definition. Hopefully it will still add something useful to your thinking.

Re: This is not a manifesto

Richard Durham — Fri, 10 Feb 2012 10:23:28 -0000

I quite like that! Matches up well with my own drivers - although, as usual, you have expressed it much better than I could!

Looking forward to the elaboration around Quality specifically. I have been spending a lot of time recently (more than a year so far) trying to delve into what Quality is - what people mean when they use the word, specifically in terms of software but generally as well.

Richard

Re: This is not a manifesto

Antony Marcano — Mon, 06 Feb 2012 04:38:54 -0000

Thanks for the feedback Bob.

I can't promise definitions but I can promise an elaboration of the feelings that those words represent for me :-)

I like the idea of "progress", although it doesn't connect with me as well as "advancement". I had considered it and chose advancement instead.Mostly I chose it because it connects with how I feel. I completely understand your concerns about the message it might send. I hadn't considered the 'selfish advancement' issue... And I would hope that my team-mates wouldn't be thinking that way. My experience on teams is a sense of fellowship where this sort of thing generally isn't a concern. We advance as a team. I recognise that this isn't always the case.

Advancement, for me, is more than progress. It's about making advances in progress and our ability to make progress.

Thanks again for taking the time to give me feedback. The more I get, the deeper my understanding of these ideas gets.

-Antony

Re: This is not a manifesto

Bob Marshall — Mon, 06 Feb 2012 04:16:50 -0000

Nice post. Maybe would have chosen "progress" as a label in preference to "advancement" (too easy to mistake for personal advancement aka selfish ambition?). And I'd say the Quality over Quantity balance is, at least in part, context-dependent.

Looking forward to reading your definitions...- Bob

Re: Mission Critical Agility at NASA

Olu — Tue, 20 Dec 2011 17:47:10 -0000

Well said.

Re: Monsters, Names, Pot-Roast & The Waterfall Model

Jerrel — Thu, 17 Nov 2011 22:33:25 -0000

waterfall brought me here.. nice post

Re: Scenario-Oriented vs. Rules-Oriented Acceptance Criteria

Antony Marcano — Fri, 14 Oct 2011 15:30:22 -0000

I can relate to what you describe here (as in the looser way of working). That's quite consistent with teams I would be a team-member of... But then I wouldn't even be using terms like "acceptance criteria" in those situations. It would be little more than a card, the conversation and lots of collaboration - with whatever notes are necessary to aid our collective memory.

For those teams that do place a high emphasis on capturing up-front acceptance-criteria and can relate to the problems I outlined, then moving in the direction of scenario-oriented acceptance criteria might prove a useful step towards not needing them at all.

Thanks for your comments Liz.

Re: Scenario-Oriented vs. Rules-Oriented Acceptance Criteria

Elizabeth Keogh — Fri, 14 Oct 2011 05:31:24 -0000

I'm a massive fan of BDD, yes. I like to talk about the behaviour we're expecting, then look particularly for *unusual* scenarios - edge-cases which aren't obvious.

In the cases where the scenarios are obvious from the behaviour we've discussed, I'm happy to leave it at that, unless someone wants to automate it. An example might be:

"Replaced or refunded items should be added back into to stock unless faulty."

The four scenarios you could associate with this are obvious.

However, when I ask, "Can you think of an example in which items aren't returned to stock even though they're not faulty?" someone might say, "Oh, do you remember that time when that mother came in to get a refund because the buggy was too small, but it had been recalled anyway? Yes, we need to check for recalls." And now we have another scenario. *That* one, I'd want to write down - it's not obvious, and it's easy to forget. But I'll write down that specific scenario, with a title of "Check for recalls". And then someone says, "Oh, we can't even refund earrings for hygiene reasons, unless they're faulty!" And now we have another. So I'd write these down, but I wouldn't bother writing down the obvious ones.

That's why I can say that I'm into BDD, but not necessarily driven by specification by example - there *are* other ways to specify, and they're OK! I find the word "specification" stops people questioning quite so freely as well, so I don't tend to use it.

I'm very happy for people to have the conversations around as many scenarios as they want, and pretty much insist on it if it's something new or unusually complex, but I think people are starting to put *too much* emphasis on capturing every single scenario, when some of them are really obvious. In those situations, I'm happy with rules being captured (as above) instead as proxies for the scenarios they generate. The scenarios will appear when and if we automate. In the meantime, the focus can fall on some of the unusual scenarios instead (which are frequently around new, differentiating and therefore highly valuable functionality). So we don't "replace" the rules, because often we don't even bother writing them down!

The big difference for me is that where a scenario *needs* to be captured, I'll use specific, realistic, actual scenarios with realistic names and data, rather than capturing scenario-oriented acceptance criteria. I find it pings people's imagination more, and lets us come up with the other five scenarios that we *also* forgot about.

I have done the kind of thing you're talking about before, capturing all the scenarios to use as acceptance criteria. I found it useful in low-discipline environments, where the developers sometimes forget to check what's working and what isn't. I've got away from that recently by teaching Feature Injection instead, so that everyone has a clear idea of the value of what they're doing and the risks associated with it, and is motivated to understand their work better.

I've also done it when the scenarios have been discussed during planning meetings, and needed to be captured because the people doing the work weren't always the same as the ones doing the capturing, or enough time passed for them to forget. Persuading people to step away from fine-grained estimates (also using Feature Injection) and accept some discovery in the process of software development means we no longer have to do that either, and can talk through scenarios as and when it's needed, thereby keeping the knowledge fresh.

As a result I suspect that I have a slightly looser process - and I don't think either of our approaches is necessarily wrong. We may just work in different contexts.

Have a chat with Dan North about his "Ginger Cake" pattern some time, and please invite me for the conversation if I'm around :)

Re: Scenario-Oriented vs. Rules-Oriented Acceptance Criteria

Antony Marcano — Fri, 14 Oct 2011 03:21:21 -0000

Hi Liz,

Some of the things you've said don't make sense to me so either I've not understood you, you've not understood me, or a little bit of both.

Hopefully we can do something about that... What I think I'm saying, in relation to what you're saying is:

* Your "acceptance criteria" are what I call "rules-oriented acceptance criteria".
* I find that you can also take a "scenario-oriented" approach to acceptance criteria and I favour that over "rules-oriented acceptance criteria".
* Your "scenario titles" are also my "scenario titles" but they can be the same as my "scenario-oriented acceptance criteria" but they can't be the same as the rules-oriented acceptance criteria.
* Your "scenarios" are also what I call "scenarios" and I am in general agreement as to what goes into them (although our writing styles may be a little different).

In more detail...

Hi Antony, this makes sense. I think the only difference is that I'm calling the examples at the bottom, where you actually have specific albums and people, "scenarios", where as I'd call the short-hand form for the scenarios you identified "acceptance criteria phrased in scenario form". It isn't until we get "visible to me, not to others" that the scenarios start to emerge, and probably if we were talking through them we'd find more (eg: what happens if Jane visits a page where Fred used to have a public album?)

I can see why you might think that calling the "given-when-then" parts scenarios is different to what I was saying since I've re-read the post and it's not clear that I too also call those scenarios... Although I also acknowledged that some people also refer to them acceptance tests, so that's not different to what I was trying to say.

How is calling the "scenario-oriented acceptance criteria" (the phrase I used) different to the phrase you've used: "acceptance criteria phrased in scenario form"?

A better way of getting my point across might be that I call these "scenario-oriented acceptance criteria":

* Can create new private album (visible to me, not to others)
* Can make public album private (visible to me, not to others)
* Can make private album public (visible to me, & others)

And I call things like this scenarios:

Scenario: Can Create new private album 
When I create a new private album called "Weekend in Brighton" 
Then I should be able to see the album And others should not be able to see it

And, by using scenario oriented acceptance criteria, we can use the criteria as the scenario titles and the scenarios become an elaboration of the criteria, rather than mis-aligned derivatives of the 'rules-oriented acceptance criteria".

I like to retain the acceptance criteria in some form, but often only as the title for a scenario or a short description of what we're trying to achieve in the scenario blurb. I've found this useful in the past because we often miss scenarios (despite all the conversation, we don't know what we don't know).

If a team found it valuable to retain the 'rules' as notes or additional reference material, I'm ok with that... but I'd not want them to be regarded as acceptance criteria.

In order to demonstrate that the rules-oriented acceptance criteria in my "private albums" illustration have been met you'd need all three scenarios anyway... All the rules in my illustration apply in each scenario (i.e. the rules are cross-cutting) and are demonstrated by all three scenarios passing... so I'm not sure what value keeping the rules-oriented acceptance criteria would add.
Can you demonstrate how the acceptance criteria (as you describe them) or "rules-oriented acceptance criteria" as I describe them, can be used as scenario titles?

I'm not completely drawn in by Specification by Example as a result...

I am confused as to how you can not be drawn in by "Specification by Example" since you're such a strong advocate of Behaviour Driven Development...

Unless you have a completely different idea of either "Specification by Example" or "Behaviour Driven Development" to me...

What I understand from "Specification by Example" is that it's a general term to describe approaches that use examples, rather than rules, as the basis of a specification. Examples can be any form of stimuli with an associated outcome. I also understand it to imply that we infer the implementation both incrementally and iteratively from the examples and test our understanding by being able to execute the examples against the implementation.

Test-Driven Development and Behaviour Driven Development are forms of "Specification by Example" since we specify things by means of input-output examples (or stimuli-outcome examples). An input-output example may be very specific or more abstract, depending on what aspects of the input or stimuli is relevant to the scenario. From each example we infer the next evolution of the implemented algorithms to support these examples.

...though I do very much like talking about behaviour and having examples of it. Using the desired behaviour (or "acceptance criteria") as a title is a really lightweight way of getting the traceability, etc., that you mention.

I think what I'm trying to say is that by reframing our rules-oriented acceptance criteria as scenario-oriented we negate the traceability concern. I wouldn't call it lightweight... maybe zero-weight because we demote the rules to no longer exist or into nothing more than notes - so there's not need for traceability.

My post was mostly aimed at the opposite problem - when people were specifying scenarios too early and in too much detail, resulting in glazed eyes and boredom.

That's not the opposite problem. It's a related problem solved in a different way. My solution to that problem is expressed in the blog post as it's ok to discuss the criteria in terms of rules but (and this next part is where our approaches differ) replace those "rules-oriented acceptance criteria" with "scenario-oriented acceptance criteria" at the earliest opportunity. The key-word there being "replace". In the context of this problem, I'm only talking about going as far as writing the "scenario-oriented acceptance criteria" not the full scenario.

As for the examples you gave... the scenarios are exactly the same but for some word-smithing. The final elaborated example you give is a good one... and similar to where I might end up if that was what we wanted to happen. In my example, we had decided in the conversation that the person would get a 404 when attempting to view someone else' private album and that the scenario was adequate as it was.

I hope that clarifies what I was trying to communicate a little more.

Re: Scenario-Oriented vs. Rules-Oriented Acceptance Criteria

Elizabeth Keogh — Tue, 11 Oct 2011 04:06:59 -0000

Hi Antony, this makes sense. I think the only difference is that I'm calling the examples at the bottom, where you actually have specific albums and people, "scenarios", where as I'd call the short-hand form for the scenarios you identified "acceptance criteria phrased in scenario form". It isn't until we get "visible to me, not to others" that the scenarios start to emerge, and probably if we were talking through them we'd find more (eg: what happens if Jane visits a page where Fred used to have a public album?)

I like to retain the acceptance criteria in some form, but often only as the title for a scenario or a short description of what we're trying to achieve in the scenario blurb. I've found this useful in the past because we often miss scenarios (despite all the conversation, we don't know what we don't know). I'm not completely drawn in by Specification by Example as a result, though I do very much like talking about behaviour and having examples of it. Using the desired behaviour (or "acceptance criteria") as a title is a really lightweight way of getting the traceability, etc., that you mention.

My post was mostly aimed at the opposite problem - when people were specifying scenarios too early and in too much detail, resulting in glazed eyes and boredom. I reckon it's probably OK in that context to capture the acceptance criteria and just talk through scenarios until they're automated, while also capturing any unusual edge-cases that come up. So in that situation I'd have:

Make a private album public,
Make a new private album,
Make a public album private - Given Fred has a public album, when Fred makes the album private and Jane goes to look at it, then Jane should see "This album has been made private".

I think we both agree that whatever helps people talk, in their context, is fantastic. It's been a while since I've worked on a project where the testers haven't *wanted* to be more involved, so thank you for reminding me that this happens.

Re: Old Favourite – Developer Race-Tech: Continuous Testing

Antony Marcano — Mon, 01 Aug 2011 13:14:27 -0000

Hi Jean-Paul.

Firstly, it's a sad truth that many developers don't do much in the way of testing their code... and that's a shame because that means they are not taking responsibility for what they do.

Secondly, developers who aren't bothered about writing automated unit tests or are not running unit-tests frequently are not the target audience for this blog post... This really is targeted at developers who are employing TDD (or an approach that results in frequently writing and executing unit tests).

Beyond that, I think the direction you've taken the metaphor causes it to break down (as all metaphors do eventually)...

Think of running the unit-tests (something the developer does) as being analogous to selecting a gear (something the driver does).

Think of saving your files then telling your IDE or command-line to run the tests (something the developer does) as being analogous to de-clutching, moving a gear lever and re-engaging the clutch (something the 'typical' driver does).

Think of each save to a file (something developers do) automatically causing relevant unit tests to be run in the background as being analogous to tapping the up-shift paddle (something a race driver does) automatically causing the de-clutching, shifting of cogs and re-engaging of the clutch in the background. In this part of the analogy, I'm only relating actions of the developer to the actions of the driver... not the internals of the machines they happen to be operating.

JUnitMax and Infinitest are two plugins that behave just like this. They make the execution of your unit tests as unobtrusive as background compilation... they even run the tests that are most relevant first based on the class you've just changed.

I hope that clarifies my point a little...

Personally, I write and execute unit tests frequently and the less I have to think about explicitly pressing the keyboard shortcut to run my tests the better... I'd rather it just happen in the background.

Best,

Antony

Re: Old Favourite – Developer Race-Tech: Continuous Testing

Antony Marcano — Mon, 01 Aug 2011 13:13:30 -0000

Hi Jean-Paul.

Firstly, it's a sad truth that many developers don't do much in the way of testing their code... and that's a shame because that means they are not taking responsibility for what they do.

Beyond that, I think the direction you've taken the metaphor causes it to break down (as all metaphors do eventually)...

Think of running the unit-tests (something the developer does) as being analogous to selecting a gear (something the driver does).

I hope that clarifies my point a little...

Best,

Antony

Re: Sushi, Hibachi and Other Ways of Serving Software Delicacies

Antony Marcano — Tue, 05 Jul 2011 03:26:43 -0000

That might be a solution in some situations... Although, reducing the menu
options just makes the cooking more efficient. It may reduce the costs in
the kitchen but doesn't get the meals to the customer any more easily or
quickly unless those funds are used to boost the parts of the system
suffering from under investment.

The problem is rarely budget but perceptions of how much we feel we 'should'
have to spend on certain types of things compared to others. Rather than
looking at the evidence and diverting funds to balance out the throughput of
the whole system, people _feel_ that certain things _should_ cost less than
other parts of the system that are 'sexier' or are perceived as the main
value-add of the process.

The trick is to get people to care more about overall throughput of
delivered value above just cutting code or the 'cooler' practices of a given
methodology. This is what the Lean movement is really about... making
sustainable throughput of customer-value sexier than coding or branded
management methodologies or anything else... And to do this, the movement
fights fire with fire by becoming a branded methodology (or collection of
branded methodologies). But that is a whole different blog post..

Ultimately, people will always do what they _feel_ is right even if all the
evidence points to that being less effective than an alternative... And that
is the rather subtle subtext of this story :-)

Re: Sushi, Hibachi and Other Ways of Serving Software Delicacies

Roland Stens — Mon, 04 Jul 2011 12:41:41 -0000

What if we simply shrank the menu choices?

Re: To hack, or not to hack

Salim Virani — Mon, 13 Jun 2011 15:00:01 -0000

Hi Antony, would be interesting to know how you see the forked Kanban approach fitting here. http://agilefocus.com/2010/04/...

Re: Old Favourite – Developer Race-Tech: Continuous Testing

Jean-Paul V — Mon, 06 Jun 2011 17:07:04 -0000

Unlike the race driver who's gearbox was designed, built and tested by somebody else the developer has to, at least most of the times, design, built and test the test cases himself if he/she is to (re-)use a continuous testing tool. I think herein lies the crux of the problem. A lot of developers do not seem to want to put in that kind of effort for something they either do not do anyway or are content with the test cases they have added to the code.

Re: Old Favourite: QA / Testing – what’s the difference?

Antony Marcano — Mon, 30 May 2011 05:08:54 -0000

There's been a subtle evolution to how I express my thinking on this subject since I wrote these articles in 2008. ..

Although "Testing" is more analogous to "Quality Control" it isn't "Quality Control".

Quality Controllers have the ability to reject or accept a product based on a set of pre-set criteria (and perhaps a certain amount of their own judgement).

In software teams, in my experience, this is rarely a decision made by the person(s) testing it... and rightly so.

It is a decision made by the 'product owner' or 'product manager', or others with more visibility of the business concerns.

We are 'developing' a product - not manufacturing one. Something being wrong with our product is analogous to something being wrong with the design or entire production line of a manufactured product - i.e. all instances of that product will be affected, not just one at the end of the production line.

All affected stakeholders should have some influence on the decision and it should be decided based on a risk vs. reward basis (relevant to that the business or domain). Testers can tell the business folks what the deficiencies of the product are but the people with their finger on the pulse of the business and its market are best placed to decide whether going live is a risk worth taking.

So, the only variation I would add to the above is to emphasise the word "more" in the statement "Testing is more analogous to Quality Control." And I'd say "but Testing is not Quality Control".

Re: Monsters, Names, Pot-Roast & The Waterfall Model

Large Planter Pot — Thu, 26 May 2011 11:22:21 -0000

I'm so love this blog, already bookmarked it! Thanks.

Re: Software Teams can Jump

Paul Dyson — Mon, 23 May 2011 08:39:27 -0000

Sorry ... couldn't resist ... an hour after I posted this link popped into my twitter stream:

http://www.infoq.com/news/2011...

From the first entry written by someone described as an Agile Coach:

"Do you work hard to make them agile since this is what they're paying you to do even though they really don't want to change?"

"Make them agile", "what they're paying you to do", "they really don't want to change". Not much self-organisation and emergent behaviour going on here!

Re: Software Teams can Jump

Paul Dyson — Mon, 23 May 2011 07:01:17 -0000

Hi Antony,

a comprehensive and insightful response which I'd love to respond to in detail. But I'm going to resist ... partly because I don't have time to write a long letter, let alone a short one right now but mostly because I think detailed point-and-counter-point discussions are best done face-to-face. Maybe we'll meet one day and can have that discussion.

Instead I'm going to step back and try and explain the context in which I make my comments so you can see where I'm coming from. I've read your article four or five times now and it really is about having 'a coach' (specifically you in most cases). A labelled individual with an identified role:

"If you have a professional software team without *a coach*, consider ..."

"Competitive sports teams always have *a coach*. Temporary coaching in a professional sports team is almost unheard of"

"On many teams, once *I* move on, there is a coaching void."

"I always say to my clients to keep at least one day in their budget for *me* to go away and come back some time later"

You're absolutely right when you say you are asking questions rather than offering conclusions, albeit with a bias based on your experience that having 'a coach' is a good thing, and what I'm doing is positing a different set of questions with a bias based on my experience.

Why?

Two things make me feel uneasy about the growing 'cult of coaching'. The first is that I've seen many teams thrive without 'a coach'. Yes, Kent had coach down as a role in his first edition - I don't blame him, he's American, they see the whole of life as a sports metaphor - but none of us who started out in the early days took that too seriously. We couldn't really because there were no coaches to call on; we all had to make our own discoveries and mistakes. Different teams talked to each other and learned from each other but I can't remember a single one appointing a coach from inside or outside. And those teams all did great things partly, I believe, because their behaviour and learning emerged as a result of self-organisation and experimentation.

[As an aside: some of the best-known coaches emerged from those teams and I wonder whether they are so well-known and talented because they have just been around for longer or because they got so much from learning it all for themselves?]

As soon as you appoint 'a coach', no matter how experienced and talented, how well-meaning and adaptable, some of that self-organisation and emergent behaviour goes out the window. Its human nature: even in a team of experienced peers, identify someone as 'the coach' and the team look to them for guidance. Remove that person and they feel they have lost that guidance (a "coaching void"). In other words you can take a team that would tend towards self-emergent behaviour, and be very strong for it and, by providing guidance, deny them that opportunity.

And this is assuming the coach is a benign and benevolent presence (and something I want to say is none of this is an attack on you or any individual ... I'm sure you're a great person who adds a lot of value to any team you work with). If the coach is a bit naive, doesn't understand the business domain well enough, hasn't got the right techniques for this team, is having a bad week, whatever, then their guidance may take the team to a place it really doesn't want to be. Either way, a question the team or the manager or the business owner should ask themselves, alongside the ones you pose, is "can my team self organise and can behaviour emerge or do they need a guide?" if the answer is they need a guide a further questions need to be asked: "are they the right team; is the coach the right coach?".

The second thing that makes me uneasy is an extension of the first. The more people - usually professional coaches - who say "you really need a coach", the more this becomes accepted wisdom. Its an age-old pattern: want to do something different, get in an external guru.

Now maybe you don't mean it quite like that. Maybe you see all 'good' coaches as experienced facilitators who don't even provide something as directed as 'guidance'. But that's irrelevant because managers and business owners will always look to external gurus when they need to make a change and large consultancies are built on the back of providing those gurus. How long do you think it will be before IBM has a team of 3000 certified coaches? How will people distinguish between the good coaches and those peddling Agile Method/1? If the government decides they need to do 100 agile projects why would they come to the likes of you and Rachel and Liz (great people all) when they can go to KPMG and take advantage of their agreed rates and loss-leading prices?

You see I think the sad thing in all this is that *the* truly great thing about XP and agile was that it started off being about teams discovering for themselves a new way of doing things that took complete advantage of the soft nature of software and the unique way in which people delivering software could organise themselves and work. I'm afraid that what I see with the establishment of Coach as a job title and Mastership certification is the erosion of that celebration of the uniqueness of software and software teams to something that is much more standardised, commoditised and off-the shelf. So my hope is more people ask themselves the question: "do we really need a coach or can we just do it for ourselves like so many others have?"

Hmm, a longer letter than I'd hoped ... as always. Will leave the final word to you.

Cheers,

Paul

Re: Software Teams can Jump

Antony Marcano — Sun, 22 May 2011 05:43:11 -0000

P.P.S. Paul, I hope my last significant comment addressed the key points of our disagreement and refined our understanding of that disagreement further... It's occurred to me that you are not really the target audience for this article. "Experts" (à la the Dreyfus Model of Skills Acquisition) generally find maxims and rules frustrating because an expert knows they don't always apply.

So, I guess the intended audience was the teams that drop any form of coaching way before they are ready because a manager somewhere wants to save money... not because the team elects to go it alone.So, the expert version would contain the sorts of things in my most recent comment to you... Essentially saying that I've found ongoing coaching valuable and I've seen value in recognising coaching as an area to develop skills in within the team... and that finding someone with those skills to come in periodically and tell you what they see from the satellite view can help you spot things that the team might not see.