Rough notes for a blog post about control

Lot of people who want Agile training or consultancy say that they want more control.

Very often they want to "control" their junior staff. They're very worried that their junior staff are lazing around doing nothing.

A lot of people who are saying these things are in what I regard as the 4F stage of management thinking "Why don't the fucking fuckers do what I fucking tell them? After all, I'm their fucking boss." This was exactly how I felt when I directed my first play at university.

By the time I'd got round to directing my second play I'd realised some really important things:

• Everbody is a volunteer
• Things go much better if you create an environment where they feel they can try new things and do their best
• You have a be an honest judge, that they trust, of whether what they're doing is good enough

Things they don't want to hear - "Law of Requisite Variety" , from William Ashby one of the founding fathers of cybernetics

"the variety in the control system must be equal to or larger than the variety of the perturbations in order to achieve control".

This means that in order to control your team, you need to as sophisticated as they are. In order to control a team of people or a project, you need to understand what it's about.

If people in your team do exactly as you tell them, you're stuffed. If you make them do exactly as you tell them for long enough they will acquire a syndrome known in psychology as "learned helplessness." They give up even trying to think for themselves and do exactly what you tell them.

There's always another way of controlling behaviour. You can kill it dead. You can fire people, or threaten to fire them. But actually, Ashby's law applies to that as well. If you try to control things by killing them, you end up with a system that only contains things you can't kill - like MRSA. You end up with just the people you can't fire, or aren't scared of you.

This fits in with difficult conversations stuff. Understanding is all.

Read in a book on Buddhism recently - "If you want to control a wild animal, put it in a big field".

For further information, contact Mark@agilelab.co.uk (07736 807 604)

What's the difference between a team and a group?

Very interesting chat on Wednesday with Dave Dawes (http://www.entreprenurses.net/) about the difference between a group and a team. I think what Dave was saying is that a team has a fixed number of members who stick around for a long time. A group has members that come and go.

Think this is very interesting with regard to the whole "forming storming norming and performing" account of team formation. If you have a group where the members are constantly changing, you will never get past the forming/storming/norming phase. So the amount of self-organisation and the level of performance you can expect from a group as posed to a team would probably be less. Similarly, the amount of management involvement required reduces as you move from forming to performing as this article explains.

I got thinking about all this forming, storming, norming and performing stuff after doing Rachel Davies' fascinating coaching exercise at minispa2009.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

What are you doing for lunch?

Do you work for or run a small to medium sized web development agency? Do you suspect that your team would benefit from some training in project management, but you can't see where you would get the time to send anybody on a training course for a whole day, let alone, go yourself. We might be able to help you.

Many of our customers are *very* busy small to medium-sized web development agencies. They don't have time to go on a delegate course and they certainly don't have time to let all of their staff "lose" a day on an in-house training course. Therefore, we're offering our well-established, well reviewed one-day "Introduction to Agile" course in three new flavours - Breakfast, Lunch and Dinner.

The idea is simple. We break the six hour course into four 90-minute sessions and arrange to give those on your company's premises in either a breakfast, lunch or dinner (end of day) slot.

Of course, you could get through the whole course in a week, but it's probably better to spread it over several weeks, to improve the chances of retaining information and to give time between sessions to reflect on current process.

Example schedule - what would go in the four sessions?

Session 1:

• Getting to know you.
• Traditional project management methods vs Agile, iterative methods
• Why the web is different

Session 2:

• Stories: How do stories differ from use cases and other specifications?
• Estimation: Planning poker and other effective ways of estimating work quickly.

Session 3:

• Prioritisations: Always work on what's of most value to the customer
• Iterations: Plan work for a short, fixed period of time.
• Tests: Use tests so that you always know when you're done.

Session 4:

• Velocity: The power of knowing what you're capable of as a team
• Meetings: How are meetings different in an Agile project, what meetings do you need to have? How are they run?
• Role of the Project Manager: What does a PM do in an Agile Project?

We can also can also run several single-session seminars - "The role of the Product Owner in the Agile Process" and "Software without tears - negotiations and difficult conversations in software development."

We can also mix and match sessions to provide a custom solution for your company.

Contact us if you're interested in having us run a course in your organisation for breakfast, lunch or dinner.

Negotiators know how to make the pie bigger - learn how to do this as part of our "Software without tears" seminar in an Agile Lab lunch time session.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

What Could Possibly Go Wrong?

We know all the theory right? So now all we have to do is put it into practice? How hard can that be?

I read a blog post a couple of weeks ago about how to keep your brain sharp as you get older. This is the kind of thing that is to Twitter (with the oldest average age of any social media network) what relationship quizzes are to fashion magazines.

I don't remember most of the recommendations (probably because I'm getting old - boom! boom!), but one of the suggestions was that you try to do things with the "wrong" hand. I'm left-handed and all the way through school struggled to write as quickly and as neatly as my right-handed school mates. And trying it out has revealed to me a marvellous instant demonstration of the difference between theory and practice.

