Month: July 2010

Ask the team about technical debt – the creeping doom graph

On By James KingIn Consulting, Measurement, Reflection, TechniquesLeave a comment

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.

Advertisements

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

On By James KingIn Measurement, ReflectionLeave a comment

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.

Measuring quality and maintainability

On By James KingIn Implementation, Measurement, TechniquesLeave a comment

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.

Estimating the impact of technical debt on stories – heat maps

On By James KingIn Consulting, Decisions, Implementation1 Comment

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.

Questions for project audits – part two

On By James KingIn Investigation, Reflection, RiskLeave a comment

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.

Questions for project audits – part one

On By James KingIn Investigation, Leading change, Measurement, Reflection, RiskLeave a comment

I was talking to a colleague recently and promised to share some of the questions I ask when auditing a project (or taking one over).

My first question is generally “what is the project about?” But that generally leads to a vague answer.  So I use my “question compass”:

My question compass

These are the questions I use to get a basic orientation when analyzing just about anything.  By way of explanation though, I don’t always use the exact wording shown.

When asking “what do you mean” I use a technique that sounds really simple and is surprisingly effective – the “nouns and verbs” technique.

I listen for a noun in a sentence and then ask “what do you mean by ‘noun’?”.  When I get a response I ask about one of the verbs in the response “How do people currently ‘verb’?” or “How do you envision people will ‘verb'”.

I keep doing this for a little while even if I think I know what people mean because it is amazing how often it clarifies my understanding.  Then I pick one of the things the person said and ask “why are we doing this project?”.

I do use the famous 5-whys technique to probe more deeply (ie ask why several times) but I also add the question “why else?”.

I was once told that we do things for two reasons – the right reason (the one we tell people) and the real reason.  I think it is a quote from someone famous.  But it certainly clarifies my thinking when I ask this question.

My next question is “Is that true?” and I ask this one in a number of ways:

  • What would the team say the purpose is if I asked them?
  • Do all the steering committee share the same understanding?
  • How do you know that is true?  How do others know?
  • How would you know if that was not the case? (my favourite question).

Almost there – but I still have one last question – “So what?”.  Like asking if something is true, asking so what can seem a bit blunt.  So I ask it in a couple of different ways:

  • What impact is that having?
  • What would happen if we didn’t do it?
  • What would the impact be over the long term if we don’t do it?
  • What will happen if we do it?  What else will happen? What won’t happen?
  • What are you hoping won’t happen if we do that?
  • What will the team/customer say when it happens?

After these questions I generally at least have some idea of what is going on – which is often the best place to start.

Recent photos

On By James KingIn ObservationsLeave a comment

I took some photos in a recent workshop and when I was emailing them I came across these ones on my phone.

When I grew up in Western Australia we had corny number plates like “WA – the state of excitement”.  Similarly, in NSW we have the phrase “The premier state” on some number plates.  So I was quite impressed with the different approach they used to a number plate I saw in Brisbane recently.

A number plate from Brisbane

On a separate trip I came across the following plaque that had been placed in the footpath to highlight some local history:

Highlighting our local history

Not very business focussed I suppose – but I thought both photos were worth sharing.