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.

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.

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. 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 , , , , | Leave a comment

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

Principles of Agile Governance

I first wrote about governance of Agile projects three years ago, when I was developing a governance approach at a DSDM development site. That work, and the work I have done elsewhere since, have further convinced me of the basic ‘correctness’ of that theory. I presented that theory at the Agile Business Conference that same year to a very interested audience.

Fast-forward to the present day and I was recently invited to attend a meeting of the APM Special Interest Group (SIG) on Agile Governance. The APM are working on a Guide on this topic and are keen to elicit opinion and insight from far and wide. When the meeting broke up into break-out groups, I attended the one focussing on the Principles – the one where I thought I could be most helpful. The principles I put forward are what I believe to be some of the guiding principles by which an Agile governance authority – however that is manifested in your organisation (perhaps the PMO, perhaps a separate body) – ought to run the portfolio of projects. They are, in no particular order :

  • People and accountability. Good governance comes from having the right people accountable for delivery, and the quality of the solution delivered. I have blogged before about the need to have the companies Security Officer (or equivalent) responsible for application security and to be accountable for the security of any application development being implemented. Similarly, Marketing should be accountable for the look-and-feel of a web-site development. And the Governance Authority should be people who have no vested interest in the outcome of the project – but they are accountable only for ensuring that it is conducted properly. If, for example, the person responsible for managing the governance process is accountable to the Head of delivery, governance will achieve only what is in the best interests of the Head of delivery. If he/she is paid to deliver more projects, then more projects will go live, even bad ones.
  • Ensure projects are adequately resourced. No project should start unless it has the resources (people, knowledge, skills, tools, equipment, etc) to ensure at least a realistic chance of success. There are no guarantees in life, but every project needs to be given every chance to succeed, and starting a project with only half the people it needs – or with poor equipment, a lack of meeting space, or anything else a successful project needs – is the road to failure.
  • Scale the governance to the project/programme. Avoid unnecessary bureaucracy, but ensure the project is under control. Good agile governance should promote agility by encouraging good agile practice. But such practices and the controls around them need to be adapted to the needs of a project and the people working on it. For example, the governance of a year-long project developing an entirely new product line and all the attending infrastructure needs to be governed differently to one involving a two-month long enhancement to a web site.
  • Review viability frequently. Consider whether all the elements that contribute to success are still in place all the way through a project. One way to do this is to review at every iteration boundary (or every Steering Group meeting) whether the project is still on track to meet the business case, achieve it’s vision, and deliver the planned scope on time and within budget. Consider whether the direction or solution design changed significantly. What happens, for example, if one key person leaves, and takes a few of his friends with him? Is the project still viable? Probably not, and that needs to be recognised and addressed. The job of Governance is to highlight the issue and assist the project team to resolve it.
  • Transparency. Ensure all pertinent information is widely available – on walls, dashboards, etc. It should be the responsibility of governance to ensure a project team are not hiding any bad news. All stakeholders should be aware of the true status of the project, which leads onto…
  • Fact-based reporting. Measure real progress, through delivery of valuable solution components at regular intervals. “We are 80% finished” means nothing unless that 80% can be (or has been) tested and, if necessary, implemented. Don’t measure progress by the subjective reports by PMs, so typical of most organisations – they are not always reliable.
  • Do ‘just enough’ planning throughout. This can be considered more a project management principle than a governance one, but it is also the job of governance to encourage speed to market, and early benefits realisation.
  • Ensure adequate contingency is available. Whether in time, cost or scope, different projects need to fix different elements of that triangle. Governance should check that sufficient contingency exists on an appropriate axis/axes.

I don’t know whether any of the above will find their way into the APM Guide, but I may soon be able to refine these further and put them into practice myself once again. Watch this space.

Posted in Agile | Tagged , | 1 Comment

The core of Agile

Peel away the layers of agile practices, dig down through the principles and values of the Agile Manifesto, and what is at the very core of Agile is one simple objective and two activities.

The objective is Risk Mitigation. Think about it – all the practices that distinguish Agile approaches – daily stand-ups, user stories, test-driven development, pair-programming etc – were adopted in order to reduce the risk of project failure inherent in predictive or plan-driven methods.

The two basic activities we employ in this risk mitigation exercise are Collaboration and Learning. These are the two main factors that make Agile what it is and make it work. Keep these two things always in your mind. In every task, think to yourself “who should be involved in this activity (and how) in order to make it most effective”, and “what do we need to learn most, and how do we discover the answers as quickly and cheaply as possible”.

All of the principles and practices in agile boil down to those fundamentals. Is it really so simple?

Collaboration

Consider cross-functional teams, co-location, stand-ups, user stories, facilitated workshops… All are examples of practices and disciplines designed to amplify collaboration. Because two heads are better than one. Because the wisdom of crowds is better than any individuals. Because it is more effective and efficient to get people in a room together to decide something than it is to share emails for weeks on end. Because there is no more effective form of communication than face-to-face.

Learning

Iteration, architecture modelling, story mapping, show-and-tells, prototyping, pair-programming… all examples of agile practices designed to amplify learning. Learning is important because we recognise that not only do we not get the requirements set exactly right the first time and realise it will change, we also don’t know whether the solution we create will exactly meet the users real needs. So we need to learn about those things as quickly as possible. And continue to do so until the project’s objective is met and the customer is delighted.

This may be an over-simplification of a complex subject, but when the conditions for running ‘pure Agile’ simply aren’t all there, it pays to come back to the essence of what Agile is and why it works.

Posted in Uncategorized | Leave a comment

Role Playing games as Agile educators

One day some years ago, I spent a couple of hours in the car while my son – then aged about 13 – told me all about what he’d been doing recently. What was occupying most of his time was World of Warcraft and he was now online playing this most iconic (apparently) of MMORPGs. I sighed in frustration. Gone were the days when he used to spend his afternoons and evenings playing football or cricket with his mates; now it was online games with virtual friends. This wasn’t doing him any good at all. Or so I thought.

But as I listened to him tell me about how the game worked, and the people he was playing with, I realised that there was a lot more to this than time-wasting. And when he asked if he could play when we got back to my place, I agreed, wanting to see more.

Firstly he used my desktop PC to log into his Warcraft account, but then had his laptop beside him, logged into a voice-chat application using my headset and microphone to talk with other players. I learned that:

  • His ‘raiding team’ had people playing defined roles (Tank, Healer, DPS) based on the characters they adopted and their inherent skills
  • They had a team leader, who ….
  • They met online specific times
  • They set specific goals and objectives each time they played
  • They collaborated to achieve an objective, sometimes sacrificing themselves for the good of the group
  • They communicated constantly during the game.
  • The reflected on their successes and failures after every mission.

Does this sound familiar? Does this sound a little like an effective Agile development team holding stand-ups and  retrospectives? My son, I realised, was doing more than just game playing as entertainment, he was actually learning skills at a young age that some employers tend to take for granted – clear and concise communication, how to collaborate in a group, true teamwork, negotiation,  leadership, empowerment and delegation. It can take some people years to learn these skills in the workplace, but the dynamic nature of Warcraft and the way the teams are structured meant that he exhibited the sort of behaviours that we train and coach into our agile teams. He even learned that no two guilds are the same, and he needed to find one that met his objectives too.

 

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