Thoughts in the Wilderness

As mentioned a few weeks ago, I have started a new job. My role is still unclear, but that doesn’t bother me at all – this way I can define my own role.

I’m working in a small team of web developers, trying to start on the next generation of the web portion of our core business product. The team was supposed to be Agile, but was decidedly *not*. I’m working on that, i.e. so far I’m defining myself as the Agile-guru.

We had our first planning meeting that I was allowed to run, and I went with my favorite planning tool (FreeMind). The team is very tool and framework oriented, so I think introducing the tool as part of the planning was less intimidating than if I had just gone at it with story cards.

My purpose in using FreeMind is to enable open discussion, and also to focus that discussion. It allows me to acknowledge everyone’s input, by reflecting it on the mind-map. The tree-like structure naturally allows everyone to be focused on the current area of discussion without being too distracted by other concerns. Once we have everything noted, then we can more effectively make estimates.

We had a very short estimating session. This was difficult, because individuals on the team seemed information-starved, i.e. they wanted to gather all of the requirements then and there. I tried with limited success to focus on just getting rough estimates. To keep it ultra-simple, I allowed only 4 time estimates: 1 day, 2 days, 5 days, or more (needs to be broken down further to estimate). As expected for a new Agile team, estimates were *very* ambitious, and we did not complete.

My final note is that it is interesting to be able to observe the team forming. I was the last member of the team to be hired, but before my joining, the others have barely interacted as far as I can tell. This means that we started in the “forming” stage of team evolution. This is characterised by the our manager being very hands-on, and directive. Basically, we are not a team so much as a set of individuals working under the co-ordination of a manager.

The next team-stage after forming is “storming”. This is a little stressful, and I hope we don’t lose any team members, or the confidence of our manager. I can already see some people coming out strongly on opposite sides of issues, and coming into conflict because of it.

Anyway, that’s my update. Wish me luck.

You may occasionally see the term Shu Ha Ri bandied about in people that think a lot about Agile and Lean. I think Alistair Cockburn was the first to use it in relation to software development.

The idea is that we should teach the beginner (Shu) some techniques, or best practices. Ha is the stage where the beginner has learned that there are some underlying principles, and begins to explore those. Ri is the master stage, where the master adapts and invents new techniques.

“Shu Ha Ri” is implicitly a craft-based way of thinking of software development. The individual words imply the different levels of craftsman, from apprentice through journeyman, to master.

The more interesting aspect of the term relates to communication. It can be hard for Shu-level and Ri-level to communicate. This is because Ri believes there is no single best solution to a problem (everything depends – he will implement a best solution by adapting as he creates it). But Shu needs firm guidance – he needs to be told a good-enough way to solve the problem.

One way for Ri to communicate is using the principle of strong opinions, weakly held. That is, he should communicate as if he is certain that what he says is correct. But it is all an act. He is not certain, and definitely not attached to the opinion.

In short, if I am Ri then I should feel free to present my opinions or theories as dogma.

If the other individual can show a better way, then I will accept that (it’s easy, since I was never attached to the original opinion anyway).

A while ago I did some research on the psychology of motivation, to discover ways that I could relate to our software development team that would support them being motivated.

I won’t go into the gory details (since it is was a while ago and I have forgotten my references), but what I came out with was that in order to be happy, a person should experience the following:

• competence – they should feel like they are good at their job
• autonomy – they should feel some sense of being able to choose how they work, and what they work on
• relatedness – they should feel that they are a part of some larger whole

This balances out over a person’s day-to-day living. So if I have no relatedness at work, the only way I can be truly happy is if I find a lot of relatedness elsewhere, such as participating in a sporting team.

Happy goes a long way towards supporting motivation, so in order to motivate someone, I should endeavor to make them happy.

Thinking in this way has helped me avoid repeating mistakes. One thing I had been guilty in the past was throwing unrealistic learning curves at people. But, a learning curve (while useful) temporarily reduces a person’s feelings of competence. If they feel lost, then they can also feel alone (relatedness).

Even small changes can push a person over the line, to the point where they start looking for a new job. I still throw leaning curves at people, but I try to do so in a much more supportive way.

I try to filter my thinking at work by considering whether different things increase motivation (by supporting feelings of competence, autonomy and relatedness), or decrease it:

• how do the work-processes we use affect the people that are using them?
• as a person with much more experience and knowledge, how do I interact with people with less of those things?
• how can we introduce a new employee to work in a way that makes them more likely to stay with us