Right-handed writing, the first time I tried it

So, for several weeks now, I've been writing my morning journal with my right hand instead of my left. It isn't easy. I'm a lot more relaxed now, but when I first started doing it, it was physically demanding. I found myself having to deliberately stop myself from gritting my teeth and curiously jutting my jaw - sort of like somebody might act if they were trying to amputate their own leg in an action movie.

And the writing itself was diabolical.

I would often find myself just heading off in the wrong direction with the pen, or "losing it" altogether and not being able to write anything at all.

But of course, the more I've done it, the easier it's got. Very early on in the process it dawned on me "Hey! I already know how to write! I already know all the letters of the alphabet and how to put them in the right order. In other words, I already know all the THEORY of writing, but that doesn't mean that it's any easier to put the thing into practice."

Three weeks later - better but still room for improvement

When you try writing with your wrong hand you realise very quickly that putting theory into practice is a separate process from understanding the theory. For handwriting, putting theory into practice involves changing the way muscles and neurons work, storing new information inside them, and that's a non-trivial process that takes time.

There's the learning that, and then there's the learning how and very often they're two seperate processes.

Some points that I've noticed about trying to experimenting with this radical change:

• If I take the trouble to visualise a word before I write it, writing the word feels much easier and looks much better.
• Doing something so strange, results in the whole of your body tensing up which results in terrible handwriting. But if you relax too much, that's no good either, nothing happens. You have to actively look for a balance between focus and relaxation.
• When you first start doing it, you're knackered after half an hour, actually, probably about ten minutes.
• Latin characters are designed to be written right-handed. There's a kind of rolling flow to writing right-handed that you never feel when you write with your left hand. Every now and then I feel this "flow", normally when I forget that I'm writing with the wrong hand and concentrate on what I'm writing.
• Exploring all the possibilities of writing with my right hand, cutting loose, letting go, scribbling and shading, drawing big shapes and small shapes, tiny stick men and perfect circles, seems to improve things just as much, if not more than simply concentrating tighter and tighter control and getting the letters perfect. Periods of "going crazy" scribbling and doodling followed by focussed concentration seem to work best of all.

Left-hand writing, perfected over about 36 years.

Any of this got anything to do with Agile? With training? With Lean and Kanban and experimenting with new methodologies? I dunno, what do you think?

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Notes on Rachel Davies workshop "The Role of the Agile Coach"

Rachel Davies ran a very interesting workshop yesterday at MiniSPA2009 on "The Role of the Agile Coach."

I won't give away the details of her workshop, but suffice to say that it involved some people working on a task and other people taking management roles. It looks like a very simple activity, but to me it felt like a re-run of the Stanford Prison Experiment with non-toxic glue and feathers.

Some observations from the experience:

• Even though Rachel's an Agile coach and this workshop was supposed to be about Agile coaching, everybody, especially those in management roles seem to treat this as a waterfall project, even down to trying to treat the instructions that came with the activity packs as a fixed spec.
• I was a worker, and as a worker my main motivations were to bond with my other workers and to make myself useful. I didn't really take any notice of the coach who was there supposedly to ask questions.
• Comments from the two people who were asked to take on management roles were almost all critical. In a sense, this was an artefact of the task - what else did they have to do but point out what they thought was going wrong?
• The spec for the task was very loose, but that didn't stop some people who were in management roles adding in extra assumptions, assuming spec where there wasn't any. And assuming that part of the task was to hammer down the spec.
• I found myself saying "We thought we were being creative, but management just thought we had no idea what we were doing." Oh boy did this chime! To some degree with my experience at Xerox, but especially with my experience working in research at Universities.
• We got fascinated with the task and missed a (perceived to be) crucial aspect of the spec. In the end I fixed this as I walked up to submit our entry. "Management" on our team perceived this to be a grave failing, even though my last minute solution worked.
• As a team of workers, we instinctively seemed to understand that we had to feel each other out and understand what we capable of - I think this is what's called the "Forming and Storming" sections of team building. Management focussed instantly on the "Norming and Performing" and fretted and criticised as it watched our "Forming and Norming" activities.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Trying to Understand Kanban in Software

