So let me offer an analogy: imagine someone wanted you to [...]]]> One of the things I struggle with as a coach is convincing companies of the necessity for coaching. Part of this I guess is the self-interest involved. Mainly however, it lies in my seeming inability to articulate why training on its own is not enough.

So let me offer an analogy: imagine someone wanted you to teach them to play chess and win at it. To do this they want to know (and as a result, for you to teach them) what the best move is for every situation.

Now clearly, this is a ridiculous request.

Instead what you do, is first teach them the rules. And then teach them (usually by playing a few games) how to recognise good moves; moves which advance their position strategically. In other words, once they understand the rules, you teach them the principles of good chess.

How much more complex is software development, this "co-operative game"? It requires complex interacting agents to exchange information to produce an unknown (perhaps even unknowable) outcome?

How much more difficult would it be to identify (in advance no less) what all the possible moves are and figure out which one is the "best" one? And to do this without knowing what the complex environment and nature of the team and its constituent members are?

All we’re trying to do in the initial training for teams is establish the rules: e.g. stand ups are for the team, the Product Owner collaborates with the team to establish the priority of work etc. etc. Everyone needs a basic understanding of the framework, so they can play the game.

The problem is that in communicating this essential requirement, companies fixate on the training as an end in itself, rather than the beginning of a learning process. And my personal weakness is that I find it difficult to communicate the importance of values as the key factor in an Agile transformation, particularly in a sales meeting.

So I guess in the spirit of "inspect and adapt", next time I’ll try out my analogical argument.

Powered by Qumana

I have been a loyal customer of MTN for the past 8 years or so. I have been as close to a model customer [...]]]> So I’d like to divert from my usual blatherings to something closer to home. I’d like to describe a recent epic user experience fail on the part of my telecoms service provider.

I have been a loyal customer of MTN for the past 8 years or so. I have been as close to a model customer as it is likely to get. I have never missed a payment and since the contract structure I have is ‘Weekend Minutes’, and I never use close to all of them, I usually end up spending at least some money on prime time calls.  Since voice is the main thing for me, and with all the interconnect revenues they generate from that, I’m guessing that I have been responsible for about R24,000 worth of revenue at a pretty decent margin over the lifetime of my account to date.

I’m also a pretty easy customer. I rarely phone the call center and I prefer to deal via the web, so in the past I have used MTN Direct as my service provider for new contracts etc.

So I’ve recently run out of contract and have wanted to renew. So my first port of call has been the MTN website.

I entered my details for a contract upgrade and after 2 weeks had not yet been contacted by a service agent. So here I am, wanting to renew my contractual relationship with a provider who apprently is not interested in reciprocating.

Doggedly, I continued to pursue this like some love-sick puppy.

Every few days for the next three weeks I have tried to access the site at: http://www.mtnsp.co.za been greeted by the image below:

So foolish as I am, I just assumed that it really was down. Even for this extended period.

Until I received an email from MTN with my statement, which mentioned a ‘Summer Sale’. Clicking on that took me to the site in some weird aspx level. So clearly, when some maintenance was done to the site, nobody bothered to redirect the landing page to the correct aspx landing page. And since this has been going on for more than three weeks now (and yes, this screenshot was taken a few minutes ago), it mens nobody has bothered to check why their site stats are down. Their bounce rate must be 100%!

But now I have managed to get to the two pieces of information I am looking for: the handset and telephone number I need to call to arrange my contract. This part is fairly smooth, I get an email with the forms in PDF format, but I can’t edit them. So I have to print them, write all my details in my inelegant scrawl in a space too small to actually accommodate the info, scan and email back.

No acknowledgement of receipt follows. Unless you count the spam joke email I received the CSR who I exchanged email with, telling me to ‘Hang in there, it’s nearly Xmas!’

I had been told by the CSR that the phone could take about a week to reach me.

What frankly fascinates me is that I went through this exact process about four years ago with much less trouble and delay to receive the phone.

So three days pass. I receive two missed calls from a number I do not recognise. They leave no message.

This morning at 6:45 AM my mobile rings. I stumble out of bed, grab the phone from my wife’s hand and listen to someone mumbling at me. He’s asking me ‘How I am’. I am too stunned to really do anything other than blurt ‘It’s very early in the morning!’ To which he replies that he has a delivery of a cell phone for me, that he had tried to phone me yesterday and couldn’t get  through, and where in Johannesburg was I, so he could deliver the phone.

