Clarke Ching's Rocks and Snowballs

confidence and visiblity

People don’t have confidence if they don’t have visibility.

I’ve just recruited 9 temps to work on our data cleansing project.  One of them, John, has recently finished an IT degree so I asked him if he would work on what I call our “data engine”.  At it’s simplest this involves running queries against an Oracle database using Microsoft access and Excel, but in the longer term he will need to rewrite a rickety system that I’d hobbled together to automatically identify dirty data and to catch when other parts of the organization have dirtied data that we have previously cleaned.

I’ve done lots of this sort of stuff before so it is easy for me, but John had no experience with any of the technologies I was asking him to use. 

So, I asked John to do a couple of tasks that would be easy for me but would be harder for him.  I made it clear that I was throwing him in the deep end and that I expected it to take him a few days, but that I wanted him to struggle a bit – because that’s how you learn the tricky stuff.  I asked him to ask me for help when he got stuck. 

He went off and did exactly as I asked him.  He took his time and in the end he did a good job, in good time.  I was really pleased with his effort.

But here’s the glimpse that scared me:  while he was working independently (just as I asked), I kept having these horrible urges to ask him to prepare a design document. 

But, a design document wasn’t necessary:

• If I was doing the task, with his same level of experience, I wouldn’t prepare a design document.
• The size of the task didn’t warrant a design document – beyond a few scribblings on a pad.  This was a university-assignment sized exercise where (if you are average or above) you solve the problem first in code, then you write the design up, then you hand in the assignment.
• A document wouldn’t be any use because the only way he could build what I asked for was to (a) verify his requirements (b) do a little research (c) build a little bit (d) test that it worked. (e) repeat until he had something to show me.  That is, he’d have to do it as a learning exercise.

I was a little bothered by my reaction – why would I want to ask him to do something that I didn’t want him to do?  I thought about this inconsistency a bit and I realized that a design document would serve a purpose: it would give me some visibility (and therefore confidence) in what he was doing.  I’ve only known John a few weeks and I didn’t know him well enough to have faith or trust that he was up to the job (which he is). 

I thought a little more and I realized that an easier way for me to gain confidence and visibility was (a) to spend a little more time with him and (b) break the task down into smaller deliverables.  Both of these were easy to do.

This little incident helped explain another little incident: when I started my current role, despite busily working to construct our “data engine” before we ramped up with the new staff, someone in the client organization asked “what value” I was adding.  Why were they paying for me?

This seemed, to me, to be a stupid question.  I was very busy doing what I was asked, and  I hadn’t done anything to demonstrate that I wasn’t adding value.  My first instinct was to think he was stupid. 

I chatted with my boss about this and we agreed that the client wasn’t stupid. 

We agreed that the problem that I needed to solve was that not only did I have to add value I had to demonstrate that I was adding value.  This was easy, I just spent a little more time writing up my progress reports to emphasis not just what I was doing, but why I was doing it.

People don’t have confidence if they don’t have visibility.

Introducing ...

Ph. D Candidate, Angela Martin (a fellow Kiwi) has some great writing about Agile software development.

This one about the role of the XP Customer covers an area often glossed over:

We found that the interviewees provided a consistent picture of the XP customer role and they agreed that the XP customer role, especially for larger organisations, is very demanding. It requires preparation, skills, attention to detail, and the ability to make critical decisions.

One small step can change your life

Now, this is a lovely little book: One small step can change your life by Robert Maurer (the freebie articles in the media section are good). 

Just lovely.  It’s about using the Kaizen, japanese practice of small, incremental improvement, in your personal life.

I’m only on page 48 but I love it already. 

 

I’m only typing this now because I just made my wife read the chapter on small questions.

Google Print has arrived - sorta - and it looks good.

Wow!  Take a look at this Google Print search for “Goldratt”.   Click on the books title and you can view the text (just like Amazon, but with less clutter). 