I was very interested to hear Karl Scotland's talk yesterday at Minispa2009 about Kanban. I think he's a addressing some very important issues, but as I've said on Twitter, I wasn't quite convinced by his talk. I think he's nearly there and can't quite make out whether the problems are in my understanding; his communication; or in the actual ideas themselves. Anyway, here are some notes on things that I think at the moment are an issue.

Software components aren't car parts

One of the way I try to explain stories when I'm doing agile training or consultancy is that stories are stories. A story is an out-of the ordinary situation which needs resolution. It's news. Software development spends most of it's time dealing with "Man Bites Dog" cases because "Dog Bites Man" cases are already catered for in the language libraries and the API. Software people, project managers and the people who support them with training and consultancy are all what Peter Drucker called "Knowledge workers". Ironically, that means we spend most of the time NOT knowing what we're doing. I'm not sure how well this fits with manufacturing car parts, or assembling cars.

Toyota Production System is a "That would never work for us" method

Anybody who has ever tried to advocate any kind of project management method to someone in an organisation will be familiar with the "That would never work here, that would never work for us," response. What isn't perhaps discussed so much is that exactly that attitude is the root of the Toyota Production System from which Lean and Kanban ideas are extracted.

As I understand it from my reading of Taiichi Ohno's book and from reading "The Machine that changed the world." One of the original spurs for the Toyota Production Method was an understanding that the way that Ford made cars wouldn't work in Japan. They simply couldn't make enough cars to get the economies of scale that Ford (claimed) he was getting. Another realisation was that Japan's demand for manufactured goods was extremely cyclical and so Toyota needed a method that could "smooth" out these oscillations in demand. But Ford's model of hiring and firing low-skilled workers as the need arose simply didn't fit with Japan's cultural understanding of what work was. People worked for the same firm and stayed loyal to it all their lives. Enormous value was placed in the deep knowledge and mastery of skills. Toyota decided to put together a system valued skilled workers and held onto them through all stages of the economic cycle.

This is what I don't see in Lean and Kanban approaches to software. It doesn't say "We need to design our own Toyota Production System that reflects our culture, values and economic cycles," rather it says "we need to use theirs!".

Flow vs frame. How do you know what you're capable of?

This maybe not so much an objection as a lack of understanding. I didn't quite understand what Karl meant by the term "cadence". It seemed to be something like an iteration, but of variable length. I sat up and paid very close attention at this because one of the things that you're always asked when consulting and training about Agile methods is "How long should iterations be?" And so some kind of rule - even a rule of thumb for working this out would be interesting to know about. But at the same time I'm worried that giving up on the idea of fixed-length iterations, results in the loss of information about velocity. And one of the things that I think is vitality important about Agile methods is the ability to get better and better understandings of what you're capable of as a team.

Another way of thinking of iterations is a frame that you put around the work that would be getting done anyway that allows everybody (developers, project manager, clients) to talk about it in an different way, to reflect on progress, to decided on changes of emphasis and direction.

The aim of these comments and objections isn't to dismiss Kaban/Lean approaches because I think they would be particularly well-suited to settings such as web development agencies, where the work tends to turn up in a continuous flow and doesn't necessarily fit itself into time-boxed. Iterations.

Thanks to Karl for an interesting talk.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Very Pleased

About this:

"Mark recently helped us to implement a SCRUM project management tool to streamline our project process. He helped this to happen while also bringing his experience to bear in advising the team on best practice and training them in SCRUM and product ownership. Mark is a really nice guy, an expert in his field, and has really made some significant improvements to our team's ability to plan and deliver projects for the business. Many thanks - and I hope our paths cross again."

Damian Stafford, Group Operations Director at Lawton Communications Group
(quoted from LinkedIn)


For further information, contact Mark@agilelab.co.uk (07736 807 604)

Money, Money, Money

I was using this piece of overheard dialogue as part of the training that I did yesterday. There's a lot wrong with it as a piece of training material, but the one advantage that it has is that I actually did overhear this conversation in a cafe in London. It's the way people really talk about projects, scary though that may be.

I got some funny comments- "Are they married?", "What kind of weirdo are you, lurking about in cafes and overhearing peoples web development negotiations?" (Well, check out the rest of this blog, this kind of weirdo).

But one the people attending the course, had something very insightful to say. "He's just talking about the money." she said.
"He's not trying to find out what they want, what's important to them, he's just talking to them about the money."

For further information, contact Mark@agilelab.co.uk (07736 807 604)