This is such a monumental screw up in customer experience that it leaves me literally stunned. I reply that I am in fact in Cape Town. What he said next I could not decipher and then he hung up.

Now, MTN is a company in crisis. And maybe, as a result, I should feel bad about taking my business elsewhere. But frankly, while I feel terrible for those people who will be losing their jobs perhaps some companies don’t deserve to live. It is clear to me that if the people responsible for managing this beleaguered organisation spent a little time trying to figure out how to create a remarkable customer experience, rather than chasing cost cutting measures, they might be able to save their business.

And let me be clear; I don’t blame any of the people I have dealt with thus far for the terrible customer experience (crap website, poor email protocol, phoning me while I am still asleep). The poor guy who doesn’t know I am in Cape Town and whose been told he has to get hold of me is likely some poor schlub who works for near minimum wage. He is more than likely doing what he has been told to do.

I blame PF Nhleko for creating a culture of mediocrity where this kind of crap is allowed to happen at all.

So cheers MTN; it wasn’t worth the pain of keeping the relationship going.

]]> http://carlokruger.com/?feed=rss2&p=107 4 http://carlokruger.com/?p=104 http://carlokruger.com/?p=104#comments Sun, 15 Nov 2009 14:18:55 +0000 admin http://carlokruger.com/?p=104 As I coach more and more teams, I notice a pattern. Scrum masters who fear (or loath) conflict try to resolve discrepancies in estimates as quickly as possible. They will try to force a majority vote as consensus. Or worse, place the dissenter on the spot, somehow implying that they are holding the process up.

This [...]]]> As I coach more and more teams, I notice a pattern. Scrum masters who fear (or loath) conflict try to resolve discrepancies in estimates as quickly as possible. They will try to force a majority vote as consensus. Or worse, place the dissenter on the spot, somehow implying that they are holding the process up.

This creates a dangerous dynamic within the team. Conflict is seen as bad and to be avoided. The way to recognise this is when you hear a statement like: “I guess I could go down to a three”. The scrum master is missing the purpose of the meeting. The team is there to gain a common understanding of the work. When a team member capitulates, they’re robbing the team of an opportunity to really understand something. It makes the team as a whole, less effective.

It also makes the estimation meeting less representative of the team’s understanding, and as a result team members begin to see less value in it, resulting in greater skepticism in the process of estimation. Which sets up a vicious little circle.

The underlying problem here is the notion that dissension is a zero sum game. The notion that an argument has a winner and a loser means that people will sometimes refuse to participate. The culture we should be trying to create is that of strong opinions, weakly held. Argue until you’ve been convinced otherwise. Then gracefully move on to the next topic/item.

The scrum master’s role is to fascilitate the discussion, to make sure that it remains a robust discussion about the issue. More importantly, the scrum master should be coaching the team in why the estimation meeting is important and how to best use the time in those meetings. This comes down to understanding the principles and not executing a set of rote ceremonies.

used with permission: http://www.flickr.com/photos/kylemay/

Technology is nothing but tools. When you consider that the people who are usually most passionate about technology are the ones in the agile camp, the proliferation [...]]]> As a life long fan of technology and one privelaged to work within a high tech industry, it’s easy to get distracted by the shiny…

used with permission: http://www.flickr.com/photos/kylemay/

Technology is nothing but tools. When you consider that the people who are usually most passionate about technology are the ones in the agile camp, the proliferation of agile tools in the market place has a sense of inevitability.

It is also the most common mistake we make as practioners, certainly when we start down this agile road. Agile = Cool so we want all the shiny cool new tools. Preferably one written in Ruby (or Python or Haskell). With many rounded corners and buzzword compliance.

I think the reason why we fall into this trap, why we find it so compelling is because we’re technologists. At our core, we believe that given the right tools we can change anything for the better. This unflagging optimism is why I read too much sci-fi. On my first real scrum job, I immediately went straight for the throat and tried to find the right tool to get this scrum stuff embedded into our development process ASAP. I believed that the tool would help us ‘do it right’. Turns out there is a word for this belief: Technicism

And I got it precisely wrong.

Agile adoption is a change process, and change is hard. We all too easily use technology to hide from change. My problem with most electronic scrum tools I’ve seen, is that it is all too easy to use them to hide the valuable stuff that help us to manage the change. (Maybe if we had the technology where all our walls were display screens that were also touch-sensitive it might be different.)

