James King

What you do next matters

Should measures be “SMART”?

Posted by James King on September 6, 2010

I was having a debate with a friend of mine recently.  He said that all measures should be “SMART”.

The term is usually used for goals and says that the goal should be specific, measurable, achievable, relevant and timely (or something similar).

The problem I pointed out was that the M in SMART means measurable so the concept of SMART measures is a bit redundant. He responded that in his experience many of the “measures” he saw in place were not actually being measured and so, he claimed, it would be good to remind people to actually have measures that they will measure.

I am not sure if he is exactly right or not, but I came up with my own standard for measures.  Its a little lazy compared to some, but I find it useful.

I think measures should be Credible, Useful and Easy (CUE).  

The most important component is Useful – the meansure must assist you to either make a better decision, change a specific bahaviour or reduce the ambiguity in your understanding of something.  It is suprising how easy it is to forget that the measure is only worthwhile if it can be used for something – in which case you should understand what you are likely to use it for before designing the measure.

But the measure also needs to be Credible so that you and others are confident that you can rely on it.  Note however that being Credible without being Useful is actually worse that not being Credible – you will confidently make decisions on the wrong data.  Thus you also need to understand where the measure will sound good but not be relevant.

Easy means that it should be easy enough to measure to make it worth doing.  So a measure might be worthwhile even if it is a substantial effort as long as you gain a huge benefit from it.  But my experience is that if it is hard to measure then people will forget to measure it, take short cuts and even fudge the information.  So the harder it is to perform the measure the more you need to ensure the people doing the measuring believe it is Credible and Useful to measure it propoerly.

So there you have it – measures should be CUE.  Not quite the same ring to it as saying goals should be SMART but good enough to be useful (I hope).

Posted in Investigation, Measurement | Leave a Comment »

A role profile for poject teams

Posted by James King on August 29, 2010

According to management theory, we all do a better job if we have a clear understanding of our role and what value it is adding to the team and the organisation. We also find work more satisfying when this is the case.

But quite often the role profile, position description and annual performance agreement become more of a burden than a source of job satisfaction.

In fact in most of the really successful project teams I have been in, we threw away our job titles and did whatever it took to make the project successful. So my experience with performance agreements and job descriptions seems to go against management theory.

As the team matured though, we started to learn more about each other’s strengths, weaknesses and even the type of work we liked/didn’t like doing. And it is at this point that I agree with the management theory – I was happiest when I knew what value I added to the team.

But it can take a while to carve out your niche on a project if it is large and complex. So this is the approach I like to take to get to this when starting on a project:

  1. Define your job in really simple terms in relative ignorance (ie based on what you think you know before starting):
    • My role is blah: where “blah” is less that seven words or a title such as DBA
    • If my grandmother asked what that means I would say …..
  2. List your most important 3-5 responsibilities as you see them 
    • For example a BA might list “produce the scope document” and “Mentor other BAs”.
    • Define a measurement.  This is not a smart goal or a stretch target – just state “I would know I was on track if …” and “I would know this isn’t happening if …”
  3. State the key decisions on the project you think you should be involved in:
    • I will be the one who decides …
    • Always check with/involve me in these decisions before they are made …
    • Let me know just before you …. even if you didn’t get my input
    • Tell me after the event if you ….
    • I am happy to be involved in other discussions but feel free to leave me out.
  4. At least meet with the project manager and argue about all the points above.  At best have a speed dating session where everyone in the team presents the above info to each other and argues what it should be for each person’s role:
    • (By “argue”, of course  I mean talk … actually I mean feel free to argue too).  Argue about both the explanation and the ranking of your responsibilities.
    • You will be suprised how often you thought the most important aspect of your role was different to what others on the project thought it was. Talking about it removes that ambiguity and forms a common understanding.
  5. After about 3-4 weeks, repeat the process and see what has changed.
  6. To go the next step, you can have a separate session on understanding each other’s strengths, weaknesses and communication styles. I can help you with this but there are also many books and workshop techniques you can use yourself. In fact if you are in Sydney, you can go to the Australian Institute of Management bookshop and they will show you several cheap and breazy workshops you can run out of the box.

If you review this description periodically and even better discuss it during project retrospectives then life will go easier and you will both get more kudos and feel like you are adding more value. 

The reason is that you will be discussing (and evolving) your understanding of why you are there and the understanding others have of why you are there.  And it means you will be focussing your energy on the key things that others also think they need from you, rather than working really hard on what you thought was important but that others didn’t think was.

Posted in Capability growth, Observations | Leave a Comment »

The “what would someone else suggest” technique

Posted by James King on August 18, 2010

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.

Posted in Decisions, Techniques | Leave a Comment »

How do you mean?

Posted by James King on August 18, 2010

I am running a workshop workshop today – a workshop on workshops.

Actually I am running a training course for some experienced facilitators and the course is about how to run workshops better.

