Agile disciplines

Agile disciplines2018-08-21T15:22:54+00:00

Agile has many associated disciplines, through which an Agile approach is maintained and, in the longer term, an Agile mindset and culture are created.

Without these disciplines, using the Agile practices alone is most unlikely to create a thriving Agile culture; with them, that culture will emerge almost as a matter of course.

Unlike Agile practices, the Agile disciplines are not procedure-based tasks but rather reusable techniques or attitudes to work. Disciplines are what you arrive at work with – especially in the form of self-discipline. So, if you want to know how serious Agilists work and behave, master the items below. It’s not easy, but it is very rewarding – for you and your colleagues, for your work and your organisation, and for your career.

For details of each discipline, click on the menu on the right.

Map of the Agile disciplines

Agile Disciplines

DisciplineDescription

Adapt continuously

In traditional organisations, the rules are the rules. Not in Agile. In Agile, rules remain valid solely because they add value – which rules very often do. But as soon as they start to get in the way, they need to be changed. Hence the Agile mantra of continuous adaptation.

So what are you going to put in its place that’s better? Ideally ‘nothing‘, because the built-in dynamism and transparency of Agile mean that you just don’t need to do that sort of thing any more. But even if the answer isn’t ‘nothing’, nothing should be immune to regular adaptation – to make it better/ faster/ cheaper to do, to make it more fit for purpose, to make it easier.

Unlike biological adaptation, Agile adaptation doesn’t happen by accident. In fact all the ‘ceremonies’ in Agile are specifically designed to encourage the constant refinement of practices, roles, tools and results. Daily Stand-Ups are constantly looking for obstacles to eliminate, Retrospectives look for lessons for future implementation, Showcases seek direct feedback on improvements, and so on.

There are limits to adaptation, of course – in fact the ability to adapt effectively is one of the great tests of both one’s professional maturity and one’s self-discipline. Adaptation is as much a responsibility as a freedom, as much a burden as a liberty. Especially in a corporate environment, there are many questions that need to be answered before adapting existing ways of working:

  • Do you really understand why the previous approach was in place?
    • Is there some other factor you’re not aware of?
    • Who do you need to check this out with? A team mate? A user? The Product Owner? Is there a user, contractual or policy issue here?
    • Look before you leap!
  • Adapting may be advantageous to me, but who does it harm?
    • I’ve asked the team, but who shares this code? Who uses this interface? Who needs us to work this way?
    • If you don’t know, your ‘adaptation’ may turn out to be very maladaptive for someone else.
  • What will the impact be in the longer term?
    • This change may handy right now, but what are its implications – if only for the rest of the backlog?
    • It’s crucial not to build in speculative what-ifs, but equally critical not to lay traps for your future selves.
  • Do you have any real evidence that your idea is really better?
    • Is it just your hunch? A passing inspiration – maybe even just a whim?
    • If so, is there any way to check out your good idea to see whether it is in fact better than what’s already in place?

And so on. Continuous adaptation is fundamental to Agile, but ‘making it up as you go along’ is not.

See also: Welcome change

Automate everything

You can’t automate everything, of course, and perhaps, in absolute terms, you shouldn’t automate everything. But that isn’t the point. Automation is powerful.

  • It eliminates dull, repetitive tasks.
  • It accelerates many key activities.
  • It prevents the countless mistakes that creep into manual work.
  • It allows you to carry out mind-bendingly long, intricate and exhausting tasks completely reliably.
  • It lets you get on with the truly creative work.
  • It can be done when you’re not even there (e.g., overnight).
  • It allows you to simulate conditions that would otherwise be impossible (e.g., thousands of users).
  • Where distant players have to be involved, it lets you communicate with them and manage whole workflows simply and easily.

And so on.

Many Agile tasks are supported by purpose-built tools. Test-driven development, for example, has benefited enormously from the development of so-called xUnit tools, which can set up a test in seconds but allow you to execute it dozens, hundreds or thousands of times.

So why not automate? There are situations where ‘automate everything’ is a very bad principle indeed, so check these out before the lust for another tool overpowers you completely!

  • Where the cost of buying or building the tool could never be repaid by any added value automation would offer.
  • Where the cost of the tool is just the start, & populating with data, localisation, training users & configuring for each use exceeds any realistic value.
  • Where the work you are automating is rarely/never repeated.
  • Where you can’t specify the task precisely, so automation is not an option.
  • Where no tool can do the whole task, & total cost of tool plus the residual costs of manual work exceed the value added or costs saved by automation alone.
  • Where there is no good automation technology, where what there is integrates poorly with other your tools, or where it locks you into proprietary solutions to other activities too.
  • Where the task is too complex to automate realistically, and the result will be expensive to validate & risky to use.
  • Where maintenance costs are excessive or the resources to do it (mainly people) are unlikely to be available in the long term.

Realistically, the Pareto Principle applies – most of the benefits of automation will come from a minority of the theoretical opportunities to automate.

But as I say, that’s not entirely the point. Instead, default to assuming that you will automate everything, and see how far you can push the envelope. Modern tools make many things that look hard or expensive to automate quite painless, and it is an almost invariable rule that organisations would rather waste human time than pay for a tool, yet when a realistic business case is finally presented, the tool looks like a bargain.

Challenge everything

In most organisations, far too much happens without good purpose. It’s not hard to see why.

  • The span of the organisation is too large for individuals to grasp the whole thing, so the fact that much happens for no apparent reason doesn’t seem like a reason to stop doing it.
  • Many organisations have a culture of compliance – however superficial that compliance might be, the ‘rules’ will be followed.
  • There are no means (metrics, periodic evaluations, process governance, etc.) in place to check that the even quite basic ways of working are working properly or adding any real value.
  • Fixing any of these problems is either no one’s responsibility, too low a priority or beyond anyone’s power.

And so on.