Change is also about humans. People. We’re complicated beasts and slow to change. So the best thing to use to bring that change about is the base instincts. For example, we’re social creatures. That means that the most important influences on our behaviour can be found in our peers. This is a function of our evolutionary history. So use the peer pressure to help drive behaviour. A visible example of this is the daily stand up.

In a recent conversation with a much wiser man than myself, Peter offered the not entirely surprising insight that most agile teams which move from a physical (cards, sticky notes, scrum boards) to an electronic one, usually go back to the physical. I believe that there is a sinister conspiracy at work: Scrum is in fact a 3M marketing ploy. The insight that I get from this is one that is easily lost in a cubicle farm. Making software is a social activity, and the technology we use to communicate is a poor analogue for our evolved communication patterns. Alistair Cockburn has a graph which illustrates this wonderously. In fact go read his talk while you’re at it.

So what I have learned is that this agile stuff, works a whole lot better when I step away from my identity as a tool user / maker. In fact I get a warm fuzzy feeling whenever I see my team in front of our scrum board…

The woman I admire happens to be my wife, Karen Greaves.

She has been my mentor and inspiration. She has made a reputation for herself as a superb boss (although I hesitate to allow her to be my [...]]]> I promised to write a post about a woman in IT whom I admire as part of this campaign.

The woman I admire happens to be my wife, Karen Greaves.

She has been my mentor and inspiration. She has made a reputation for herself as a superb boss (although I hesitate to allow her to be my boss, at work). Her people are fiercely loyal and she is loyal to them.

She comes from a technical background, having worked for Microsoft. I think she enjoys shocking developers by understanding their technical challenges and being able to suggest solutions. But it was really in product and project management that she discovered her true calling.

She has long been a supporter of agile methods, and has worked passionately to make it part of the environment where she has worked. I learn every day from her experiences with scrum in her environment.

For me, she has been an inspiration for how I would like to be, and perhaps a large part of the reason that I got into this business.

So today,  I salute her accomplishments in the software world, but I didn’t actually need a special day to do that.

http://scrumorlando09.pbwiki.com/browse/#view=ViewFolder&param=Orlando

Presentations are also being published to the Scrum Alliance site at:

http://www.scrumalliance.org/resources?tag=SG+Spring+2009

What it feels like is that scrum has reached a level of acceptance and recognition that it has now become mainstream enough to warrant the kinds of attacks that can build your [...]]]> There has been some vigorous discourse about the state of scrum in the past few months. I’m not going to refer to them specifically.

What it feels like is that scrum has reached a level of acceptance and recognition that it has now become mainstream enough to warrant the kinds of attacks that can build your reputation. Everyone loves the little guy; this is why it is useful to frame arguments as a battle between the little guy and the big guy. The insight to take away from this is that rising to the bait will only encourage more baiting. There is no right way to do this.

At the moment I feel a bit like scrum’s bulldog.

I think Martin Fowler probably has the right insight. The baiting, criticisms and misunderstandings will be an inevitable aspect of the growth of scrum. what we as a community need to do is emphasise the technical aspects of a scrum implementation that will ensure success.

Nothing succeeds like success; which means that in order to be successful, we need to do more with regard to practices like continuous integration, automated regression testing and test driven development and refactoring (especially in the architecture area).

The one area where I will usually reply to percieved criticisms is where I think it is founded on a misunderstanding of a practise or role.

I’ve taken the liberty of turning it into a very basic [...]]]> I’ve published a little TEST for those of you brave enough to find out what level of scrum you’ve implemented. It is based on Jeff Sutherland’s presentation on ‘Money for Nothing, Change for free’. In it he describes an updated version of the Nokia Test.

I’ve taken the liberty of turning it into a very basic quiz running on googledocs. (Please let me know if you experience any issues with taking the test, I’ve tested it but you never know)

I suspect that even this test is still too basic, it does give you a somewhat better feel of whether you’re doing scrumbutt or better. I found it useful as a focus for a review session. It draws attention to the basic practices that you should have in place. And until those basics are in place, you don’t really begin to feel the full benefits of what scrum has to offer. Jeff puts up some empirical evidence in his presentation that suggests that an excellent scrum implementation can make a difference of 400% in your productivity as a team (however that is measured).

You owe it to yourself and your team to make sure those things are there, and if they’re not figuring out a way to get them there.