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?


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.


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

Two Agile worlds

There is a recurring theme that has been around the agile community for a while now. One so pervading the industry that I have spent quite some time reflecting on it.

Have you noticed that people are questioning the very nature of Agile itself? What IS Agile, people are asking. Is it a set of practices? If so, which ones? Some basic values and principles? Then how do we live them in our workplace, it seems too hard. What do you mean there’s no place for a project manager in Agile? We have loads of them! Speak to people at a conference or two, or even just read through the Agile LinkedIn groups forums and there are lots of examples of this type of question.

These questions (and others) are symptoms of the difficulty some people are having trying to apply ‘agile’ in their own environment. Let’s face it, an internet startup like Groupon or Twitter or Snapchat has a completely different environment to a multi-national Investment bank, a local government department or a defence contractor. A small company trying to figure out what its fledgling product will look like when it’s launched will have a different set of constraints to a company with an old and complex multi-platform architecture with development teams spread across three cities in two countries, a limited budget and a larger portfolio of planned projects than they have people to deliver them.

There are those who believe that Agile means Scrum. And/or XP. It means a small cross-functional team co-located, and delivering in short iterations to get a minimum viable product (MVP) to market as quickly as possible. And then delivering updates as quickly as possible based on feedback from real customers. The Lean Startup model. And these people are passionate about Agile. They live and breathe collaborative estimating and planning, test-driven development, continuous integration and one-click automated deployment. They have no need for project managers with their Big Design Up Front and detailed plans, nor system architects, or sponsors. And don’t even mention governance or… (deep breath) the project management office (PMO). For them Agile is lightweight, non-prescriptive, and fast-paced. It is lean (with a small L).

And there are those for whom this is anathema. Or a distant fantasy – a utopia beyond their wildest dreams. For they believe that their projects just cannot be run in this ill-disciplined manner. That projects need management, and planning, that a portfolio of projects needs governance. That there is a place for Business Analysts and platform-specialist developers, technical co-ordinators, change management teams, and yes the PMO as well. That implementations to Production (of multiple projects) happen maybe once a month (or longer), because there is complexity in parallel development. In this environment the involvement of external suppliers and lengthy contracts are the norm, tools for test-driven development won’t work with the platform and not everything is under source control. The approach to software delivery here is geared around projects – structured, planned endeavours with specific goals and usually a defined end-date.

As you can see, these two worlds (in the extreme examples I illustrate) are very different. Neither is right, neither is wrong. They just are. I call these worlds the Product World and the Project World respectively.

Our beliefs about what is right and proper are generated by our own experiences, knowledge and skills. Those who have experience only of the Product World have a fundamentally different view of what Agile is, and is supposed to be, than those whose only experience is of the Project World.

So we need, I believe, to recognise that these two worlds are very different, and that the same approach to Agile cannot work across both – there is no single transformation recipe, no one ‘best practice’ or method. That each organisation needs a deep understanding of the values and principles behind Agile, and work out the best way to live them in their own organisation. That what is right for one company is not necessarily right for another. And that we should all stop telling each other what is the ‘right’ way, and do more to discuss and learn about other ways in other environments. Sure there are things that we can all learn from other people in different environments, but we can’t assume that they will work the same elsewhere.

Agile is so much more than just a set of practices, and it is not a recipe book. Agile is a philosophy; a way of thinking. And all we can do is be as Agile as we can be, given the constraints under which we are working.

Posted in Agile | Tagged , , , , | 1 Comment

Hansei and “being negative”

The success of a change program is dependent on many things. One of them is how the organisation deals with change. And how they learn what needs changing and whether the change was effective once introduced.

I was reminded of this while reading The Toyota Way, (J K Liker, 2004). Chapter 20 discusses Principle 14 of the Toyota Way – “become a learning organisation through relentless reflection and continuous improvement.”
It explains Hansei and Kaizen as concepts and practical tools. Kaizen has found it’s way into the Lean software development community, but this was the first time I came across the word Hansei. It means deep reflection and is the root of Kaizen.
As the author explains, Toyota found it difficult introducing Hansei into their American plants because of the cultural differences. In Japan, when a mistake is pointed out, whoever made the mistake is usually the one pointing it out, or at least accepting it, then reflecting deeply on why he made the mistake and what he can do to improve so that he doesn’t make the mistake again. It is seen as a positive thing; as an opportunity. In the West, having a mistake pointed out is taken as a sign of weakness and is seen as a negative.

