This blog is moving

After more than four years on WordPress, this blog will soon be moving. I now have my own website at and all the content of this blog has already been moved there. The content on this site will, at some point, be deleted.

Please pop over to and check it out. There is an RSS link at the bottom of each page so feel free to subscribe to updates and get new content in your Inbox. I will happily take on board any constructive criticism on the website while you’re there.


Posted in Uncategorized | Leave a comment

Planning poker without cards

I recently introduced a new Scrum team across two sites to the practice of planning poker. While they had never done estimating in this way before, the idea was readily accepted and they seemed excited to start. It was never going to be quite so easy over video-conference, but better than not doing it at all, right?

I brought in my two decks of planning poker cards, and immediately someone asked if he could use the app on his smartphone. I agreed he could. Then someone on the screen at the other site asked what app that was and could he download it. I watched on in amusement as everyone, both those in the room with me and those on the screen all picked up their phones and a few minutes later we were holding up our phone screens with numbers on them.

It is, perhaps, a sign of the times that we use our smartphones for so much that we feel like we should be using them for everything possible, even story estimating. It was certainly the first such session I have ever been in where no planning poker cards were used at all.

Posted in Agile | Tagged , , , | 1 Comment

Career transition

Over the last couple of years, I have transitioned from being employed by an insurance company trying to be more agile, through being employed by a small consultancy on-site at clients doing agile project management and coaching, to where I am now – an independent Agile Coach and consultant.

While I can and do act as a Scrum team coach and mentor, my speciality is helping clients with those things that are getting in the way of a team improving its Agile performance, particularly when Scrum isn’t enough. I help the team keep as agile they can be while working in a highly-structured project environment, utilising frameworks like DSDMs AgilePM and AgilePM-for-Scrum.

Rather than working directly for the Scrum team, I work with the senior managers to help them review things like organisational structure, roles and responsibilities, Agile sponsorship, governance, getting active business engagement and so forth. A lot of companies, including my current client have a large portfolio of projects and programmes of all sizes and they have found that Scrum alone is not enough. That’s where I come in.

In the last few weeks, I have been working with two project teams with some common challenges, but also with some vastly different challenges. As I’ve said before, every project is different and requires slightly different tailoring of Agile to make it suitable. I will be writing about some of those experiences here over the next few months. It’s all very exciting, I can tell you.

Posted in Uncategorized | Leave a comment

RAG – What are you measuring?

I am continually surprised by how many traditional activities and behaviours survive long into an agile transformation. The Red/Amber/Green status reporting is one of them. Even allegedly Agile people seem to hang on to the RAG status like a comfort blanket, but in my experience, it has little, if any, benefit. And the reason is that each status colour causes certain behaviours, which are, at best, served in other ways, and at worst are counter-productive. After all, what are they actually measuring? A subjective opinion on the part of the person doing the reporting of the status of the project. Or rather, what he/she wants the stakeholders to hear.

What happens when the status report is Green? In my experience, few busy executives read any further. If the status is Green, why should they worry about it? Mentally, they may pat the project manager on the back and think ‘Good man, that. He’s on top of things.’ but that’s about all. And what’s wrong with that? It creates in some, an incentive to be… economical with the truth, especially in an organisation which lays responsibility for delivery with the project manager and not the Business Sponsor. I know of more than one person who has reported a project as Green in order to be left alone to fix the problems he knows he has, instead of being transparent and setting expectations based on facts. I recently spoke to a Head of PMO who said she uses the term Watermelon Green to refer to projects which are Green on the outside and Red when you open them up and look inside.

An Amber status is often a bit of a cop-out. It says ‘I’m not 100% comfortable with how this project is looking at the moment, and I’m just covering my own rear in case things get worse. The same Head of PMO calls this Institutional Amber, so prevalent is this.

And a Red? In some organisations, this is taken to mean the project manager and the team have major problems they cannot handle. In some cases this results in the project manager being replaced (for no reason other than honesty) instead of fixing the cause of the problem that led to the Red status being reported in the first place.

RAG status codes are more often than not ambiguous and interpreted differently by different people, although I know of one company that created a formula based on cost, milestone and other measures to derive a RAG status. Interestingly, the validation allowed a project manager to override the status upwards, but only a Sponsor could downgrade it.

But it’s still a lot of nonsense to accomplish something really simple – understand whether a project is on track or not.

 So what do we do differently? Simple – report facts and leave out the subjective status codes. That way stakeholders have to hear the full picture. In Agile projects, there is no substitute for regular demonstrations of actual progress to stakeholders. And if some sort of regular status reporting is required, replace the RAG status with a graph – either a burndown (or CFD) chart of progress within the current iteration, or a bar graph showing work remaining (or completed) in each iteration. Or both.

There is nothing that a RAG status will convey that a graph of actual performance won’t convey better.

Posted in Agile, Business | Tagged , , | Leave a comment

Agile game: MoSCoW prioritisation

