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)?

“Stand in the circle”

While catching up on my reading of lean blogs today I stumbled on a post by Jon Miller at Gemba Panta Rei, called Give Me 60 Minutes and I’ll Give You a Lean Transformation, in which Jon describes a very simple — and quite theatrical — means of driving improvement:

“This exercise starts with picking a spot in your gemba and standing in that one place for 30 minutes. Find 30 things to improve in 30 minutes. Write them down. Take the next 30 minutes and make at least one of the improvements you wrote down.”

5278916281_6e11555f1f_b

Cornell University Library

Taiichi Ohno, the architect of lean manufacturing in Toyota, would teach his staff how to see waste by telling them to “Draw a circle and stand in it!” Could that work in a software development organisation?

First, I would note that a software development organisation doesn’t consist solely of programmers at work – all of the usual office activities will also be happening too. The developers may not be the bottleneck, and standing in various different spots around the organisation will thus likely bring different parts of the overall value stream into view.

Second, and as the commenters on Jon’s post point out, a lot of what goes on in an office is “invisible” because it is conducted in the virtual workplace “inside” computers. This is doubly true of software development. But as Jon suggests, the list of 30 problems could include the fact that status or progress aren’t visible, and from there its only a small step to the introduction of things like burndown charts or traffic lights for the build.

So I think the approach is feasible from a purely practical point of view; but what of the psychological / cultural angle? How might a roomful of developers react to someone with a clipboard watching them for 30 minutes every couple of weeks? I feel the person standing in the circle must have the team’s permission to be there – perhaps being a member of the team, one of the developers, most of the time. There’s no harm in the team asking someone else to do the job occasionally, to provide a fresh look and see things the team might miss themselves. But the idea that improvements can be imposed, or that one’s performance and behaviour are being monitored, is anathema. The team must decide it wants to improve, and must decide to adopt the lean kaizen approach; then the team can “appoint” one or more observers to help it find waste in the team’s activities.

On balance I think “standing in the circle” is worth a try, given sufficient introductory training to ensure that appropriate permission is granted by everyone. I’m interested to find out what kind of things appear on the list – particularly after a few weeks of running the technique. Please let me know what happens when you try it!

blame

This week I’ve come across a few articles that clicked together as I read them, and in so doing they reinforced one of my deepest beliefs about software development – or any other profession, for that matter. The articles were:

  • Train Wreck Management by Mary Poppendieck, in which Mary chronicles the origins of “management” and “accountability”. It seems that hierarchical management structures were first applied in the mistaken belief that it was one person’s dereliction that caused a train crash, and that in future such things could be prevented by management and accountability. Lean thinking says the opposite – that the train crash was an inevitable consequence of the structure of the system, and that specific individuals should not be blamed.
  • Survey Blames Blame for Lean Struggles by Mark Graban, in which Mark notices that a recent survey seems to indicate that employees blame each other for their business failing to adopt lean thinking. Mark’s subsequent analysis of the survey shows, however, that it seems to lead the participants to ask “who is responsible for…?” – so it should be no surprise that the top answers mostly involve job titles! Mark’s response is to design a new survey in “5-whys” style – an effort I applaud, even though I disliked the example embedded in the survey.
  • Risk Aversity by Henrik MÃ¥rtensson, in which Henrik uses the Theory of Constraints thinking tools to dig into why many organisations are immune to change. One of the root causes, according to Henrik, is that “mistakes” are punished in the average workplace – and so after a while everyone becomes afraid to innovate, or even to change the status quo. A truly lean organisation will reward even the person who makes a change that leads to lower throughput, because at least they contributed, and knowledge about the whole system has been improved as a result. But even the use of the word “mistake” shows how deep-seated is our culture’s desire to blame, and hence to discourage.
  • The Secret Sauce of Highly Productive Software Development by Amr Elssamadisy and Deb Hartmann, in which the authors propose that inability to learn is the bottleneck (in the Goldratt / TOC sense) in most software teams. I need to think about their “bottleneck” claim, but I do agree that learning is the key to agile success, and that a learning organisation will out-perform any other in the longer term.
  • The QnEK Horse has left the Barn by Hal Macomber, in which Hal opens the lid on a community for sharing QnEK (Quick-n-Easy Kaizen) ideas. QnEK can only succeed in an organisation where “mistakes” don’t exist, where blame is replaced by systemic learning.

For me, these articles all dovetail:

  • learning is the key to long-term success
  • the system can always be improved
  • systemic learning requires a constant flow of improvement suggestions
  • blame discourages innovation

It seems clear to me that blame itself lies at the root of many organisations’ problems. The system can always be improved, and is always the source of problems. People should be rewarded for discovering those problems and trying to fix them, especially when they “only” create new knowledge about how to perform less well.

carnival of the agilists, 3-may-07

When it comes to agile software development my preference swings heavily towards the influence of lean. The two central principles of lean are eliminate waste and respect people – although the second of these seems to be too often forgotten in the stories we read of lean (manufacturing) transitions. The agile movement (I hesitate to use that word in the present climate) has a strong tradition of demanding respect for people, arising from the manifesto’s exhortation to value individuals and interactions over processes and tools. And as I sifted through the agile blogosphere again this week I found that tradition very much to the fore. So this week’s carnival is a single-topic issue, bringing together a smattering of your thoughts on “individuals and interactions”…

To get us in the mood, in Respect People Alan Shalloway brings together a few pithy quotes, while in Individuals and interactions over processes and tools Simon Baker attempts to unpick what that particular plank of the agile manifesto means in practice. Dave Nicolette asks Is agile’s greatest strength also its most significant risk factor? and suggests that emphsising people over process is both liberating and risky.