Some time ago, I made my colleagues aware that a particular process was lengthy, bureaucratic, wasteful and expensive. A short time later, the CIO asked me for a chat and asked me why I was “being negative”. I was confused, and explained that, to my mind, I wasn’t being negative, I was looking for the negatives as opportunities to improve – a positive thing, I thought. But my comments were perceived as making waves, disrupting the status quo.
How, I thought, could you identify where change was needed unless you looked for the negatives?! Seeing the negatives and trying to improve them is not the same as being negative. Being negative is thinking we can’t – or won’t – improve.

The concept of Hansei is lacking in western organisations. The agile retrospective comes close, but the sort of deep and careful reflection that is Hansei requires a change of mindset similar to that required to really understand the nature of Agile itself.

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

Agile Methodology wars

Methodology (n) 1. The system of methods and principles used in a particular discipline. 2. The branch of philosophy concerned with the science of method and procedure. 3. An organised, documented set of procedures and guidelines for one or more phases of the software development lifecycle. 4. A pretentious way of saying Method.

Since 2001, when the Agile Manifesto was published, “Agile” adoption has grown steadily worldwide, to the point where, in 2009, Gartner declared “agile is now mainstream”.

But what, indeed, IS Agile? There are different views on this, but Agile does not necessarily mean Extreme Programming (XP). It doesn’t necessarily mean Scrum either. Lean/Kanban? Nope. DSDM? No, not that either. Fundamentally, Agile IS the manifesto and the underlying principles. It is, as Alistair Cockburn says, about Self-Discipline, Self-Organisation and Self-Awareness. It’s not about what you do, but about how you do it. In other words, it’s not about the Method.
Alistair spoke at the Agile2009 conference about the need to view Agile in the context of the larger landscape in which it now sits. Agile needs to be scalable, and for some companies that is proving difficult. And the larger you grow and the bigger your agile projects, the more you need formality, structure and governance. In other words, Method. That does not, however, mean abandoning anything in the Manifesto.

Agile originated in the context of small, co-located, cross-functional teams. That Agile principles and practices are now being used in thousands of organisations worldwide at a scale possibly never imagined by the original authors is a Good Thing, and a testament to the inherent ‘rightness’ of the thinking that went into the Manifesto. But Scrum (on its own) doesn’t scale. A large organisation embarking on a 5-year, $155m program with a couple of hundred people involved across ten countries cannot rely on Scrum alone. But that does not mean they cannot be Agile. Far from it.

Scrum lacks the Project view (search the Scrum Guide for the word “Project” and, as a noun, it is used only once : “Each Sprint may be considered a project with no more than a one-month horizon”). Scrum is not designed to work in a project (“a temporary endeavour undertaken to create a unique product, service or result”) environment, as it does not consider team-building, requirements generation, architectural design, high-level planning, etc, etc. It lacks Programme, Portfolio and Enterprise Architecture views. Oh, and before the Scrum people jump down my throat, I must clarify that XP, Kanban and DSDM don’t consider all these views either. DSDM goes one step further than Scrum with its focus on Projects and just enough high-level up-front planning, but still, there is stuff missing.

Clearly, Agile has for a long time now, required a wider view of the world, to put the iterative development cycles into an Enterprise context. Scott Ambler developed the Disciplined Agile Delivery (DAD) framework and the SDCF and Dean Leffingwell is constantly evolving the Scaled Agile Framework (SAFe), both of which attempt to illustrate this big picture in an agile context, creating the environment in which development teams can thrive down at the Sprint/Iteration/Timebox level.

While I will leave you to read about both of these at your leisure (if you haven’t already), I was rather surprised to read that Ken Schwaber, no less, has had a little rant at SAFe, although not so much about the approach, but “turning that and RUP into a product and [licencing] people to implement it”; people “touting their processes and tools” at Agile2013. Ken’s objection is that “they are now pushing SAFe as a simple, one-size fits all approach to the agile organisation.”

This criticism of the commoditisation of Agile has already been levelled at Scrum. After all, how much knowledge and experience does it take to become a Certified Scrum Master? Two days and under £1000. For a lot more money (and not much else), you could be a Certified Scrum Trainer. Mind you, it takes only a week (and a heap more money) to be certified in PRINCE2, so this is nothing new. An entire industry has been created to provide training, coaching and transformation consultancy to companies small and large. Agile IS a commodity, and a lucrative one for some.

