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, 19-jul-07

The latest edition of the Carnival is brought to you by Pete Behrens, with a distinctively “management” flavour. And having myself been called an Agile Nazi – and worse – I gained some support from the posts I had missed first time around, particularly Julie Brooks’ Who Coaches the Coach?.

The next Carnival is due in the first week of August; subscribe to this blog or a search feed to be notified of future Carnivals of the Agilists.

how to start organic change

Through bitter experience I’ve come to recognise that change works best when it isn’t imposed, and when it is allowed to occur over a period of time. So when you or I recognise that an organisation’s performance is below par, how are we supposed to get it to change. These days I try to foster change, rather than to impose it. Here are some great ways to start the ball rolling:

Current Reality Tree (CRT)
This is a great way to bring the whole organisation together in recognising and understanding current problems and the links between them. Develop a CRT together as a group to understand the very small number of root causes that lie behind today’s poor performance. Hopefully at the end of the process the whole group will feel they “own” those root causes, and everyone will be motivated to seek and implement solutions.
Simulations
Help everyone gain some experience they wouldn’t otherwise get, by running simulations. These “games” can show some specific aspect of current or future life, but isolated from the other daily crud and also speeded up. Games give the participants rapid feedback on decisions such as they make every day, and insights into their impact on other aspects of their organisation. These insights often “click” some days later (link via Keith Ray), causing folks to spontaneously begin instigating change themselves.
Hansei-kaizen
Run frequent (eg. weekly) retrospectives, and encourage participants to take ownership of the problems they observed in the previous week. Create a culture in which the “way we do things here” gradually evolves, and in which everyone sees this evolution as natural.

I’ve worked almost exclusively with the last of these, usually preceded by some root-cause analysis using CRTs. I’ll definitely be adding more simulations to the mix in future. Do you have more techniques to add to this list? And how do you mix them when asked to initiate an agile transition?

force fields of attraction

How do you introduce yourself? by Pam Slim is all about walking the talk – modifying our language to reflect our ambitions instead of our fears. I suppose this is related to NLP, and I can vouch for the fact that it does make a difference when I can present myself in terms of where I want to be, rather than where I fear I’ll end up.

That said, the reason I’m writing this is because of an almost throw-away line towards the end of Pam’s piece:

“A Buddhist friend once told me that the words that you say form a force field of attraction around you.”

ghandi This strikes me as true in so many ways. The actual choice of words we use matters so much, and reveals so much about our preferences, beliefs, prejudices, fears and so on. And the congruence – or lack of it – between those words and our actions is often a great barometer of our authenticity.

A few times in my career I’ve been asked by colleagues how it is that organisations have tended to adopt values or approaches I hold dear. I answered that I just talk about stuff sufficiently often that it becomes part of the meme soup of my working locality. That’s the attraction field, and I think it only forms when the congruence is there too. There have also been a few occasions when the force field hasn’t materialised, and in each case I was trying to force something without being it. As Ghandi said:

“Be the change you wish to see”

(Thanks to Nynke Fokma for reminding me of that quotation, and to the force field that brought both of these statements into my browser today.)

yet more on metrics for coaching

A month ago I began asking whether it was possible, meaningful or sensible to measure the performance of an agile coach. Herewith a couple of further thoughts on that topic.

vernier Firstly, there’s been some discussion of metrics over on the scrumdevelopment Yahoo group. The original question posed to the group was:

“What metrics do I collect that tell me this agile stuff is actually doing my group any good”

Mary Poppendieck weighed in with three metrics that should be taken together as a package:

  1. cycle time;
  2. business case realisation;
  3. and net promoter score.

Her post goes on to describe these measures in detail, and why they are important. They do seem spot on to me – though I’ve only tried the first for real, and even then with only limited success. It seems to me that there’s a strong case for measuring the coach according to the results of the organisation being coached, and these look to be measures I’d be willing to adopt for myself. But then…

Secondly, I have now finished Value-based Fees: How to Charge and Get What You’re Worth by Alan Weiss, as recommended by Deb. While not about coaching per se, the book does make recommendations as to how a consultant should establish performance measures with his or her clients. Weiss divides measures into quantitative and qualitative. Regarding the former:

“[Y]ou cannot base your contribution on what I call a ‘magic number’. While a 6 percent sales increase might be highly desirable and even, in your opinion, very achievable, it’s never a good idea to peg your success to that magic number. The reason is that there are far too many variables that can affect that number adversely for you to take that risk. […] It is better to state that you will assist in maximising the sales increase.”

And regarding qualitative measures:

