They need to fix accountability

My favourite comment for the week was me and a friend talking about a project we were consulting on. We agreed that “they need to fix their accountability”.

While we might be right, we realised that it is a bit wimpy to suggest that someone else has to fix accountability for a project you are on.

So we had a long discussion about what we could do on the project and we concluded we just needed to make sure we were clear on
– what we delegate (including escalate or ask for);
– when we are ambiguous about our own accountability for something and our own authority for getting things done
– when we were assuming someone else was “handling something” and when we thought we were.
– Next project we will go back to basics and insist on a session where we sit down and explain our roles and responsibilities to each other and then debate them.

We have already had improvements in less that a week. It was so simple that I am wondering if it is worth creating a one day course that covers nothing more than delegation, follow up and expectation setting. Would you come to a course like that or is it something you already know and do?


Argumentum ad waterfallium

Argumentum ad hominem is a cool Latin phrase I read in a book called “How to win every argument – the use and abuse of logic”.  The book is written by Madsen  Pirie and while I don’t know if it is still in print, I do know its on the shelf at the Chattswood Library in Sydney.

The concept is that I will attack an argument by attacking its source (speaker).  So rather than saying I disagree with Fred because of a flaw in his argument, I either

  • Explain that Fred is a bit of a wally and therefore not to be trusted in this matter.  The natural conclusion is therefore that we should ignore what he is saying; or
  • I say that Fred is not one of us.  All people of a certain grouping (say agile project managers) believe that xyz, which is not what Fred is saying, so as agile project managers we should ignore him and believe (my argument).

The problem with the approach is that I have not assessed or commented on the quality of the point Fred is making, but rather distracted the group from doing so.

This turns out to be a great way to trick people if you want to be evil:

  • As Australians we must believe that … (never mind why)
  • Fred is from management, so of course he would say … (never mind if it makes sense)
  • Waterfall projects are stupid and agile/lean/kanban projects are much better, so we must … (never mind why)

I have noticed a lot of people recently saying we should not do x because it is a waterfall approach to projects or we must do y because that is the agile approach.

The problem, as you can probably perceive, is that “waterfall projects” are not people and so “argumentum ad hominem” does not apply.  So I have invented a new term “argumentum ad waterfallium”.

Now if you are evil, you have a Latin (ish) term to apply to what you are doing.

Also – if you hear someone say “that was how things worked in waterfall so we can’t do it” or “In agile projects you need to have user stories so we need to …” you can respond automatically with “Waterfallias Argumentum ad”.

When they ask “What on earth do you mean by that?” – you can respond with “exactly what I am asking you”.

Just because waterfall is old and agile is cool does not mean we should or should not do something.  I have commented on this in a blurb I did to advertise a talk I am doing.

More widely though – you will often hear people in the workshops you run say that some must happen because “the CEO said it” or not happen because “that was the old way” or “that is what management want us to think”.

When you hear this (or do it yourself) remember – the source of the argument may make us question the motives for the argument but they do not impact the quality or the logic of the argument.

So whenever anyone uses this technique stop and ask them why they disagree with the argument.  You will often find that they struggle to answer that question without reverting to talking about the person rather than the argument.  Which means they are probably not considering the argument at all.

Vacancy for an agile trainer in Australia

I do a lot of work with Software Education and I can vouch for them as an excellent group to work with.

So I thought it would be worth mentioning that they are looking for a new trainer to deliver a range of courses in agile development.  You will need to be charismatic, experienced and good at dealing with the reality of projects rather than just the theory.  The charisma is particularly important because the rest of us trainers look like we have been hired for our experience rather than any soap opera like good looks 🙂

If you get a job there and love it then you owe me a coffee.  If you hate it then its not my fault, I just typed in a link to some random site and you should have done more research.  On the other hand if you miss out on or don’t follow up on the role then it will have been great.

Similarly if you start work with Software Education and it all goes really well then tell them that you found them through me and I deserve kudos by association.  But if you suck at facilitating and helping participants learn, then tell them your name is Geovanni McKetchup and that you have never heard of James King.

On a slightly serious note though, if you are considering training or consulting and do have some practical experience, then they are a great bunch to work with.  Contact me if you want more of a briefing on their style and what it is like working with them.

Minor rant from James – what happened to the customer

I just posted this on another site, so I didn’t want to repeat it all here.

The article is at this simple english heading:

As you would (not) guess from the wording of the link, I am wondering why we still debate the involvement of the customer in our IT projects.

We adopt every new technical practice and every new approach – and then baulk at the idea that we need to understand our customer’s needs, or at the idea that we need to get them to make the time to help us.

Maybe we should stop implementing other project methodologies and start breaking our project approaches into two simple groupsings:

– Method 1 – ask people what they want, give it to them and then ask them what they want next.

– Method 2 – build something, apologise and then tell the client they are stuck with whatever it is, so why not give us more money and see what happens.