This lack of rationality leads to serious inefficiencies – delays, waste, demoralisaton, disputes and worse. Agile challenges this by insisting that everything that does not obviously do some good is probably doing harm, and should be stopped until a convincing reason to restart is found!

This is facilitated by constructing a special Agile space – a cocoon within which rationality can prevail – consisting of the team, its environments and its resources, where the team not only may but are actively encouraged to eliminate every vestige of waste and rework and to build a truly excellent working environment.

Collaboration

Two heads really are better than one, so what about a whole team of heads working together?

Collaboration is one of the true fundamentals of Agile, even being explicitly mentioned in the original Agile Manifesto. It’s centrality to Agile can be expressed in many different ways:

  • Collaboration facilitates rapid, clear communication.
  • Collaboration facilitates change and improvement.
  • Collaboration supports our shared but diverse professionalism.
  • Collaboration makes it easy – inevitable, in fact – to acquire new skills and experience.
  • Collaboration builds team spirit and mutual support.

… and much else.

And as about half the other Agile disciplines rely upon collaboration, its value really cannot be overstated.

Collocation

Collocation is a basic premise of practical collaboration. It demonstrably makes development easier, and the closer you are together, the better it works. A team sharing a single room will even do noticeably better than one split across floors of the same building. As for offshoring…

How collocation works is very simple. Where traditional organisations demand that we email each other, schedule special meetings, write long documents and generally put a hundred pauses (and sometimes thousands of miles) between real work, collocation allows everyone simply to turn to their fellow team member and speak directly – without formality or organisation or delay or composing specifications or memos or anything else.

Note the impact this has on another traditional feature of space allocation. Agile teams are organised according to the work at hand, not by function. Developers do not sit with developers, they sit with whoever else is working on the same stories.

Interruptions are also limited if you take the additional precaution of isolating the work area from neighbouring areas – by having a separate team room, perhaps. However, if you do this, avoid internal interruptions by developing the discipline of taking extended discussions, phone calls and external meetings elsewhere – an adjacent side room, ideally, so it’s not too remote.

Finally, collocation is one thing, shoving people into a hole together is another. Don’t skimp on space. Less space squeezes productivity as well as bodies. If people feel uncomfortably close, make more room.

Continuous everything

Yes, everything – user interaction, planning, designing, coding, building, integrating, testing, accepting, deploying, automating, backlog refinement, maintaining, refactoring…

The goal of Agile is to deliver real value quickly and reliably. To do that, it is constantly striving to reduce the elapsed time between an idea emerging and its implementation in working software. In that way, the idea is realised literally as quickly as possible, and in a way that continuously tests both the original idea and the solution that will be delivered.

At every point in this process, new options and new problems emerge, each of which may lead to any part of the development process – from updating the story to better methods of deployment. A designer needs to keep an eye on exactly how the code is evolving, a tester can advise a developer on the pitfalls associated with particular aspects of the product, a deployment expert can advise the Product Owner on which features of the product as a whole will deploy easily together, and so on. Waiting for a set-piece review at the end of, say, the design ‘phase’ is simply storing up problems when sharing the experience of the team as a whole could have removed them before they appeared.

Hence the value of ‘continuous everything’.

‘Continuous everything’ is made a lot easier by the cross-functional nature of Agile teams. Because there is an expert of pretty much every aspect of the delivery process already present in the room, there’s no need to wait for a formal review or testing to check whether something makes sense. In fact, if the team is working at all effectively, you won’t have to wait for an opinion: you will get it just as soon as anyone spots the opportunity to improve something.

On the other hand, ‘continuous everything’ also makes it easier to utilise your team resources more efficiently. By expecting many eyes (and hands) to be on a single piece of working software at one time, there are no long pauses while individual specialists are waiting for something to do – for their ‘phase’ to begin, for when a new item is thrown over the wall from the previous silo.

Rather like ‘automate everything’, ‘continuous everything’ is not an absolute rule. In fact if you took it too literally, ‘continuous everything’ would quickly collapse into ‘continuous nothing’. But also like ‘automate everything’, it’s not a bad default position. You should expect people to justify why they shouldn’t do something continuously, not why they should.

Cross-functional

All Agile teams are cross-functional – which is to say, they aim to include within themselves every skill they will need to get the job done. Having a complete team means that the right people are instantly on hand to supply almost every kind of information, decision and action – and warning. At the same time, it eliminates most of the external dependencies that cause so many delays and misunderstandings (and not a little friction). The completeness of the team will also allow its members to see the whole wood, not just the trees they are most familiar with.

When teams are mixed like this:

  • They produce more effective solutions in less time.
  • They are more likely to generate genuine breakthroughs.

Initially, cross-functional teams have some trouble agreeing shared norms and procedures (including cultural differences between professions as well as specific working standards), but this kind of short-term cost is commonly compensated for by the longer-term synergies created by learning to see the work (and the world) through other professionals’ eyes.

Debug first

‘Debug first’ is one of those small Agile notions that can seem simultaneously trivial and annoyingly Agile-for-Agile’s-sake. But like all the family of ‘Quality First‘ disciplines, it’s both more radical than it looks and more important.

Above all else, Agile aims to avoid having bugs in the first place. Injecting bugs is a waste, and so is the time spent getting them out again. However, no one’s 100% perfect at that, and bugs will occur. What you have to do is to stop them breeding.

‘Debug first’ typically means checking the automated test results and fixing anything they throw up before getting on with the day’s more routine development work. It could also refer to fixing any error you find anywhere, of course, and in Agile you certainly should – errors not just in products but also in the way tools work, in the set-up of your workspace, and pretty much anything else that can in any way affect how well you and your team do your job.