“Qualitative measures can be among the most powerful [but] “I’ll know it when I see it” […] is insufficient for a consulting project. In fact, here are the parameters for creating a successful, anecdotal sereies of measures for a project: the buyer himself or herself will judge the result; the effectiveness will rely on observed behaviour and factual evidence; there will be gradations of success, not success or failure; there must be reasonable time limits.”

Weiss goes on to give examples that are very much like the kind of anecdotal measures I’ve been using on my own projects. So now I’m back to where I started! On reflection, I think that’s just fine. Start with something like:

  1. assist in minimising cycle time;
  2. assist in maximising business case realisation;
  3. and assist in maximising net promoter score

and then augment those with any other anecdotal measures that are valuable to the team, manager or organisation I’m working with.

What measures do you use to assess your own performance at work?

process improvement metrics – some questions

Software process improvement is all very well, but how do we know whether it is working?

The topic of measuring the effectiveness of process improvement activities has crossed my path several times in recent days. For example my current client and I are trying to define ways to measure the benefits to their organisation of retaining me. And then there was the designing metrics session at SPA2006; in their handout notes, Jason and Duncan suggest that process improvement be run as an agile project, with its own stories, velocity etc. Not to mention a conversation I had with Deb Hartmann on the same topic; seems she wants to measure – or at least chart – her coaching activities.

blindfold I’ve found almost nothing written about this topic, so at present I’m afraid I have only questions. First though, some basic assumptions. I assume that software process improvement in itself is pointless. As I said earlier this week, the term “process” doesn’t capture enough of the behaviour of a system to be useful. And of course “improvement” is a relative term. Improvement compared to what? And towards which goal(s)? According to Goldratt there’s only one Goal: maximising profits in both the present and the future. I will assume, then, that software development is always carried out with that goal in mind: the software either reduces our own organisation’s costs or increases our sales, or is designed to be sold to other organisations so that they can use it for one of those ends. Either way, the process of producing that software is only a fraction of the whole system, and may contribute a large or small amount to how well we’re working towards our organisation’s Goal. Furthermore, improving the software development department in isolation may prove beneficial initially, but could be creating a local optimum at the expense of another part of the system, or could simply not be worth doing, if other parts of the system are contributing more to poor overall performance.

All of that notwithstanding, there will be times when an organisation must turn its attention to improving the software development department. Software development will inevitably be the system’s primary bottleneck some of the time, and so its contribution to the goal will need to be addressed. But depending on context the “improvement” required may involve improving quality, reducing time to market, improving customer service, ensuring the right software is developed, training people, or any number of other things. That is, the day-to-day dynamics of the overall system’s push towards the Goal will create short- and medium-term demands on software development; and the response from software development must be measured in terms of those demands.

Henceforward, I’m going to use the woolly term effectiveness as a shorthand for the software department’s contribution to the overall system Goal. Improving the department’s effectiveness then equates to reducing costs and/or increasing sales in the overall system. And instead of talking about “software process improvement”, I’ll discuss “software department effectiveness” instead.

So, back to the top. How can we measure the performance of a software coach? As yet I have no answer; instead I’ll ask a few more related questions:

  1. If we hire a coach or process facilitator or scrum master, how will we know whether we’re getting value for money? Unless the coach doesn’t charge, the organisation’s Operating Expense has increased, so should we be looking for a corresponding increase in sales?
  2. Should a software coach charge a percentage of their client’s increase in profits? Now and in the future?
  3. How often is it possible to attribute improved profitability to the actions of a software coach?
  4. What if the service constitutes training – how can that be directly accounted to profitability?
  5. Given that increased profitability may be measuable only after a period of time has elapsed, how should the risk be apportioned (between client and coach) during that interval?
  6. Conversely, how risky is it to define local measures purely on the software department?
  7. Imagine an ineffective organisation whose biggest problem is not within the software development sub-system. But suppose nevertheless that the organisation blindly hires an agile coach to improve the software department’s effectiveness. Is it meaningful to talk about “improvements” when the real problem is elsewhere? Can the changes be measured in any meaningful way?
  8. Assume that one of the objectives of a coach is to transfer sufficient knowledge so that the client organisation can ultimately continue alone. How can we chart progress towards that goal?

I can find no answers in the lean manufacturing literature (assuming lean sensei charge for their services), or in the agile domain. I suspect that we as an industry just don’t know (yet). Deb suggests we may need a few OpenSpace discussions to work out the answers – or even to establish some direction – and I concur. If you know of any resources, or if you wish to participate in getting these discussions going, please drop me a line.