Thumb based voting

Not everything in coaching is based on complex psychology and systems thinking.  Sometimes you just want want a quick way to make a group decision, assess data or gather people’s reactions to an idea.

One of the quickest ways to assess an idea is to ask for a show of hands. I leaned this one in school when the teacher would ask us to put our hands up if we had a question.

Read More »

A rough and ready presentation on agile governance

I recently gave a presentation on agile governance at a Gartner conference in Australia.

A couple of people asked for a copy of my slides – but they don’t make a lot of sense without some explanation, so I created a short video of the presentation:

The original scrappy version is here

A cleaned-up, slightly refined version is here:

The good news is that I did it in one take with just my new Nexus tablet as recording equipment and Powerpoint as a publishing medium. Of course the bad news is that you can probably tell this is true by the product quality.

The humble trade-off matrix

I have been doing some business analyst training recently and I spoke about a “trade-off matrix” a couple of times. A couple of people have asked for a good link to explain what one is and why they are so cool. So I looked on the web and couldn’t find anything decent enough to send through.

So I thought I would describe what a trade-off matrix is here. I will also briefly mention why they are useful and then mention a couple of variations that people might not have heard of.

Read More »

The dark art of office politics for IT leaders (part one – why is it stressful?)

Apparently office politics is a horrible thing that other people do.

But many of the emerging IT leaders I speak to get told they need to be better at “soft skills” and “influencing at a senior level”.  What this often means is get good a politics.

Sadly a lot of office politics seems to involve people playing games to get their own way at the expense of everyone else. This skill can be learned and might seem useful, but it is not what I am going to talk about here.  I am going to talk about “how do the good guys get the right outcomes when people have competing interests or needs and some people seem like knob-heads”.

Read More »

Stealing ideas from Stand Back and Deliver

I am running an “advanced BA course” next week and as part of the course we will be exploring the concept of strategy from a business analysts point of view.

One of the trainers I work with (Shane) recommended we provide the participants with a book called “Stand Back and Deliver” by Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald.

Read More »

Would you hire a project manager to plant a tree?

Many great ideas fall on deaf ears. So organisations bring in project managers to make sure we implement good ideas properly.

Good project managers define and clarify the idea, break the idea into features and then deploy the features into production. But quite often, people just don’t make use of the shiny new features they have been given.

Which is another way of saying that the great idea fell on deaf ears. So some organisations bring in change managers (and trainers and technical writers) to make sure people understand the new idea.

Good change managers make sure that the project is visible to stakeholders, supported by the important stakeholders and that the features being deployed are explained properly to the users. But quite often, the users go back to their old ways after a week, or they complain about the new features and the “stupid” projects that created them.

Which is another way of saying that the great idea fell on deaf ears.  So what goes wrong? Why do so many good ideas fail to get adopted?

Read More »

The one thing you can’t outsource is innovation – or is it?

This blog is normally a collection of my own thoughts rather than a source for links to other people’s thinking.

But it seems a lot of companies are now deliberately asking others to do their thinking for them, so it seems fair enough for me to do the same.

Here is an interesting link to an article on crowdsourcing.

So my question is – if you can even outsource your thinking, what does it mean to be an organisation in the new world order?

The “what would someone else suggest” technique

Today I ran a workshop on workshops and predictably one of the things we did was brainstorming.

But one of the participants was a little bit bored with putting post-it notes on the wall, so we replaced our standard brainstorming with “what would someone else do””.

This approach can work really well in either a coaching session or a workshop.

The idea is that if we already knew what to do about something there would be no issue and no need for coaching or a workshop. So rather than asking “what can we do” and being stuck with our usual thinking we ask “what would someone else do”.

For example, I might ask you to answer the following questions to shift your thinking:

  • What would you never do that someone else might try?
  • What would your parents do?
  • What would a leprechaun try?
  • If we just found out out competitor had solved that problem, what would they have done?
  • What would your evil twin do?
  • How would Buffy the Vampire Slayer deal with that?  What about Spike?
  • What would never work?
  • If you were back at school, what would your friends have told you to do?
  • What would you tell someone to do?
  • What would Homer Simpson never think to do?