So I have been reviewing conflict management techniques, ways of engaging un-engaged participants and issue resolution techniques.

Interestingly I have just noticed (yet again) that some of the workshop techniques (affinity diagrams and speed dating for example) work for both mitigating “strong personalities” and influencing the “passengers” to stop sitting back and start contributing.

Then I decided to throw in the question compass some abstract/concrete thinking and some fun things like options generators.

But now I have decided to lead with one of the least sensible seeming yet most useful techniques – the grammatically nonsensical question “how do you mean”.

Another facilitator taught me this one – it does not actually make sense so there is no right answer … which gets people to blurt out any answer .. which helps then explore what they really want to say.  I am not quite sure why but it frequently seems to work.

So – 10 experienced facilitators and the first and best tip I will give them is just to ask a dumb sounding question.

I will see how it goes.

Posted in Arguing | 2 Comments »

Agile release planning game downloads

Posted by James King on August 8, 2010

There are now three versions of my agile release planning game so I thought I would add them to the site so people can download them directly:

The original version

The basic game covers release planning and also the challenge of planning for new features, fixing defects and being impacted by technical debt. It works well when leading discussions about velocity charts, replanning and technical debt.

It is set on Mars and involves the team planning how to survive or leave Mars.  The version attached contains additional complexity around having the team set clear priorities (survive, continue with a scientific mission or work on leaving).  But some people prefer to ignore the scientific goals of the project to simplify the game, in which case they tell the team to focus only on surviving.  The components are:

ARPG facilitators guide v1.1     ARPG game board v1.1     ARPG glossary v1.1

ARPG iteration instructions v1.1    ARPG status report v1.1

An older version of the game had events the impact the team as well as defects and stories.  Generally I have ignored the events so I have removed them from the following folder.  So the following folder contains stories and defects … although you may find that the status report is all you need to track defects: ARPG Story Cards and events v1.1

The iteration planning / Kanban extension

The following version can be played on its own (though you will need to read the facilitators guide above and use the story cards).  Alternatively it can complement the game above if you use it to replay a couple of the iterations in the orginal game.

It is designed to focus on storywalls and resource allocation during the iteration.  The team allocate people to different stages of story development (effectively – elaboration, build and test/deploy).  Then, during the life of the iteration they encounter bottlenecks and re-assign people to provide better flow through the team. 

Debriefing this extension can lead to great conversations about “activity versus throughput” and the potential issue of testers sitting idle for a week and then being flat out for a week (and hence becomming a bottleneck).

ARPG game extension – iteration storywall v1.1

The lost alphabet extension

The latest addition to the family comes from Brazil and was created by Eduardo Meira Peres. 

Eduardo has created a simplified version that can be explained and played quicker than the original. He has also changed the problem the team face.  They no longer have to survive on Mars, but instead they must work with a tribe here on earth who have lost their alphabet. 

 The intriguing problem that the team must now solve is to use an agile process to help the team re-invent the alphabet from scratch.

I believe this extension is available in both Portugese and English, though I have only provided the english version here:

EMP_ARPG_facilitators_guide_english_v1.2

EMP_ARPG_game_board_english_v1.2  

EMP_ARPG_iteration_instructions_english_v1_2

EMP_ARPG_status_report_english_v1.2

EMP_ARPG_Story_Cards_and_events_english_v1.2

Please feel free to use any of these versions – and let me know how you go.

Posted in Games, Products | 2 Comments »

Ask the team about technical debt – the creeping doom graph

Posted by James King on July 31, 2010

I was just talking about the sad state of affairs where some teams know they are making life harder by taking shortcuts or creating workarounds that will slow the team down in the future. In fact, my grandma had some pretty good advice on this:

There never seems to be time to do things properly – but don’t worry, there will be time tomorrow to react to the crisis that resulted from  what you didn’t do properly today.

To avoid this crisis management though, here is a simple way to measure the “technical debt” we are creating today.

Put the following table up on a white board and have each team member put their vote into the appropriate box.  For politically charged projects youmay even have a secret ballot.

When we deploy our changes, the system will be … -2 -1 0 +1 +2
More complex (-) or simpler (+) than before          
Harder (-) or easier (+) to maintain and support          
Harder (-) or easier (+) to enhance or build on next time          

Rather than voting out of 5 however, they are comparing the system before they touched it to the way it will be after they deploy their changes.  Specifically their votes will be as follows

  • 0 means that there is no real change in the measure;
  • + 1 means things are better than before and +2 means a lot better; and
  • - 1 means things are worse or more complicated than before and -2 means even more so.

Now simply average the answers to give a score for each question. 

Hold regular retrospectives or reflection sessions should highlight the ongoing impact of building (or removing) complexity from your life.  But if you want a solid predictor of the impact is will have over time, try using this creeping doom graph (which can also be a virtuous circle graph if you are actively making things better each week).

