James King

What you do next matters

Archive for the ‘Implementation’ Category

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 »

Agile and ITIL – Handing over knowledge

Posted by James King on May 23, 2010

At first pass, agile and ITIL approaches may seem like natural enemies.  This is certainly true if :

  • Agile is for cowboys who evade testing, write code without knowing why and think that documentation is close to pure evil; and
  • ITIL is a pack of non-thinking drones who create multiple unnecessary roles, random gateways with no purpose and document everything in sight without knowing why … including the average length of the carpet in high traffic corridors.

Where the zealots rule, the only thing that agilistas and Itilists will agree on is that one of them is fundamentally wrong and must be stopped.

But when they actually listen to each other they will discover something interesting:

  • ITIL has a very good knowledge management process hidden in its mist (Knowledge Centred Support) that says that we should record and solve problems by referring to a known list of symptoms and predicted root causes. Then if we don’t know the answer we should iteratively solve the problem and evolve our knowledge base for next time.
  • Good agilitstas  says that we should iteratively evolve our knowledge as we solve problems and start to better understand root causes rather than work on symptoms.
  • Both say mailing an out of date requirements document to a support team is pointless and both say that we need to collaborate on building our knowledge.

So here is a predictable outcome when good agilistas meet good itilists.  We all agree that we need to collaborate to evolve the knowledge needed by a support team.

  • The agilistas have this knowledge and believe that it should only be documented if it is fit for purpose; while
  • The itilists have the process and the “fit for purpose” documents that can replace large and wasteful requirements documents for support teams .. but  want someone to collaboratively build their knowledge based on the things the agile team already know.

So – when they actually talk to each other about effective support and about looking after the interests of their clients and their teams (rather than zealotry and what someone told them to think) then they find that they are actually a really good team.

Posted in Implementation, Observations | Leave a Comment »

Delegation part 1

Posted by James King on April 4, 2010

I believe that a lot of decision making is negatively impacted by unclear delegation.

The result is that both the delegator and delegatee (if such words existed) want the right outcome and behave intelligently – but act on different information or assumptions.

So it should help when delegating decisions to a group, if you am really clear on what decision you want made :

  • Not just the item that is up for discussion but also whether people are helping you decide what the solution should be or just how to implement the solution that has already be decided; and
  • Not just whether you want to talk about a decision but what outcome you want to achieve in the meeting.

For example – pick one of the following for the decision in question:

  • I have made a decision and I want to explain it to you, as well as get your feedback;
  • I am going to ask for your ideas and then make a decision;
  • We are going to decide this together, but I will decide if we cannot reach agreement;
  • We will decide this together and we need to all agree before we move forward;
  • Let me know what you want to do as a team and I will back you; or
  • Everyone can decide their own course of action separately after we have discussed the decision.

Similarly – set one of the following as an expectation before you ask the group to make a decision – At the end of this discussion:

  • I want everyone on board with the decision and acting on it;
  • I want the decision made, but we can come back later and talk about how to implement it; or
  • I want everyone to go away and think about it, so we can come back and make an informed decision later.

It often surprises me how a little clarification leads to a realisation that we were much less clear as a group than we thought we were … which means we were probably wasting our energy working in different directions.

Posted in Decisions, Implementation | Leave a Comment »

Small experiments vs planned execution of change

Posted by James King on January 17, 2010

I am working with a client who has a whole continent full of different “tribes”, all of whom are going agile and all of whom have huge change agendas on at the moment.

So I am working on a change management plan to help the organisation roll out consistent approaches to IT development and to demonstrate continued improvement in speed and quality across multiple development teams for multiple internal and external clients (the tribes I mentioned).

I think I have a cunning plan but it will be interesting to see how it plays out in reality.  Rather than rolling out a structured change program I am recommending we let all the cowboys run wild and do whatever change they want.

Then instead of driving change, the central group responsible will define the rules for experiments so that:

  • When a group want to try a new idea they must first report in that they are doing so.  They do not need permission but need to state the experiment they are performing, why (which can be as simple as “make life easier for ourselves), when the first phase will happen and most importantly – what they predict will happen.
  • Then at the end of each phase we will check whether the outcome was as expected.  If it is then we will ask why and then see how we can share the knowledge more widely.  If the result was better or worse than expected then we will ask why and see what we can change or roll out more widely.

Doing this will help our central team focus on some core activities which we can also treat as experiments.  It will also allow individual tribes to move at a pace (and in a direction) that suits them rather than waiting for us to catch up.  Of course it might also lead to chaos, lack of focus and inertia.

Give me a call in a month or so (or add a comment here) if you want to learn how it turns out.  Or give me a call now if you think you know how it will turn out and want to warn me.

Posted in Capability growth, Implementation | 1 Comment »

Help with implementation of change and projects

Posted by James King on September 12, 2009

Even when you have an understanding of what the organisation needs, it can be difficult to implement the right solution effectively while so many other things are going on.

I specialise in supporting your team in effective implementation of a range of initiatives.  Where projects are large and complex, I also recommend trusted partners who I know have a track record of delivering the projects that I have seen others struggle with.

The specific support I can provide to you is:

  • Change management action and communication plans.
  • Change management delivery.
  • The rollout of integrated (or “blended”) learning solutions.
  • Assistance with improving team effectiveness.
  • Introducing Agile approaches to development teams.
  • Introducing continuous improvement approaches to service delivery teams.
  • Implementing process improvements in service delivery and project consulting teams.

To find out more about these services, you can browse the articles in the Implementation services category (coming soon).
You can also call me on +61 4 21 058 459, or email me at james@kingsinsight.com

Posted in Implementation | Leave a Comment »