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

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

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

Prototyping – what is the MVP?

What if you have a great new business idea, but don’t know whether it will work. You prototype it, right? Of course. But what do you prototype? How do you define what that minimum viable product (MVP) is that will prove whether your business idea is a great one or a non-starter?

As Steve Blank says in this article, it’s not necessarily a smaller, cheaper version of the final product. The important thing is to define what you don’t know about the product, and work out the quickest, cheapest way of finding out the answers. It’s about smart learning.

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

Can we believe the Chaos report?

The Standish Group have been publishing the Chaos report into the state of software development annually since at least 1995 and the figures have been reproduced all over the place, especially when trying to explain why Agile is a good idea. If they are to be believed, the software development industry is in serious crisis, with only 32% of projects completing successfully (in 2009).

But some people have been questioning the figures. Ask yourself – How many failed projects are you aware of? I haven’t seen too many, to be honest.

Interestingly, the Standish Group have never published their data, nor the names of companies that completed their surveys. Which raises questions about the integrity of the surveys. But more to the point, the definitions of what constitute a failed or challenged project is seriously open to question. The University of Amsterdam and the IEEE highlight the problems with the way the Chaos study has been conducted and challenges the results as being unrealistic.

“…Standish defines a project as a success based on how well it did with respect to its original estimates of cost, time, and functionality”. In other words, they are judging not the projects themselves, but merely the estimation of those projects. And that is something entirely different. That project success can be meaningfully defined as the accuracy of estimation is clearly nonsense.

Scott Ambler regularly conducts surveys on a host of IT topics, especially but not limited to Agile. According to these surveys, in 2011, traditional projects were perceived to be successful about 50% of the time, Agile or iterative projects about 70%. Yet, in 2010, agile projects were perceived to be successful just 55% of the time, challenged 35% of the time, with 10% failing. Interestingly, 33% said that no agile projects had failed.

While these figures are better than those published by Standish, I think there is some way to go before we properly understand how successful projects are, especially in an agile context. Are we all measuring the same thing? In my recent experience, I can think of only two project failures in the last couple of years – less than 5 percent! One was stopped part way through, the other was completed but had to be ‘switched off’ afterwards.

Perhaps we need a new definition for success, failure and what constitutes compromised, that can be applied to all IT projects, regardless of Method. Then we can realistically assess how successful Agile methods are.

What does success mean in your organisation and what are your success rates? Answers in the comments box below please.

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