I recently developed and presented a one-hour ‘master class’ on MoSCoW prioritisation. It’s not a hugely complicated topic, and one I have written about before. This time, though, I was able to talk people through the process of going from project priorities to increment priorities to timebox priorities, and how prioritisation leads to feature-contingency. As part of that presentation, I created a short exercise to demonstrate how to prioritise, the things you learn in doing so and the importance of having the right people present, including those who set the project vision and define the business case.

I created a set of 16 user stories and wrote them on 5″ x 3″ (127mm x 77mm) cards based on reverse-engineering a smartphone app. The app I chose was Pay By Phone but any application that has some practical real-world use would work just as well.

The game worked like this :

Ask delegates to work as a team, but without talking. Standing around a table, they need to place each of the 16 story cards into one of four columns headed “Must”, “Should”, “Could” and “Won’t”. This represented the prioritised requirements list for the project. Emphasise to the team that only the Must Have requirements are guaranteed to be delivered, so they should ensure that those requirements in the “Must” column represented their definition of the Minimum Useable SubseT (or Minimum Viable Product (MVP)). When a card switches columns more than once, pull it aside for later discussion. The game ends when all cards have been placed in a column and no more cards are being moved.

The objective of the exercise was to see whether the group understood the MoSCoW definitions and what comprised the MVP.

The exercise proceeded well and in less than 10 minutes everyone stood back from the table. There were two cards pulled aside.

The requirement to levy a charge each time a parking transaction was completed was a Must Have in one person’s mind (based on the assumption that this was how the app generated revenue) but a Could Have in another’s because he thought the app might be paid for.

I was surprised to see that one requirement – the ability to pay by credit/debit card – was also one of the controversial ones. I deemed it the core reason for the app itself and an essential part of the MVP. Someone else thought that the app was for booking a space, not for actually paying for it.

Both of these provided clear evidence of the need for a project Vision and/or Business Case before running this exercise in real life. Or at least called for the involvement of a Sponsor or Business Visionary / Product Owner to provide that guidance.

To my satisfaction, the two requirements I made up were allocated to the Won’t Have column, as they didn’t generate much value.

If you have played this game (or a variant) yourself, please tell me about it in the comments section below. If you’d like to see the user stories I wrote, just ask and I will send you a list of them.

Posted in Agile | Tagged , , , , | 2 Comments

Do we really need projects?

In an Agile sense, you probably work in one of two types of companies. While there are certainly hybrids of these two examples, bear with me for a while.

The first type are IT-focussed, <em>tech-savvy</em>, often relatively new companies. They sell stuff online generally or at least create products that require frequent changes or improvements.

These Type A companies have an IT infrastructure that was designed from day one to allow concurrent development, integrated testing, continuous integration, perhaps even continuous deployment, because updating their product frequently is important, both to them and to their customers.
These companies have evolved their entire operating model to continuous and rapid improvement of existing – and new – products. They practice Product Development and everything they do is geared towards that.
IT is structured by product lines, directly answerable to the business, their recruitment, personal development, organisation structure, processes, their entire culture is driven by the need for constant change.
They will generally practice Scrum or Lean, possibly with XP, perhaps using something like SAFe if they are large enough to warrant that.

The  other type – Type B – comprises those more traditional, older companies, like banks, insurance, pharmaceutical companies and the like, companies where IT is not central to their core business. It’s not that IT isn’t important to them, but that IT is not integrated into the business, it’s a separate function. Some were probably founded a hundred years ago and IT became a necessary evil around the seventies, but it was difficult for most people to understand so it became a cost-centre, an expensive overhead. The systems were huge mainframe-based systems most of which still exist to this day. Changes to these systems take time, partly because of the complexity of the systems, partly because they were not designed for modern integrated testing practices and tools, and partly because the changes required are usually substantial in nature. They are often in heavily regulated industries and one change of regulatory regime results in a two-year change programme. Not one ideally suited to agile development, but one with a clearly defined goal, highly detailed and fixed requirements, an immovable deadline and often cost constraints as well.

So when we consider how to apply Agile at each of these types of companies, we need to be conscious of their vastly different needs and environments.
While type A implements change through continuous Product Development, type B implements change via projects. Why? Because they need to. Because sometimes there is a need for a Sponsor, for governance, for solution architecture.
In this environment projects make sense; they have a whole portfolio of them.
So the next time you say to someone “you don’t need a project manager or a Sponsor or a contract”, think again. And instead ask “so how agile can you be? Let’s do that.”

Posted in Uncategorized | 2 Comments

Agile – one size fits all?

Almost every day I read about doing agile ‘properly’. Some people are asking what is the right way to do something, others (including me, it has to be said) are giving their views on what works for them. For someone new to agile – perhaps considering adopting it in their workplace – it is potentially very off-putting, as it may give the impression that we agilists actually can’t agree on what’s right and what isn’t; that agile is actually just a bunch of techy geeks making it up as they go along in ill-disciplined fashion. But that’s not true.

Continue reading

Posted in Agile | Tagged , , , | Leave a comment