After all, if they are left:

  • They will have to be dealt with one day, and at no less than the cost of dealing with them right now.
  • Meanwhile, every item that depended on the buggy code, the badly organised meeting, the poorly set-up environment – may also break. Either you will have built it right but it won’t work properly, or you will have assumed the the faulty item was right and made a wrong decision about the item that depends on it, so now it’s wrong too!
  • Other developers relying on you also risk being derailed by the fault.
  • Agile’s commitment to technical excellence and constant refactoring really make it imperative that you fix problems ASAP.

So, kill bugs as soon as you spot them. You can’t make anything worse, and you will probably make something better – if only by avoiding creating a new bug!

See also: Quality first; Test first.

Deliver early, Deliver often

If, as Agile assumes, working software is the real test of how well you’re doing your job, then ‘Deliver Early, Deliver Often’ should be like a mantra constantly in the back of your mind. By delivering early you discover exactly how valuable your work really is as quickly as possible, and by repeating the process frequently, you ensure that your focus never wanders from the one thing that really matters – delivering real value to the user.

Of course, that’s not the only reason to deliver early and often. Development is expensive, and the basic Agile model of value is deeply committed to repaying that expense as quickly as possible. Comparing the traditional ‘deliver at the end’ model with Agile’s ‘Deliver early, deliver often’ strategy, it’s not hard to see why we should prefer the Agile view of things.

Agile Value Model

Even if the total value delivered by each approach were the same, the fact that Agile starts to deliver it so much earlier means that the real cost of Agile is much lower, as it returns income to the organisation almost from the very start of work! In short, Agile starts to pay for itself long before other approaches.

Finally, by delivering early, you subject your work to the ultimate tests:

  • Does it work?
  • Does the user like it?

If the answer to either of these questions is No, it is a good idea to find out as soon – and (as each new delivery takes place) as often as possible!

Fastest way to do anything

…is not at all.

We all do too many of the wrong things. It leaves no time to do enough of the right things. Hence this discipline – don’t do things that you don’t need to. Be constantly looking out for superfluous tasks and activities, or for sensible activities that have become too complicated. And then update or remove them.

Of course, you need to be careful. There are many reasons why we sometimes have to do what is, from our own local point of view, too much:

  • Policies and regulations demand it.
  • There are hidden costs or consequences of omitting this activity.
  • The thing you want to remove may not always be a good idea, but sometimes it is.
    • Try to get it made optional rather than eliminating it altogether.
  • You may not need it, but someone does.
    • As with the previous item – make it selectable rather than mandatory.

In a way this is another kind of refactoring, but for work processes rather than systems. Once you start looking for ways to shorten, simplify or just delete work, you’ll be surprised how much of the traditional approach simply disappears, leaving only the truly value-adding activities – and a better mindset for future work.

Of course, The Fastest Way To Do Anything Is Not At All is a close cousin of the XP principle, Do The Simplest Thing That Could Possibly Work.

Grooming

If we want to deliver as much value as possible as quickly as possible, and we want to do it by doing barely enough (if not nothing at all), then we have to be continuously on the lookout for stories that are not going to add the value they were meant to deliver. Perhaps we’ve had a closer look and realised that a story will be a lot harder to implement than we first thought or it won’t benefit the users as much as the Product Owner had hoped. Perhaps it’s not defined well enough to proceed with. Or perhaps the organisation is simply heading somewhere else, and the story’s no longer worth while.

That’s when the grooming starts: combing through the backlog to check that our plans still make sense, and then shaving off the things – from fine details of individual stories or features to complete epics – that no longer merit inclusion. This is the other side of ‘look ahead‘ too, of course – not just looking but doing something quick and decisive about it.

Grooming should be a continuous process: there is no point in delaying such a decision, and every reason to think you will waste time and effort if you wait too long. However, the speed and urgency of work in a thriving iteration can make it hard to stand back and look systematically at the backlog. So it can be very useful to include a structured backlog grooming event in each iteration. It should not be allowed to replace the team constantly thinking about how to do more by doing less, but a backlog grooming meeting does give the team a definite opportunity to get together, pause and take a long, hard look at their backlog.

Iterative & incremental

As often as not, Agile projects need to spend a good deal of their time exploring the environment they operate in. What do the users really want? What’s the best way to build that? What is the context it will operate in? What are the best vehicle and the best channel for delivering value?

Such questions can quickly become overwhelming, so the best way to handle many of them is to bite off small, manageable chunks of work and deal with them one at a time. That is, we should work iteratively – which is to say, in repeated loops that start with a basic concept or problem and end in the delivery of a working solution. We should also deliver incrementally, which is to say, in small, manageable sections we can package up quickly and reliably, deliver to the user and then get on with the next segment.

Why iteratively and incrementally rather than in grand, multi-year programmes? Not because some expert or consultant has pronounced it the Next Big Thing but because its very nature means that it’s tested over and over again, before your very eyes.

Just enough

Everyone understands the principle of not gold-plating; ‘just enough’ simply takes this wise counsel to its logical conclusion. After all, if enough truly is enough, then ‘just’ enough it still – enough!

This is the basis of, for example, test-driven development: start by writing a test, and if the code passes the test, move one. No embroidery, no clever add-ons – it’s barely enough to pass the test, but it’s still finished. You may want to tidy up, to refactor, but that’s all.

Likewise, when collecting information, collect only what you absolutely need – the rest can wait until you actually need it. Stories work on this basis, of course – you only write down the minimal information needed to get a realistic sense of the story, because the detail will come when you talk to the relevant users. Until then you need to know only enough to understand what the story is about, whether it is likely to throw up serious problems you need to address exceptionally quickly, and who you need to talk to to understand more.

It’s true that you should also leave a tolerance for unexpected contingencies, but that is still only just enough.

See also: Just in time

Just in time

One of the most basic features of change programmes is, not surprisingly, change. But not only in the obvious sense. The situation you are working in is also likely to change frequently – with changes of strategy, requirements, players, goals – well, almost anything.