The aim is actually to ask more than 7 odd ways of solving the problem that we would not normally think of doing.  The reason for trying more than 7 is that someone told me that the first few approaches we think of are often repeats of the same ones … plus 7 is a lucky number.

But in our workshop one of the crew was a more inventive.  This is what he did:

  • Break people into teams of two;
  • Allocate a fictional (or famous) person to each group;
  • Give people to brainstorm some suggestions their fictional person might come up with;
  • Share the ideas with the group; and
  • Ask people to state how they could combine different combinations of the suggestions to come up with something that is actually sensible.

It worked really well in the group.  The only improvement I thought might work well for next time was to consider using some deliberately different characters to find some extreme suggestions, for example:

  • One team be Santa Clause and the other Scrooge; or
  • One team be Britney Spears and the other my great grandma.

Try one of these approaches next time you are stuck for ideas and let me know if it works.

Estimating the impact of technical debt on stories – heat maps

I have been in several conversations recently about how we take refactoring and technical debt into account when estimating work on IT projects.

For those not up with the jargon – refactoring involves improving or simplifying your code without changing the functionality.  This means that the code can run faster and more reliably, be better maintained etc.

Technical debt is the concept that if I take short cuts to get a project into production then I am borrowing from the future – in other words someone in the future will need to do more work to make up for the fact I am doing less now. 

Unfortunately though, even if I do all the work that needs to be done now, the system I build will become less fit for purpose over time if it is not constantly maintained and refactored which means that all systems have some level of technical debt in them.

In fact when you talk to some teams they will go to a lot of trouble to avoid making changes to particular systems or system components because they are “delicate” or more accurately unstable and scary to work with.

One of my favourite tools for taking this into account when I am estimating the cost of adding or changing features in a system is the a “heat map”.

Essentially a heat map is a map that shows where to expect trouble in a system and where to expect smooth sailing.

To create a heat map, simply take any model of the system and shade or colour different areas of the model to indicate the ease or complexity of working on different each area. Things that can be taken into account include whether there are automated tests in place, areas of spaghetti code, areas that involve complex integration code, areas the developers know well or anything else the team feels is relevant to the complexity (and therefore estimated effort) involved in working on different areas of the system.

The team adjust estimates involving different areas of the system in line with the “heat” of the particular area.

Heat map

Once the team has created the heat map they use it to update their estimates for changes that involve different components of the system.

I the team are using relative estimating techniques like planning poker they they will simply discuss which areas of the system are impacted by the change and then take this into consideration when voting on their estimates.

If the team are estimating by time, then they might agree, for example, that any work involving the lightly shaded “a bit scary” components will take 20% longer and work involving the “bad lands” will take 200% longer.

This is a simple way to take a lot of complexity into account when doing your estimates without having to go to a great deal of effort.

Finally launched my agile training game

We set up a stand at the recent Software Development Conference to run the Agile Release Planning Game I designed.

It seemed to go down really well, so I have decided to make the game available publicly if anyone is interested in using it.

In the game, participants are a group of scientists and engineers who are stuck on Mars after a “less than successful” landing.  They are on a mission to make scientific discoveries but must now rebuild a basic infrastructure for survival before returning to their original mission.

Participants then create a strategy based on rebuilding their ship, building a base and/or returning to their basic goal of research.  In doing so they must make trade-offs between quality and velocity.

The game introduces concepts such as release planning, iteration planning, velocity, release planning trade-offs, building by feature and adaptive planning.

The game is designed to be led by a facilitator, but can be run without one.  The release planning game takes around half an hour to play and can be replayed multiple times to explore different concepts in more detail or to improve the outcome based on lessons learned in the first attempt.

Different options allow the game to be played as a very simple introduction to the concepts of release planning or a more complex game involving more realistic trade-offs and decision making under conditions of uncertainty and pressure.

In addition, there is an extension included in the game that focuses on planning within the iteration (or sprint) rather than across the wider release.

Let me know if you are interested in learning more, or even trying the game for yourself.