Creeping doom or virtuous circle of improvement?

Or better yet - give me a call.  I will come and run a couple of workshops for the team to help them see where they are creating un-needed complexity for themselves.  And more importantly I can help them turn the creeping doom graph into a graph of positive improvement – honestly … it can be done.

Posted in Consulting, Measurement, Reflection, Techniques | Leave a Comment »

Growth or reduction in technical debt – why not just ask the team

Posted by James King on July 31, 2010

I just posted an article on measuring quality and maintainablity.  But I am waiting for my tea to boil so I thought I would start a new article.

One of the things that often interests me is that teams feel like they need to cut corners this week to get their work done even though they know it will make life harder next week.

Everyone in the team would say that what they are doing and yet everyone feels like they have to do it. So why do they keep making life harder for themselves (or for the team inheriting what they do).

One theory is that people are evil and will therefore eagerly and knowlingly make the world a worse place. But I have an alternative theory – I think that people are focusing on the things we measure – the things that are top of mind.

So I think one of the causes of stress in the world is simply that people are measuring and focusing on the time it takes to complete each task in front of them, without having time to meausre (or focus on) taking the time to make things better for the team next week.

As a partial antidote to this problem, I propose that we apply an easy measure of the impact we are having on the future ability of our team (and others) to support the work we are doing this week.

In IT teams there are ways of doing this – using measures such as code complexity and function points for example.  But they can be hard and I am lazy.  They also focus on the code and not the data, the overall design or the process changes we are making.

Another approach is to create and update a system (or process) heat map. But on top of this, we can also predict the impact we are having by simply asking the team what they think will happen with the work they are doing.

I will post a couple of ways of doing this – but more importantly, why not just do it?  Next time your are in a team meeting, implementation planning session or restrospective, just ask the crew

  • Whether what they are doing this week is making life easier for themselves and others next week; and
  • What they would do about it if it was up to them.

I bet they can answer both questions quite clearly … and I bet life would get better if they (and you) acted on the answers.

Posted in Measurement, Reflection | Leave a Comment »

Measuring quality and maintainability

Posted by James King on July 31, 2010

We often say that we are focused on quality and yet only report on time and money when reviewing our projects. 

Or we report on “the number of defects” but not on the actual “quality”, not “the ability to maintain this system when we go live”.

I think this is because people often thing that measuring quality and maintainability is hard. But here is an easy (if not fully robust) approach to measuring quality.

Each retrospective (or team meeting or implementation planning meeting) we can ask the team to report on their own perception of the quality of the work they are producing. But rather than asking for an objective measure of quality, we ask how they view their work compared to last time (the last iteration or a typical project done by the team).

To do this we ask a question and score the answer as ”0″ if the quality (or other factor) is the same as usual.  If it is better (or a lot better) then the answer is +1 (or +2).  On the other hand if it is not as good as usual then the answer is -1, or -2 if it is a lot worse than usual.

For example we could have the following survey for the team to complete prior to the retrospective:

When we deploy this into production … -2 -1 0 +1 +2
The quality of what we produced will be …          
I will be proud of what we produced                         
Production support’s feedback will be …          

These ratings are not designed for a project office to use in assessing projects against each other but rather for the project team themselves to use in deciding how they are travelling and how to tune their own performance.

Posted in Implementation, Measurement, Techniques | Leave a Comment »

Estimating the impact of technical debt on stories – heat maps

Posted by James King on July 31, 2010

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.

Posted in Consulting, Decisions, Implementation | Leave a Comment »

Questions for project audits – part two

Posted by James King on July 24, 2010

When auditing a project (or taking over a project or even taking on a senior role in a team) I like to go and talk to everyone in the team.

When I do, I generally ask them the same questions to get a better feel for what is going on.

I really liked a set of questions I picked up from a book called “The First 90 Days”, so I use a modified set of them:

What is your role?

  • What does that mean?
  • How would you explain it to my mother?
  • How would others explain what you do?

How confident are you the project will meet it’s objectives?

  • What are the objectives?  Really?
  • How clear are you on the objectives?
  • What do management think the project is doing?
  • What do others think?
  • If it fails, where will it probably have gone wrong?

What is the biggest issue facing the project?

  • What would happen if we could get rid of that problem?
  • What would need to change to get rid of it?
  • How could we deal with that problem?
  • How is it impacting us/the project?  How does it impact you?
  • How are we currently dealing with it?
  • Why is it still there?  What is stopping us deal with it?
  • What should we do about it now?

What is the biggest unexploited opportunity in the team?

  • What would have to change for us to exploit it?
  • What would happen if we did?

What would you do if you were me?

Most projects are really really complicated.  But most people know how well it is going or how scary it is if they have time to think about it.  So I find you get a pretty good overall understanding if you just ask everybody these questions.

Posted in Investigation, Reflection, Risk | Leave a Comment »

« Previous Entries