If we can expect change to happen, what is the best way to handle it? One good starting point is to do as little as possible about something until one absolutely must. If you wait for the very last moment, it’s far less likely that you will have to rework what you’ve already done when yet another change comes along. Hence the importance of working Just In Time.

‘Just in time’ does not mean that you should ignore the future. In fact, ‘looking ahead‘ is just as basic to Agile. But looking ahead does not mean rushing to take action – a far more time- and resource-consuming activity! No, just-in-time is soon enough.

See also: Just enough

Look ahead

Just as it is important that the work you do today should be sensitive to its context, so you should regularly take time to work out what the context of your work will be tomorrow. That way, when tomorrow arrives, you are more likely to be ready for it.

Looking ahead is so natural to human beings that it may seem strange to suggest that it’s a specifically Agile discipline. Yet in traditional change processes, it is unusual for most people to be involved in looking ahead – few have the necessary information anyway – and staged events where looking ahead is actually the goal are few and far between. There are some, but relatively few people’s opinions count and, even when they do, they are often filtered through constraints and prejudices built into the programme.

In Agile exactly the opposite is true. For example, many of the Agile ‘ceremonies’ aim to take a peek into the future.

  • In Release Planning, you try to identify the factors that may complicate your work, and so make sure that, in Iteration 0, you take care of them.
  • In your Daily Stand-Up Meetings one of the key questions you ask is, What do you think might get in your way?
  • In your Retrospectives, you explicitly identify lessons you have learned for the future.
  • Disciplines like pairing make it one of the pair’s role to look at the bigger picture – including the future.

And so on. Crucially, all these event involve the whole team. So not only are occasions for looking ahead a daily feature of Agile but absolutely everyone is expected to get involved. Everyone’s opinion matters.

Looking ahead isn’t limited to these semi-formal events. Anyone can raise any issue at any time. And as we’re all jointly responsible for the ultimate success or failure of our work, the incentive to speak up is always present.

Motivation

If we want the whole team to contribute everything they can, we need to make sure they are motivated to do so. At the very least we need to eliminate every discouragement from getting as involved as possible. For example, we need to cut out:

  • Repetitious work.
  • Work that is too trivial for the skills and experience of the worker.
  • Anything that could be done better.
  • Anything that would be better done by a machine.
  • Anything that would be better not done at all.
  • Hierarchies and management systems that militate against respect, self-discipline and professionalism.
  • Exhausting work hours, weekend working and a general lack of work-life balance.
  • And much else.

In their place we need to put:

  • The opportunity to do creative, varied, fulfilling work.
  • Respect for individual skills and experience.
  • Respect for professionalism.
  • Full responsibility for one’s own work.
  • The opportunity to work in a mutually supportive team.
  • The opportunity to develop new, cutting edge skills.
  • A sustainable pace of work.
  • And again, much else.

To repeat, if we want people to behave in a professional, self-disciplined way – and to reap the many, many benefits that follow from employing the best – then we have to motivate them accordingly. Money and promotion aren’t enough: for true professionals, the work itself is the thing.

See also: Pairing.

Pairing

Pairing is usually regarded as a programming technique, but in fact it can be used all across the development process. Almost every task would benefit from having an extra pair of eyes on it – so much so that, in an Agile environment at least, we should probably default to pairing on everything, and give it up only where there is a compelling reason.

Generally speaking, the more complex, innovative or critical the task, the greater the value of pairing.

Pairing is simple and easy. One of the pair, the ‘driver’, does the direct work – typing at the keyboard, for example or writing down the design. The other member of the pair, the ‘navigator’, sets the driver’s work in its strategic and tactical context. This isn’t just looking for mistakes, it’s also looking for opportunities that the driver, heavily involved with actually getting things done, is often too focused to deal with right now.

So, in pair programming, the navigator is looking for tactical defects such as syntax errors, typos, poor code quality generally, and technical mistakes such as calling the wrong method. But they’re also looking ahead, testing the driver’s work against the overall goal of the work, and so making sure they’re going down the right road. This is much easier for the navigator, who can sit back and take a more detached, more context-sensitive perspective on the work.

It also helps that the navigator is there to bounce ideas off of – instant brainstorming!

Pairing requires incisiveness, but also a high degree of humility (on the driver’s part) and tact (on the navigator’s). This gets easier when a further part of pairing is applied – swapping roles frequently! Then the driver will be on the receiving end of a running commentary, and perhaps learn what sorts of comment are most – and least – likely to be constructively received.

It sounds expensive – paying two people to do one person’s work. But there is ample evidence that it pays.

  • The additional effort is very small – perhaps only about 10-15% overall.
  • The quality of output is substantially higher:
    • Fewer defects are found, so you save on retesting and delay.
    • Technical debt is lower, so future work is cheaper.
    • You have built in an especially intensive form of review – another proven and cost-effective way of improving quality.

So the net effect of pairing is almost certainly both greater efficiency and greater effectiveness – at a reduced total cost.

Pairing also seems to improve morale and improve teamwork, so skills will be passed on more quickly and experience intensified.

How does pairing work? Laurie Williams, who has researched pairing extensively, suggests a number of drivers:

  1. Pair Pressure. Pair programmers put a positive form of pressure on each other.
  2. Pair Negotiation. The partners must negotiate how to jointly approach the problem, so pairs evaluate more alternatives than either one would have thought of in isolation.
  3. Pair Courage. Having a partner is a tremendous encouragement to be bold and creative.
  4. Pair Review. Pairing provides an immediate review mechanism, so defects are spotted and removed before they are able to infect the product as a whole.
  5. Pair Debugging. It’s much easier to understand (and often anticipate) a bug if you try to explain it to someone else.
  6. Pair Learning. Knowledge passes back and forth between the pair partners – product knowledge, coding wisdom, tool skills, background knowledge, professional experience…