[This is mysterious.  Google Print seems to be hidden – if you go to http://print.google.com/ you don’t get a text box.  I found it through the nifty xtragoogle.com via a blog that I can’t recall (sorry)].

 

 

Mad Bomber

If I was a mad, evil bomber intent on blowing something up then I would make all the wires the same colour. 

 

If they try to make me go back to the old way of working, I'm going to cry. A lot.

I got an email this morning for an ex work-mate.  He knows that I’m into the Agile and he sent me a copy of an email that had been officially circulated around the company. 

The company (the former employer mentioned in my last message) had recently started developing software incrementally for several of its smaller projects. One of the staff on the new team, Andrew Ducker, was so impressed about the new way that he wrote a blog entry about his experience, which he later emailed to his boss.  His boss was so pleased that he forwarded the email onto his colleagues. 

“If they try to make me go back to the old way of working, I'm going to cry.  A lot.”

Eventually the note made it to my friend, who works as a developer for the guy mentioned in my prior note. 

 

 

I WANT TO DO A GOOD JOB

Over the last fortnight, I’ve ramped up my team from 2.5 people to 11.5.  The newbies are all on temporary contracts and the work is, honestly, pretty dull. 

It’s a data cleansing project which has a lot of manual work.  The guys (meaning guys and gals where I come from) are temps.  I know some people would manage the new staff – especially since they’re temps with no apparent loyalty to the company – by setting up a system to force them to work as hard as possible – setting difficult objectives, measuring them, clocking-in and clocking-out, that sort of thing.

But I don’t know how to manage like that. 

And, more to the point, I don’t think it works. 

Why? Because, whenever I’ve been managed like that I’ve ended up hating the job and only putting in the minimum effort to survive until I could find another job.  I think most people are the same.

So, instead I’m trying to set the team up so that the guys can manage and organize themselves.  They’re bright and enthusiastic people, they have a broad variety of experience and are a fun bunch.  Why not exploit their inherent energy and give them the chance to do a good job?

-oOo-

I knew they were a good bunch when they started getting grumpy with me on the first day.  They didn’t have enough work to do (because I was the bottleneck), but even if they did they didn’t have any user ids.  They were looking at me the same way a pack of starving dogs looks at rump steak – THEY WANTED WORK.

I managed to find them some work that didn’t require user ids, but UNFORTUNATELY, they were too keen, they worked too hard and they kept running out of work.  THEY WANTED WORK. 

They didn’t want to sit around surfing the inherent.  And more so, they didn’t want to get in trouble for sitting around surfing the Internet.

THEY WANTED WORK.

-oOo-

I think that when most people go to work they WANT TO DO A GOOD JOB.  If they aren’t doing a good job it’s not because they are inherently lazy and un-trustworthy, it’s usually because the system that they work in doesn’t allow them to do their best and/or they’re not trusted. 

If I didn’t find them work then their enthusiasm would wane, they’d fill in their hours, but they’d hate it.  They’d surf the inherent and muck about.  Who could blame them?

-oOo-

I’ve always found that I am work best when:

• I have a clear WHAT but I get to choose HOW;
• I have the satisfaction of doing a good job and I can see that I’m doing a good job;
• I get to do what I’m good at
• There’s some sense of urgency
• Someone thanks me every so often

So we had a meeting.  The newbies had already created the sense or urgency – they wanted work.  The problem was that I was the bottleneck to them getting work.  We had to do something about this.

The first part of the meeting was to establish WHAT had to be done, which was quite straight forward. 

The second part of the meeting was to figure out HOW to manage that work getting done.  I had in my mind that I want to manage it in a scrum-like way, but I didn’t want to impose this because, to be honest, I’m not great at organizing these sorts of things.  So, I asked the team to figure out how to do it.  And they did, by themselves, with only a little nudging from me.

And guess what they came up with … a modification on the Scrum model.   We have a list in Excel (product backlog) which I and our customer (i.e. the product owners) are to add to, delete from and re-prioritize, then each week they would take a chunk off the top of the list and do it.  We have another list of lower priority work that they can do and self-manage, if/when we product owners can’t keep the first list full. 

Since some tasks are far too big for one person to do by themselves in a short time frame, we decided that we’d need to assign an owner to each task but that it was still the teams responsibility to make sure it gets done.  We figured that some people would enjoy owning tasks but that others wouldn’t – so we made that role optional and we’ll leave the organization up to them.  Later next week, I’m going to start doing short daily stand up meetings.

-oOo-

So … this has been a long post, mostly for my own benefit – I want to reflect by writing about my week.  I’ve contemplated chucking this, but maybe there are some good ideas here.  Nothing new, but still good.

It’s very early days but I hope it works – I think that it all boils down to me living up to my end of the bargain. 

 

Learning by Writing

A few months ago I had to give up writing my book full time.  It was good news really because my wife is pregnant and I would rather have the money in the bank than the words on paper.  I’ve got a contract that I’m really enjoying and I’m actually getting to apply agile techniques to get the cash flowing quicker for our customer.  The customer is very happy with the new perspective.

I’m trying to work 4 days a week and take the 5th day to work on my book – although it’s never that easy!. 

So far I find this very productive because even though I’m not writing so often my brain ticks over in the background and I don’t suffer writers block as much as I did when I was full time.

Anyway … one of the things I’ve found while writing is that if I’m getting it wrong then my characters tell me.  If I’m missing something – say my argument isn’t clear enough or it’s wrong – then the characters say so, out loud in their dialog.  Tom, Steve and Craig are all very thoughtful, well meaning and intelligent characters so they’re polite about it … but they’re very politely blunt.  I’m sitting there typing away and suddenly one of the characters – usually Steve – says something like “Huh? I don’t understand what your talking about” or “Slow down there, I’m confused’. 

I’ve learned to listen to them because they seem to understand their subject better than I do.

When this happens I’ve found that the best thing to do is to let the characters figure it out themselves. 

This may sound strange.  But, it’s like I’m just sitting there transcribing their discussions.  They discover all sorts of things that make the story or the lessons clearer, they often figure out things that I wasn’t aware.  Their discussions are a bit crazy and all over the place at times, so I need to rewrite them so that they’re crisper,

I’ve learnt lots by listening to my characters as they learn how to Roll Rocks Downhill. 

I might even get them to guest star on my blog one day. 

Learning by Talking and Listening

1.  According to a personality test I once did, I learn by speaking. 

That is, I often don’t know what I’m going to say until I say it and I learn through conversation.  I “think out loud”.

I don’t know how they do it, but the personality-test results said that lots of other people “think then speak” – i.e. the exact opposite to me.  This was a revelation to me because I can’t do that – I used to wonder if there was something wrong with me and so I tried to organize my thoughts upfront, but it just didn’t work.  To the others, I must come across as being very disorganized. 

The personality test suggested that if I am “thinking out loud” then I should say so. 

So this is exactly what I do – as the conversation warms up, I start to learn things and I get excited.  I wave my hands about with enthusiasm, I talk faster, often in incomplete sentences.  I am in essence talking to myself, repeating what I’ve learnt to myself, helping it to sink in, and seeking confirmation from my companion. 

After a while it usually occurs to me that the person I’m talking to must think I’m mad.  So, I backtrack a little and say something like, “Wow this is great.  I hope you realize that I’m just “thinking out loud” here.  They nod, pleased – I imagine – just to be included in the conversation.

2.  Now take a look at this poem:

His thoughts were slow

His words were few

And never made to glisten

But he was a joy

Wherever he went

You should have heard him listen

One of the down-sides of my “thinking out loud” style is that, compared to my “think then speak” colleagues,  I talk lots and a listen less.

3.  Last year, I was on a panel discussion with non-other than Barry Boehm.  I talked more than he did. 

I’m still embarrassed about it because while I learned lots by talking, I missed out (as did others) the chance to learn from the master.

4.  It’s interesting … but I’ve just realized that I also learn by writing. 

The answers obvious now that I’ve thought and written about it : Not only do I have to say that I’m “thinking out loud”, but I also need to listen more.

I wouldn’t have explicitly known this if verbalized/written it down.

Am I just thick or what?

Tell me … if I were to add lots of comments to other peoples blogs – especially the more popular ones – would my google rank go up?

Not that I could be bothered but … just wondering.