what is your experience of mentoring programmes?

One reason I started this blog is that my left and right brains don’t seem to be connected to each other: I tend not to know what I think until I hear myself stating an opinion, and then I’m often horrified by what I hear. So blogging is a bit like talking to myself. Steven Pinker (I think) even suggests this — talking to oneself, not blogging — is the most plausible reason for the evolution of speech. Anyroadup, I haven’t been doing enough of either during the last few months, and I’m feeling the effects.

However, I have recently discovered the fun of asking and answering questions on LinkedIn, and I’m finding it has much the same effect as talking to myself. So when I answer a question over there, and in so doing discover I have an opinion I like, I’ll share it here too. Here’s the first one…

Andrew Calvert asked: “What is your experience of mentoring programmes? Mentoring; some think is an organic process that cannot be artificially replicated. Others think that you can assign mentors to learning partners (or mentees!) put in enough structure and have a working mentor programme. What do YOU think? Experiences?”

My answer:

I believe mentoring involves a) being a role model, and b) partnering to share knowledge. Institutional mentoring programmes (such as buddy systems for new joiners) can be great initially, but in my experience only pass on basic information. On the other hand, role modelling — and the kind of mentoring that goes along with it — has longer lasting and more positive effects.

In my work in software development I always try to involve both aspects. And I find that mentees (sic) self-select once they’ve seen that I’m working in a way that gets results. So when a developer asks for my help, he’s usually already seen how I work; I can therefore help him solve his problem in the same way.

So yes, I think mentoring is “organic” and should not be forced upon people. But organic growth always starts with a seed, and I believe that seed is the presence of role models who are willing to help and share.

Do you have experience of role modelling or mentoring programmes? Which works (best)?


carnival of the agilists, 9-nov-07

Welcome to the latest edition of the Carnival of the Agilists, the blogroll that skims the cream from the top of the agile blogsphere. This week’s theme is: a bumper bag of liquorice allsorts

Brian Marick has posted the transcript of his OOPSLA talk in several parts. Part 3 discusses Pasteur’s attempts to educate the French about the causes of anthrax, and relates that to a fun idea for energizing daily stand-up meetings: “another example of using a weirdo theory from sociologists to give myself ideas.” Meanwhile Mark Levison has revived his team’s iteration boundaries by introducing good agendas: “By breaking things down into smaller more focused chunks the new agenda (and prompting questions) has made our retrospectives more valuable”. Dale Emery also chips in on the subject of efficiency, with a great discussion of the causes of multitasking: “If I split my time among all six tasks, I get to tell all six people every day that I’m making progress on their important tasks. And I get to be sincere about that”. (I have no idea why this post appeared in my RSS reader this week, as it was written over two years ago. Still, it fits here and its still very relevant today; think of it as this Carnival’s “Two Years Ago This Week” entry…)

Both Mark Levison and Dave Rooney discuss the downsides of working remotely from the team. And while Mark (and his commenters) provides a list of tools and techniques to help improve communications, Dave’s top tip is: “Remind your significant other that hay and shavings from the rabbit’s cage shouldn’t be washed down the drain in the laundry room.”. Now why didn’t that practice make it into the white book?

Rebecca Wirfs-Brock reports on the findings of a workshop that discussed Challenges When Communicating Designs: “I started by making the connection between telling others about designs and storytelling. Effective designers need to tell good stories. And the tone and means by which we communicate design ideas should vary depending on the reasons we have for telling a particular story, and our audience’s background and expectations”. Now I think about it, the great developers I’ve worked with are all great story-tellers too; Rebecca’s discussion suggests that’s no coincidence.

Michael Feathers’ latest addition to the Beautiful Code blog is a post entitled Elegant Byte Counting, which centres on the use of the SpecialCase pattern to solve a tricky little code duplication problem: “This is a particularly elegant way of handling things. Rather than having separate code to traverse writable things for size and write, all of the work can be done with the same piece of code, the write method. There’s less duplication and less possibility of error in maintenance.” There are nowhere near enough of these great little design vignettes around, in my opinion.

After the summer-long debates about certification of various sorts, Willem van den Ende has discovered that you’ll make more money if you are not certified. He quotes Mark Gallaher thus: “A new report from industry research firm Foote Partners LLC finds that the average pay for noncertified IT skills topped that for certified professionals […]”. Less is more, it seems.