But perhaps the single most useful thing to understand about pairing is knowing when to stop. So much intensity can be very tiring and relationships can come unstuck with too much pairing! 1.5 to 4 hours is a good range of time to spend together. This is why pair rotation is a very common practice. As Williams puts it:

In industry teams, pair rotation is a common practice to keep the pairs dynamic, rather than having assigned pairing partners for days or weeks at a time. Many teams rotate pairs several times per day or once per day. Frequent pair rotation is important for knowledge transfer among the team. Additionally, pair rotations aid in indoctrinating and training new team members as empirically demonstrated at Menlo Innovations, Microsoft, Motorola, and Silver Platter Software.

Prioritise

First things first.

Many flavours of Agile set great store by delivering the stories with the highest business value first. There are any number of reasons why we may not get to bottom of even the iteration backlog before the current iteration or release is over – unexpected obstacles may arise, the situation may change, we may run out of money. So we need to make sure that we do the most valuable things first.

Of course, we may prefer to prioritise by other criteria – by criticality, for example, or by complexity, novelty or the number of other stories that depend on this one. After all, these stories are more likely to cause more problems, and it would be a good idea to find out what the problems are early, so we don’t have to abandon delivery altogether. Or we may want to adopt a multi-dimensional approach, such as ranking stories by a combination of business value and difficulty to implement.

But in any case, delivery is a risky process, so we need to prioritise. And because delivery is a risky process, we should not limit our enthusiasm for prioritisation to stories. In fact, as so often in Agile, the same discipline should be extended wherever possible. For example:

  • We need to choose between attending an external meeting with a vendor and getting more stories completed. Which should we do?
  • We need to choose between doing extra hours right now to complete a delivery (and so probably losing productivity later on) or maintaining a sustainable pace, which will probably be more effective in the long run. Which should we prefer?
  • We need to choose between spending half a day on a key webinar and doing some direct work. Which should we prioritise?

A major difficulty with prioritisation is (as I’ve already suggested) there are so many methods you could choose to prioritise by. A handy way of thinking about prioritization is the so-called Kano diagram. (For an explanation of the Kano diagram, see here.)

An important feature of the Kano diagram is that, if you go too far down or too far to the left, you are actually making things worse. So, for example, if the training webinar you were thinking of attending is generally interesting but won’t add specifically to your ability to complete the current release, would attending actually make things worse – by taking time out of the iteration that won’t, in fact, be repaid in this release? Likewise for many other decisions: once you are clear about the proper context of your decision – in this case, ‘the current release’ rather than ‘my general skillbase’ – the priority of a given option may become clearer.

The Kano diagram also illustrates another benefit of Agile’s enthusiasm for continuous adaptation. This is what has been called ‘quality gravity’. Over time, things that were high priority items stop being quite so valuable. In products, for example, they might be innovative features that quickly become routine. In this situation, priorities have changed, and quality gravity will have dragged the value of this feature down, perhaps to the point where it has been completely superseded and it should be taken out!

In most organisations, things which were once high priority items are often embedded in standards and procedures. Later, however, when they stop being so vital, it can be extremely difficult to remove them – they are part of the routine, the rules, the (increasingly bad) habits of the organisation.

For Agile, however, the constant process of prioritisation also includes constant re-prioritisation. So such things will quickly be exposed and eliminated.

Of course, not everything can be prioritised along the Kano dimensions. For example, it does not (in its standard form) allow for things that are actually going to get in the way. A feature that would complicate my life, for example, might be very negative – the more there is of it, the worse the product gets! Some ways of working are like this – when they add demands for information that no one will really use, for example.

But Gartner-style quadrants provide a similar (easier but less clever) solution, and there are other answers. The key is to decide what the key dimensions of your decision-making need to be, and to be strictly rational about how you come to your conclusions.

Quality first

The ‘Quality First’ philosophy – or ‘Stop The Line’, as it was known at its birthplace, Toyota – is quite a shock to most managers. No, no, they will cry, speed is essential! And whether you’re running a production line or developing the next generation of your organisation’s flagship IT system, so it is.

But speed (like productivity – another equally doubtful management obsession) isn’t always what it seems. Throughput isn’t results. In a nutshell – ‘More haste, less speed’. (Or festina lente, as the Romans used to say.) If you hurry to do the urgent things (writing code, hitting milestones) but neglect the important things (code quality, delivering real value to the user) you will very soon discover just how slowly you have really been going.

Nor is this only about code. At every step on the way it’s easy to see why a little extra attention to quality will bring benefit – and not just in the long term.

  • Weak or poorly conceived stories lead to mistakes and confusions.
  • Badly set-up tools and environments reduce your velocity and cause endless frustration.
  • Superficially conceived designs simply embed mistakes and inefficiencies deep in the system.
  • Badly constructed code is harder to alter if the user changes their mind – as, eventually, they will.
  • Skimping on testing means that you have effectively abandoned your last opportunity to not make a fool of yourself in front of your users and other stakeholders.

And so on, through every part of the Agile lifecycle. Even badly conducted meetings waste time, mislead their participants and annoy all concerned, with an inevitable negative impact on future productivity and vital relationships.

What you’re doing when you decide to put Quality First and Stop The Line is simple: instead of maximising your use of your current process, you’re proactively building a better one. So, as with everywhere in Agile, benefits start to accumulate immediately, rather than waiting for some future improvement that may or may not materialise – and will usually only come long after the same mistake has been repeated over and over again.

If Toyota’s experience is anything to go by (and research says it is), Quality First starts with massive loss of productivity. But if you’re patient, the gains will come. It’s like training for your first marathon: it’s painful at first, but if you persist, amazing things will happen. Better, faster and cheaper – not the traditional ‘two out of three’ – becomes the norm.