Quite frankly, this is all starting to sound a little like Methodology Wars. And it needs to stop. The Manifesto and the vast quantity of excellent publications by notable authors like Mike Cohn, David J Anderson, Tom and Mary Poppendieck, Gojko Adzic and many others are muddying the waters for those still trying to find out what the actual heck Agile really is. Yes, we do value individuals and interactions over processes and tools, but frankly, a little process now and again is also a good thing. And we need a little framework in our lives when we want something to act as the basis for setting up our whole organisation to be properly agile.

I think what a lot of companies need is a ‘steer’ – some principles, a rough guide or a framework, that will help them deal with all those things that are necessary for a Scrum (or XP or DSDM) team to thrive in a large and complex organisation. Things like Governance, like Portfolio, Programme and Project management, like HR, resourcing, organisational structure, empowerment, enterprise architecture, etc etc.

Perhaps the time has come for another gathering of the good and the great agilists to agree a new Manifesto – the Enterprise Agile Manifesto, or the Agile at Scale Manifesto. It might not even take three days.

Posted in Agile | Tagged , , , , , , , , , | 4 Comments

Killing Agility

In their iconic book “Peopleware”, DiMarco and Lister said “I can’t tell you what to do to get a team to gel, but I can tell you 100 things that will prevent it”

A similar thing applies to Agile. A lot has been written about how to become agile – what practices to use, and what principles and behaviours to adopt. Little, however, has been written about what can stop an agile transformation in its tracks. There are a number of things that can undermine or derail an agile team or company, especially one in transition. One day I might write that book, but the focus of this post is just one such factor – individual KPIs (Key Performance Indicators).

I was recently made aware of an organisation that did an ‘audit’ of user stories and concluded that they were not of a very good quality. Management, typically, decided that to improve this practice, KPIs were needed. So someone asked the members of the Business Analysts practice to come up with their own KPIs.

Here are some of them, and why I think they are a Very Bad Idea :

1. Percentage of projects that have prioritised and estimated requirements – If the perception is that 100% is perfection, teams will be motivated to put any priority and estimate against the stories, just so they don’t ‘fail’ the metric. So in some cases, the estimates and priorities will be meaningless. They could also come up with just a handful of stories with priorities and estimates at the time the metric is taken. There – passed!
2. Percentage of requirements fully implemented – This is the same as fixing the scope of a project at the start, something that all agile methods are against. Meeting this measure means teams are motivated to prevent change (in contravention of the fourth value in the Agile Manifesto). And assuming the requirements set is baselined at the end of Foundations, meeting it would encourage teams to spend a lot longer defining the set of requirements and be excessively pessimistic about their estimates to ensure that they are all delivered.
3. Quality of Requirements Index – The intention was to measure whether stories adhered to the INVEST criteria for writing good stories. But this cannot be done reliably on an automated basis, and manual reviews are tedious, time-consuming and subjective. This measures the mechanics of story generation, not the quality. How do I know whether a team’s story is Independent or not without understanding the rest of the requirements set in total? Is a story Small enough? I can’t tell that either. Is Testable measured by the presence of acceptance criteria? Very easy to game that, isn’t it?
4. Number of missing requirements – It is normal – indeed encouraged – that requirement detail emerges over time, that stories are decomposed as the project progresses, that new requirements will also emerge as the product is developed. Are these classified as ‘missing’ requirements? Like measure No 2, this also encourages fixing the scope of the project at the end of Foundations, leaving the project manager with no contingency, and pushing back on any attempt by the business to change the requirements.

These are not things we want to encourage, and improving the quality of a set of requirements cannot be achieved by setting these sort of measures – quite the opposite. Gaming them, especially when they are automated, is easy. Remember, you get what you measure, and managers are all too quick to measure things and present figures that show themselves in a good light because the numbers are going up, but without thinking of the consequences of these measures on the teams and individuals involved. Agile is a team game, after all. No, the answer lies in education and coaching teams on how to do it properly and the benefits they get from doing so.
In conclusion, I’d like to share my opinion that measuring individuals on an agile project team is in itself harmful. How would a team feel if just the Business Analyst was subject to such measures? There is potential for the needs of the BA to meet the KPIs to be at odds with the team’s needs, and this is detrimental to teamwork. There are a lot of things that are worth measuring in an IT organisation. Individual KPIs like those above are not in that list.

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