And finally…

The calls-for-participation have been published for both Agile 2008 and Scotland on Rails. Give them a look and submit a few sessions — I know I will!

To suggest items for a future carnival – especially from a blog we haven’t featured before – email us at agilists.carnival@gmail.com. As ever, this and all previous editions of the Carnival are catalogued at the Agile Alliance website. Look out for the next edition of the Carnival around the end of November, hosted by Pete Behrens.

more on performance metrics

Since I opened this particular can of worms a couple of weeks ago, the power of intention-manifestation has brought these related blogs posts into view:

Do you know of any more discussion, research or case studies into measuring the performance of managers, coaches or businesses?

managing an improvement exercise

In these last few posts I’ve been trying to edge towards a deeper undestanding of what agile coaches do. These are thought experiments. My aim is to be able to give our clients a means to assess when and whether they are deriving value from the use of our services. And I believe that this will also give us greater means to implement successful improvements in the effectiveness of the software teams we meet.

Several times, both very recently and in the dim past, I’ve seen folks advocate running software process improvement exercises as if they were agile projects. What would that be like in practice? I imagine we would identify process changes we wish to make, creating a story card for each. There’d be a daily stand-up meeting, at which the change team discusses progress, obstacles and plans. There’d be iteration reviews and planning games, and a backlog of change stories, and the change team would chart the project’s velocity, presumably in some kind of “change points”.

bonsai What would that change project’s backlog look like? Well if we’re in the business of implementing change to a recipe, I guess it might have a series of stories, each of which puts in place a specific brick of the whole edifice. Sounds like we know where we’re heading already. We’re in danger of turning the software team into a local optimum within the organisation as a whole. We may even shift the bottleneck away from development altogether. Then what?

But if we’re in the business of improving effectiveness there will be no backlog. There can be no backlog. Each change (possibly a small suite of changes) will have been worked out as a response to the overall organisation’s current greatest need. By asking “where’s the bottleneck?”, “where’s the current constraint on throughput?”, “what is the common root cause of our major incidents?”

And after we’ve implemented this change, what next? We must measure, observe, inspect. We must let it settle in and then measure our new levels of throughput and expense. Then ask the questions again – looking for where the bottleneck has moved to now. This is hansei-kaizen, an endless cycle of inspect-adapt-inspect-adapt, as Scrum puts it. And at each cycle it is the overall organisation’s Goal pulling each change through the system.

Now, what about the individual change “stories”, what will they look like? Will each have acceptance tests? Can we assign each a monetary value? Questions for another day…

let the goal pull change through the organisation

What’s the Right Way™ to carry out an agile transformation? Indeed, is an agile transformation always the Right Thing to do?

On the one hand, an agile coach may be hired to “implement” Scrum or XP, because that’s the way the organisation has decided to go. Alternatively, one may be engaged to help improve an organisation’s productivity, say, without regard to whether the resulting system behaviours will be recognisable as this or that agile method.

In the domain of lean manufacturing, productivity improvement itself can – and indeed must – be seen as a pull activity:

“Taiichi Ohno remarked that TPS is very much like the scientific method of experimentation. When this is not kept in mind, the result is “push” style Lean (Do as you are told), rather than “pull” Lean implementation (What is the biggest problem?)”

This is a very clear answer. “Lean” is the name given after the fact to a very effective type of system that was “grown” piecemeal by kaizen – continuous gradual change. magnet (Ohno states elsewhere that all of the key aspects of the Toyota Production System arose individually as solutions to the root cause of some specific incident.) Lean was not the goal, it is simply a name for the resulting shape of the organisation.

Similarly in software development, we must not let the “agile” banner get in the way of our goal, which is the creation of an effective software department. The body of agile knowledge is invaluable as a source of ideas and experience when we are faced with effectiveness problems to solve. But it must not be used dogmatically. “Extreme at all costs” may well be better than we were before, but without the pull from the overall system’s Goal it is unlikely to be sustainable in the long term.

What interests me is effective software development; that is, software departments that contribute to the overall organisation’s Goal of present and future profitability. Such effectiveness must be achieved gradually, by repeatedly resolving the root cause of the biggest problem. The Goal will pull changes through the system, if we let it.