So Quality First isn’t gold-plating. Don’t worry about the elegance of code that’s never going to be looked at again. But at the same time, it’s really difficult to predict which code that is. Some code will obviously be re-engineered over and over again, but how much would definitely not benefit from being well made? So whatever you’re building, defaulting to Quality First is not a bad philosophy.

See also: Refactor.

Refactor

Refactoring (or Refactor Mercilessly, as XP puts it), says one of its principle authorities, is ‘a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior’. And it’s crucial to Agile.

Refactoring can be explained as follows:

“Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.”

There are dozens and dozens of small, simple refactoring techniques, all with names like:

  • Remove Named Parameter
  • Collapse Hierarchy
  • Replace Conditional with Polymorphism
  • Extract Method

What these very simple techniques are doing is implementing all the standards for good quality code and programming we have all officially learned but seldom have time for. As a result, the systems traditional development teams work on are frequently obscure, faulty and sometimes so hard to understand that a complete rewrite is easier than a fix!

Simple versus EasyRefactoring is closely connected to a much more general principle – that simple isn’t the same as easy. Many things are easy that make life less simple, and not all simplifications make life easier. However, the goal of refactoring is to make code (and designs, architecture, tests etc.) more simple so that, in the long run, the code is easier to understand, change and support.

So refactoring is central to Agile, because by constantly attending to the small improvements in code quality, the system as a whole is kept as simple to engineer, support or even completely transform as possible. Since Agile aims to be as swift and simple as possible, working with systems that are so well-engineered is a major benefit.

See also: Quality first; Refactoring (technique), Simplicity.

Self-organisation

Agile teams are self-organising. That is, it is the team that decides how the team works, how to collaborate among themselves, what good engineering looks like and how to solve problems when obstacles appear. Without this authority over its own activity, the team loses its ability to respond quickly, flexibly and decisively to changes in circumstances, priorities, and needs – the very things Agile is designed to achieve.

The other side of being self-organising is responsibility. That is, the team sets and holds itself to the standards that go with the freedom to operate as it chooses. That’s why Agile really depends on the maturity of the team and its individual members – it takes a long time to acquire that level of self-discipline.

Of course, a team cannot exercise such a high level of self-organisation if it lacks the resources to carry those responsibilities out. That’s why strong Agile teams always include the full range of skills needed to complete their task: if they didn’t they would have to look for them outside, which would immediately limit their freedom of action.

Self-organisation can be one of the hardest things to achieve in many organisations. Senior management don’t often want to let go of the power to control teams. But that’s what Agile assumes – demands, in fact. Often senior management are only willing even to contemplate allowing their teams such a high level of autonomy after repeated failures and delays have proved that the traditional top-down approach to management just doesn’t work.

But once self-organisation becomes the normal way of operating, its benefits usually become clear very quickly. Perhaps this is because working quickly and flexibly, with a high degree of commitment and professionalism, only becomes possible once the experienced, self-disciplined professional engineers who make up Agile teams are freed to use their skills and experience freely.

See also: Trust the team.

Simplicity

‘Simplicity’, say Agilists, ‘means maximising the work not done.’ It’s a good goal, to do as little as possible while still delivering the desired results. Hence Agile’s emphasis on more specific simplifying disciplines such as ‘just enough‘.

But simplicity also means something else: simplicity is organised complexity. There are lots of hugely complex elements to most work, but if you can discover the underlying simplicity – the key to the pattern, the basic model – things quickly start to make sense and fall into line. An optimal order of working will emerge that will allow you to limit yourself to the right work done the right way in the right order.

Taken together, these two facets of simplicity explain why it figures so prominently in Agile – in refactoring, in automating everything, in the simplicity of ceremonies such as Daily Stand-Ups, and so on.

See also: Refactor

Sustainable pace

The real issue with setting a sustainable pace for work is productivity. The real problem with setting a sustainable pace for work is the assumptions we make about how well we work when we work long hours.

The evidence is quite clear: long hours kill productivity. It does this is many ways: it kills problem-solving ability, creativity and insight, and it makes it much more likely we’ll make mistakes. It even makes us work more slowly.

The causes of overwork are many, varied and pretty inexcusable, with the delivery team frequently paying for mistakes made by other people. But whatever the cause, long hours are not, in themselves, going to solve any problems.

The fact is, long hours reduce productivity – not only by making people less efficient but, if they become too much the norm, by actively reducing product quality and the rate at which that product goes out the door. Eventually productivity actually falls. Driving up the working week to, say, 60 hours, may, temporarily, boost total production. But the boost only lasts 3 to 4 weeks, and then the productivity curve turns firmly downwards – eventually to the point where you produce less than you would in a ‘normal’ 40 hour week.

Just as bad, the recovery time from this burst of overtime is generally at least as long as the period where overall velocity is boosted. That’s not to say you can’t ever raise production through extra hours; it’s just surprising how quickly the benefits turn to costs.

Ironically, people who do a lot of overtime often claim that they’re more productive, and can work long hours without losing productivity. That’s because, unfortunately, one of the first things you lose on overtime is your sense of how much work you’re doing! As Daniel Cook puts it:

“This behavior is fascinating to observe. Zombies stumble over to their desk every morning. Tempers flare. Bugs pour in. Yet to turn back would be a betrayal.”

Hence the value of setting a sustained pace – and the illusions and costs of not setting one.

Incidentally, it’s worth noting that the 40-hour week was first normalised in the USA by Henry Ford and his fellow industrialists. They were not, by and large, motivated by philanthropy towards their workers. Ford spent 12 years studying productivity in his own plants, and knew very well how badly long hours damaged productivity.

Test first

Test-first is an odd idea. Surely you need to build something first, then test it?

Not in Agile. Think of how Agile starts work. No detailed requirements or specifications – just you, a ‘story’ that amounts to little more than a hint at what’s needed, and a user who knows what they want.