The openness of agility is forcing us to (re-)discover some of the deeper foundations of effective communication. One of these is trust, and in I Told You So Ed Gibbs discovers one of the side-effects of not being trusted. (Trust has also turned out to be the theme of Clarke Ching’s Rolling Rocks Downhill book, which he would like you to help him rename.) And in Attachment Employment Jack Vinson points out that knowledge management initiatives will yield poor results when the workforce doesn’t trust it’s employer.

Speaking of knowledge management, in Osmotic communication – keeping the whole company in touch Tom Scott discusses the idea of using IRC (Internet Relay Chat) to promote information flow throughout a company, and specifically to provide a live commentary on what’s happening to version-controlled resources. A fascinating thought experiment, and I’m very interested to hear from any group who try it.

When it comes to working together, Jeremy Miller finds many ways in which Self Organizing Teams are Superior to Command n’ Control Teams (although some of his readers appear to disagree). And Jon Miller at Gemba Panta Rei discusses how to use Skill Matrices as a key part of the knowledge management in a lean organisation.

And finally, after all that reading, something completely different. Why not try simulating variation in task estimates, as suggested by Clarke Ching? Try it a couple of times, then imagine that Heads equates to getting good luck on a task (so it finishes early) and Tails equates to getting bad luck (so the task finishes late). What does the simulation say about plans and planning?

If you have something that you want to see in a future carnival – especially from a blog we haven’t featured before – email us at agilists.carnival@gmail.com. All previous editions of the Carnival are referenced at the Agile Alliance website. The next carnival is due to appear around May 17, hosted by Pete Behrens.

one size fits none

Dave Nicolette tells what happened when Jon Kern (one of the originators of the Agile Manifesto) gave a talk on agile development to the managers in a large corporation’s IT department.

“Jon knows his stuff, and the content of his presentation was right on the mark. But I got the distinct impression he is unaccustomed to dealing with an ignorant, hostile audience. He answered their questions in a way that suggested he had overestimated their knowledge of the underlying concepts. His answers would have been appropriate for an audience that already had a general idea what agile methods were about, and who were looking for a little more information. Instead, he had an audience who would rather stick their fingers in their ears and chant “La, la, la!” than to be confronted with the possibility that Firesign Theatre had been right all along.

Dave doesn’t say what forces brought Jon into his workplace, and I’m guessing when I say it has all the hallmarks of management preaching. Does it do any good? I don’t know. In every situation like this (I’m guilty of having done it myself) there will be those among the audience who are ready to hear the message, and for whom this is exactly the spur they need to jump in with both feet. And there will also be those who are antagonistic to the idea, and who entrench themselves even more after such an exercise. excluded Mary Poppendieck suggests that the nay-sayers should be disenfranchised, pushed out into the corridor while the rest get on with whole-hearted enthusiatic agile adoption. Presumably because that’s the cheapest option in both the long and short term. These lost souls will then either leave (she hopes) or try to change things back, or snipe and spit from the sidelines. Only the first of these presents a win-win opportunity, but surely it doesn’t have to be done that way? Is it just possible that those folks actually have something valuable to contribute as the organisation moves forward? Or is the cost of including them too high, when everyone else just wants to get on with it. Include or exclude, the result will depend on the individual. And those around them. What forces created an organisation whose strategy is heading one way (towards agility) while some of its staff actively oppose that strategy? Was someone being less than authentic when the hiring was done? Or has someone in a leadership position learned something that ultimately will require a different workforce? Useful to know the difference when attempting to instigate change…

what’s wrong with corporate culture?

Through various sources this week I’ve learned about Pam Slim’s great blog Escape from Cubicle Nation. Last week she posted her Open letter to CEOs, COOs, CIOs and CFOs across the corporate world, which has received a great deal of deserved attention. I thoroughly recommend this passionate rant from the heart – here’s a taster:

“Corporate culture is a natural thing that cannot be manufactured. No amount of posters, incentive programs, PowerPoint presentations or slogans on websites will affect the hearts and minds of your employees. If you want to see things change immediately, stop acting like an asshole.”

I’ve worked in several organisations of the kind Pam rails against, and been fired from most of them. I’ve posted some of my most poignant experiences here, here and here. And the scary thing is, it isn’t just the big corporates that foster this kind of culture. Small companies can be just as bad. Maybe the CxOs copy the style from books? Or maybe it takes a macho bullshitter to get into those kind of jobs? Or maybe the job creates the person? I can’t fathom the cause, but it sure ain’t pleasant for the rest of us. More power to your elbow, Pam!

a week isn’t long to wait

A very important part of the process of incremental delivery is the weekly commitment. Each week the product owner and the development team should agree on an increment of value. The development team will commit to delivering that value, and the whole organisation should respect that commitment.

So if anyone wants the team to do something different – a few hours’ support, or an urgent feature for a desperate customer – they must expect the team to say ‘no’. Because the team has promised the product owner that it will spend its time delivering the agreed value.

The time to choose what the team does is at the weekly planning. Or preferably before the weekly planning, in conversation with the product owner. If you anticipate support interrupts, get them allocated into that week’s increment. And if you failed to anticipate them, find a way to let the team deliver on its commitment anyway. After all, on average you’ll only have a couple of days to wait.

The way to influence how the team spends its time is to influence the product owner. To directly ask the team to do something that isn’t in the increment is to fail to respect their commitment to the product owner. No-one performs well when asked to steer in two different directions at the same time, and no-one should be asked to decide where their loyalties lie. Agile software methods all place the product owner at the gateway between the team and any parties who may wish to use their time. Entering the team’s room via the back door breaks the fundamental structure of the agile process, and will likely lead to confusion, disaffection, loss of morale and loss of productivity. And all for the sake of a couple of days…