So how are you going to get through? A good deal will rely on the user, of course: that’s why they’re there – to tell you the details. But although users are invaluable at telling you what they want, often the more you ask of them, the harder they find it to be precise about what they need.

One way around this is not to look for a positive description of what’s needed but to ask for a test of whether you’ve got it or not. How would I know whether I’ve successfully built what my user is looking for – whatever that may be? Asking for tests is a good way of breaking down the ‘specification’ and homing in on the key details – without, of course, writing that long, long specification in the first place!

So as a pragmatic technique for communicating with your user, test-first is a pretty good discipline. So much so, in fact, that it is the basis of a key Agile development technique, Test-Driven Development.

It offers other benefits too. The pressure software development projects are typically under often means that proper testing is squeezed out – there’s just no time, and rather than ask for more, it’s easier to treat the test budget as the project contingency fund. So a lot of bugs get in (because you’re under pressure) and then they don’t get found and taken out again (because you’re not doing enough testing).

The way Agile uses testing solves both these problems. Using special tools (e.g., xUnit tools, which are often built directly into development environments), the tests the developer identifies with the user can be built directly into their code. So, once written, they’re always there, and can be set to run as often as you like. The code can be fully instrumented with extremely precise tests of practically everything the user asks for and the developer writes – each function, each code branch, each parameter – anything the user or developer chooses to test for. In fact they amount to a built-in, executable specification.

And as, for as skilled developer/user pairing, such tests can be defined and built in a matter of minutes (if not seconds) the overhead this adds to the development process is extremely small.

So, win-win: you get better information from your user, and you are less likely to leave in mistakes.

Test First has other implications, of course. A closely related Agile discipline is Quality First. So if your code is thoroughly tested because you began with testing, you’re obeying that rule too. And as code with high test coverage is fundamental for making your code as a whole more elegant, more intelligible and easier to change, this will also minimise the effort you have to put into yet another Agile discipline, namely refactoring. Add to that Debug First and the virtuous circle is complete.

Timeboxing

A timebox is a fixed period of time within which a task must be completed. Timeboxing is one of the fundamentals of Agile. The basic idea is that the timebox sets an absolute limit to how long the team has to deliver a change (a release, an iteration, etc.). If they have not implemented all the stories in the backlog by the end of the timebox, instead of requesting more time (as non-Agile teams generally do), the team delivers what it has completed.

The logic behind this is simple. Experience – often very bitter but seldom learned from – shows that a team that is running late is not going to perform any better by being allowed more time. It may deliver everything eventually – though industry metrics make this seem unlikely – but why not choose an even simpler solution, and deliver what it has got now?

On the other hand, if the team has something to deliver, it adds value now – and not just when the project as a whole is complete. This means that the organisation can start to benefit from the work that has already been done, even if it can’t have everything. Better 80% now than 100% ‘one day’. And of course, if there is one thing we know about this project, it is that it is already late, so we should not be optimistic about when it will deliver anything.

Of course, it’s not easy to deliver anything if the entire development process unfolds in huge phases – capturing all the requirements, completing the whole design, testing everything together in a single phase, and so on. That is why Agile has innovated in so many different areas, such as defining and implementing complete stories. But among its many innovations, timeboxing is fundamental – without this discipline, many other Agile disciplines immediately come under pressure too.

Transparency

As the chart at the top of this page shows, transparency stands at the very heart of Agile. Like honesty in any other kind of relationship, if transparency is missing, everything else falls apart. Or as Jeff Sutherland and Ken Schwaber, the originators of Scum, put it in the July 2013 edition of the Scrum Guide:

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.

So: Rule No.1: Explain, don’t dictate. Whatever your role in the team, if you help your teammates understand why things are as they are and help them to understand the nuances of any given situation, your audience is far more likely to be receptive. Conversely, make sure you go out of your way to understand other team members’ points of view – transparency is not just about making things visible but also about looking and discovering too.

The team member who is most likely to find transparency hard is probably the Product Owner. Often they are more senior in the organisation than the other team members, and as the representative of ‘the business’ are often seen as the owner of the work. And as most organisations are more or less hierarchical, the Product Owner may think they only need to tell the team what they think they need to know. This does not help the team to be Agile, and it will certainly make it harder for the Product Owner to get what they want out of their product.

So, if you’re a Product Owner:

  • Spend as much time as possible with the team.
  • Spend at least half of that time learning – not telling!
  • Do it in person too – don’t delegate your role to, say, your business analysts.
  • Find out what the team members actually do and, as far as possible, try to understand the technicalities. This will help you understand the difficulties and risks they face better, and also expand your understanding of what is possible.
  • Likewise, get your users to visit the team as often as possible, to explain what they do and to understand better what the team can do for them.

Equally well, to the extent that Agile is a voyage of discovery rather than a production line, everyone needs to be able to see the map – the Big Picture, the Roadmap, the Strategy, the Product Plan, or whatever else you want to call it. If they’ve never read the business case, how can they know that a given idea simply will not work? How will they know whether the system they are building, however technically excellent it maybe, will meet your business needs? Without that sort of in-depth background knowledge, there’s an excellent chance that they will get it wrong. Features and stories will be misunderstood, prioritisations will not seem to make sense, and estimates are likely to go awry.

And if you’re not the Product Owner, get out of the team cocoon and get to grips with as many other people’s problems and perspectives as possible.

Without transparency on all sides, the wealth of experience an Agile team of mature, experienced, disciplined professionals can bring to bear is lost. This is especially true when there’s bad news. It does no good to conceal unhappy truths, least of all when the team will need to respond as quickly and adaptably as they can.

This point can be pushed into every corner of Agile, especially into the various meetings. Without complete straightforwardness in all things, there is simply no point in running Daily Stand-Ups, Showcases or Retrospectives. Without taking the time to explain – and hear – the concerns of others, estimating and prioritisation become futile.

So, especially when time is short – which, in Agile, it always is – always be as transparent as you can.

Trust the team

The Agile team works only as a team. All points of view are valued. When no one is the boss, it becomes possible – indeed, vital – for all team members to make a full contribution. Given the immense range of knowledge and awareness a whole team of experienced professionals is likely to have, surely it makes sense to be constantly encouraging them all to speak up?

But before making the transition to Agile, most organisations are hierarchical. There’s a definite top and a definite bottom, and the people involved in an Agile team often come from quite a wide spectrum of positions. It’s seldom part of any hierarchy’s culture to ask people below you what they should be doing: you just tell them. Still less often are you likely to ask them what you should be doing. But that is the basic premise of professionalism – just as you ask a doctor or a lawyer to tell you what to do, so you should be asking professionals of all kinds to tell you what to do too.

But you are most unlikely to do that (or to follow their advice) if you don’t trust them.

Trust isn’t something you can just leap into. You need reasons to trust. These are best built up gradually:

  • By starting with small commitments and making sure you keep them.
  • By sharing a little more information than usual and seeing whether it is used responsibly.
  • By discussing your concerns and hopes and seeing whether the response is constructive (rather than, say, defensive or dismissive).
  • By admitting to uncertainties, ignorance and mistakes.
  • By being (sincerely) generous with appreciation and praise, and forthright but tactful and constructive with your criticisms.

Conversely, if you expect to be trusted – and if you aren’t, Agile is dead – make sure this is a completely reciprocal process. Honesty, transparency, face-to-face conversations.

Perhaps best of all, nothing quite overcomes prejudice and doubt like working together everyday as equals. Try it.

See also: Self-organisation

User involvement

One of the favourite recent management buzzwords is engagement. User involvement is like that – only more so.

In most environments, the user provides stuff to the team – information for requirements and functional specifications, data and bodies for user acceptance testing. By and large, the information comes in the form of long, indigestible documents that, by the time the solution lands on their desktops, is probably obsolete.

And in between? Not so much.

But why not? The user is, above all, the person who knows what the delivery team needs to deliver. So why not ask them directly? That is, of course, exactly what Agile does. Hence the discipline of constant – or, at least, regular and frequent – user involvement. More than mere engagement, involvement means having them right there beside you as you build the system they are going to be using. The Agile user is a full member of the team, not just a visitor. So, long before it is delivered they can know what it will be like, and tell you all manner of useful things about exactly what they do – and don’t – want it to do, and how they want it to do it.

Not just any user, of course. Apart from simply being sufficiently available, a good user also:

  • is an expert in the story you’re trying to deliver (although this should not exclude them being able to represent inexperienced users too, to whom the system an expert would be happy with may be much less clear).
  • has the authority not only to approve (if not formally accept) what you’ve built but also to change the underlying story if it turns out not to work.

This involvement needs to start as early as possible. Users should have direct input to the detail of individual stories, including prioritising them to reflect the needs of the users and, where appropriate, the customer. They also need to be able to quickly and simply communicate changes to existing stories and, because we welcome change, to add new and remove obsolete stories. And if you have a separate UAT process, they will need to be involved there too.

User involvement is one of the hardest parts of Agile to get right. Users typically have day jobs too, and not all organisations are rational enough to back-fill their work while they’re helping you. It’s important to allow for this dismal fact, and not alienate the user by demanding too much time or too intensive involvement. Coming to a compromise will benefit you both.

(For more on users, see Users.)

Welcome change

It wouldn’t be very original to observe that the one constant force in IT is in fact change. However, it would be true.

Change is the norm in IT for a very simple reason: change is increasingly the norm in the organisations IT works for.

  • Consumers of IT systems and of the increasingly many software-intensive products expect more frequent updates.
  • E-distributed software is getting more and more popular with vendors, and major software suppliers are increasingly positioning their products as online service providers (e.g., Salesforce, Microsoft 365).
    • In this environment, releasing and distributing software is easy, quick and cheap.
    • However, defects instantly impact millions of customers, and switching to a competitor may take no more than a few clicks.
    • So the ability to add new features quickly and painlessly is vital, and so is the ability to correct mistakes!
  • Companies have effectively ceded control of the design and implementation of internal operational functions such as security and HR by adopting tools such as DocuSign, Zendesk and Concur.
  • The app- and feature-driven nature of new platforms (smart phones, tablets, etc.) has made disruptive innovation the norm. This demands rapid evolution in every possible dimension.
  • Consumers expect to be instantly protected from unpredictable threats such as viruses.

What else does this tell us? That welcoming change is not simply a matter of good professional practice. It’s also driven by changes ‘out there’, in the way entire industries are evolving. Traditional methods aren’t in decline solely because IT people don’t like them; they’re in decline because they don’t work any more.

So the overall message is simple. Traditional methodologies are too time-consuming, unresponsive to change and inflexible to deliver any of this. Agile, on the other hand, is designed for exactly this universe.

See also: Adapt continuously

Working software

Why are Agilists so keen on working software? Very concisely, if the proof of the pudding is in the eating, the proof of the software is in the execution.

Or as Alistair Cockburn (one of the original signatories to the Agile Manifesto and the author of the Crystal methodology) puts it:

‘Written, reviewed requirements and design documents are “promises” for what will be built, serving as timed progress markers. There are times when creating them is good. However, a more accurate timed progress marker is running, tested code. It is more accurate because it is not a timed promise, it is a timed accomplishment.”

You can read this in a positive light – it simply extends to systems development the basic empirical principles of scientific method (though it would be grandiose to describe much else about IT as scientific!). Or you can look at it from a more jaundiced point of view and say that, for half a century IT has been issuing promissory notes, but seldom have we delivered on them. So moving to ‘working software’ as the guarantor of our delivery promises seems the least we could do.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Toggle Sliding Bar Area
Want to do more than just build systems?