An A – Z of Agile

One day in 2001, seventeen developers got together to talk about the barriers and complications that surrounded the development of software. They came up with the “Manifesto for Agile Software Development” which aimed to remove those complications and make software development easier and more effective.

You’ve probably heard the term “Agile” many times, because it’s been bandied about in business like a get-out-jail-free card, over the last few years – with so many people talking about Agile this and Agile that. Take Agile IT service management (ITSM) as an example.

But if you’d like to learn more about what Agile software development actually is, and the impact on ITSM, then you’re in the right place. To explain Agile in more detail, I’ve written one of my A – Z lists on what it’s all about and some tidbits on how it might be applied to the world of ITSM too.

Agile software development

It seems sensible to kick things with off with a quick definition of Agile software development. Essentially it aims to deliver solutions quickly via self-organized teams without sacrificing quality. It’s an approach that embraces change, eliminates waste, and encourages a collaborative working environment.

Being agile is one way for organizations to keep up in a business world where the pace of change is ever-increasing. Of course, Agile can hardly be summed up in a single sentence, so I’ll let my letters B – Z explain it in more detail.

Business people and developers together

Agile is based on four values and twelve principles, and one of these twelve principles is that: “business people and developers must work together on a daily basis.”

Thus, instead of separating developers from technology consumers – perhaps hiding them in an ivory tower – they’re actively engaged with their business colleagues, which means that they can gain a greater understanding of business needs and the business colleagues can be involved with software development.

The Agile belief is that better decisions are made when business stakeholders and technical employees work together.

Customer satisfaction

The highest priority of Agile is a happy customer, which is achieved by frequently delivering value to the consumer.

This is done by building and delivering in a “step-by-step” manner, instead of creating a completed final solution at the end of a focused software development project (please see the letter T for more information).

The benefit of this approach is that the customer can review each step and provide feedback to developers about what is and isn’t working for them. This feedback can then be acted upon in the next stage. Course-correcting as needed and – importantly – no longer delivering a final solution that somehow misses the mark.

Because customers are allowed to offer their feedback, they feel involved in the process and their needs are better met which results in higher customer satisfaction levels.

One of the values of Agile is “customer collaboration over contract negotiation” which means that, to be Agile, the customer should be involved throughout the development process rather than only in a negotiation phase at the start. After all, it’s much easier for developers to meet the needs of a customer who’s engaged throughout the process rather than one who is kept in the dark until the desired – but not necessarily right – solution is delivered.

Daily scrum meetings

Daily scrum meetings (please see S for more detail on Scrum) can be used in an Agile working environment when the Scrum methodology is adopted. They’re usually limited to fifteen minutes in duration and are used to answer three questions:

1)    What did you get up to yesterday?

2)    What’s on the agenda today?

3)    Is there anything blocking your progress?

Due to the fast-paced, changing nature of Agile working it’s important to check on progress each day. And these daily Scrum meetings help to ensure that people are on track, engaged, and have a space to flag any issues preventing them from completing their work.

Embracing change

This one’s a biggy for the Agile worker, and it forms another of the four values: “responding to change over following a plan.”

The idea of Agile is that changes are welcome however late in the process they might appear. And, because delivery is made in stages, changes are easier to manage than they were with traditional “waterfall” software development – which created rigid plans at the start and meant changes along the way were costly and inconvenient.

Agile ultimately sees changes as a way of adding further value and delivering what’s actually being asked for (by the customer) upon final release.

Face-to-face communication

Agile believes that the most effective form of communication is face-to-face, which is why this is one of its twelve principles.

When developers are located together, they’re able to perform better as they don’t have to deal with the barriers that other communication methods put in the way. So, instead, communication is swift, clear, and immediate.

Good design

“Attention to technical detail and design enhances agility” is another Agile principle. The idea here is that if teams are to work quickly, embrace change, and provide continual improvements, then they absolutely must have good design and technical abilities. Without the right skills in place, workers – and their outputs – are likely to suffer under the pressure to delivery quickly.

High speed

A benefit of being Agile is being able to deliver at speed – thanks to the drip-feeding of change (and benefits) in small increments rather than waiting for one final “drop” of the finished solution. Please see the comment submitted at the end of this blog for some well-articulated detail from a reader.

On the one hand, this speedy way of working means that organizations deliver value frequently (and more quickly). But, on the other, developers run the risk of burnout if progress is not managed effectively.

Individuals and interactions

Another of the four Agile values is “individuals and interactions over processes and tools” which is a value that responds to the needs of the modern employee.

People are what make the corporate-wheels go round, so it makes sense to value them over tools. Processes and tools, while important, are merely enablers; and without people they’re often inefficient and possibly ineffective.

Thus, with Agile, individuals are trusted to do their jobs – forming self-organized teams and frequent interactions between people are encouraged.

Just for software development?

I’ve already written a lot about Agile software development above, but the Agile methodology can be used throughout various organizational departments and industries. So. it’s not just for software development, and its values and principles can be lifted and used by those looking to eliminate unnecessary work, embrace change, and work holistically.

Which brings me to Agile ITSM. Where lengthy processes, siloed teams, and reactive support models – and the traditional IT working structures – often just don’t cut it anymore. So, maybe introducing an Agile mindset into the ITSM arena can help it too.

To help you think about this blending, here’s how the four Agile values are similar in nature to the nine guiding ITIL Practitioner principles.

(Please note that the nine guiding principles in ITIL Practitioner are now seven guiding principles in ITIL 4.)

ITSM/ITIL and Agile are, of course, different in their nature but their priorities are similar: satisfy customers, deliver value, work in stages, and don’t complicate things. This means that the two have the potential to work effectively alongside each other.

Kanban

Kanban is a Japanese word meaning “card.” It’s a methodology designed to help organizations deliver changes in small doses.

A Kanban board is used to visualize workflows, and the board has columns which can be titled. For example: story, in progress, in testing, complete. Tasks are then added to the columns so that teams can easily see what’s sitting where and what needs to be done.

Kanban aims to reduce the amount of work in progress (WIP). So, a WIP limit is added to each column. If a column exceeds its WIP limit, then no further tasks can be added to that column and the team must work to clear the column before anything else can progress. This allows teams to easily identify what’s causing hold-ups – because process issues are visualized, allowing for much faster identification and rectification.

Lean software development

An Agile software development method, Lean software development, is a framework with its own values and principles that supports an Agile working environment.

The main goal of Lean software development is to “maximize value and minimize waste.” With the principles of Lean as follows:

• Eliminate waste – anything that doesn’t deliver value to the customer, for example unnecessary process steps, task switching, defects, or incomplete work
• Build quality in – write less code, keep it simple, and avoid adding defects
• Create knowledge – build daily, gain rapid feedback, release early, and encourage learning
• Defer commitment – gather as many facts as possible rather than working from assumptions
• Deliver fast – regularly show stakeholders and customers what’s being developed (Lean sees speed as the essence of success)
• Respect people – motivate the team by letting people make decisions and take control, and management should listen to the subject matter experts (SMEs) to help them assess direction
• Optimize the whole – meaning the whole value stream and not just individual teams

Ultimately, Lean software development is all about delivering value, delivering at speed, being flexible, and respecting those doing the work.

Motivated people

Another of Agile’s twelve principles is “self-organizing teams encourage great architectures, requirements, and designs.”

There’s no micro-managing in an Agile world, because it works by allowing skilled, self-organized teams to make their own decisions. And allowing individuals to take ownership and collaborate directly with other teams helps to keep staff motivated throughout the journey.

No rules

One of the biggest barriers to Agile adoption comes in the form of insufficient training in relation to the values and principles of the manifesto.

It’s often assumed that – because Agile working means flexibility, working at speed, and evolving throughout the process – there are no rules to follow. This is not true, and Agile can only be successful if all involved employees are trained and agree to take on an Agile mindset and way of working.

Opinions and feedback

Opinions and feedback drive the Agile way of working.

Scrum meetings encourage people in teams to share progress daily and voice their concerns over blockers that might be hindering their development. The “individuals and interactions” Agile value encourages teams to share knowledge, collaborate, and speak openly about progress. And customer feedback is vital throughout the process because this is used to ensure that the final solution meets the customers’ needs even if they change.

Predictions can be tough

Because Agile workers build in small steps, they only ever look a few weeks down the line. Grand plans are not made in the beginning as with traditional software development methods such as waterfall. Instead, smaller plans are made to begin with – in order to deliver an MVP (minimal viable product).

Changes are then taken into account – such as feedback, market conditions, and organizational obstacles – and the developers can act accordingly. Rather like a writer who’ll complete multiple drafts of a piece of work using editorial feedback to make changes before the final piece is published.

The key benefit of this is that time is not wasted on creating a plan that cannot then be deviated from. However, it can be very difficult for employees to predict future results – how things will be in six months’ time could be anybody’s guess as this would highly depend on what changes are required. In fact, sometimes working in an Agile manner can mean that the end product or solution is completely different to what was originally asked for – but it fits well with the customer’s real needs.

Quicker delivery

I trust that you understand by now that the Agile Manifesto is about delivering at speed. Each stage (please see the letter T for more information) follows a cycle: requirements-development-testing-delivery-feedback.

The idea is to offer live demonstrations at the end of each cycle’s final solution, to both show what the team has created and gain feedback from stakeholders to be shared with everyone involved.

Rolling-waves approach

The rolling-waves approach is used in Agile software development as a way of planning what’s to be completed.

Plans are created in waves, starting with high-level assumptions and milestones which then become more defined over time as progress is made and the final requirements are made clearer.

A rolling-waves approach to planning makes room for flexibility such that large changes can be implemented easily rather than acting as showstoppers (as they might if a complete plan is created at the start).

Scrum

I’ve already taken a peek behind the curtain of Scrum, because we looked at the daily scrum meetings – but there’s more to it than this.

Scrum is another Agile approach that can be used for teams no smaller than three members and no larger than nine. Work is split into timeboxed stages called “sprints” that are typically two weeks long (but can last up to a month). Scrum encourages daily collaboration – the daily scrum meetings – and works to ensure that teams are prepared for last-minute changes and able to deliver on time.

Scrum is made up of three roles:

• Product Owner – acting as the representative of stakeholders, responsible for any backlogs and maximizing value from the team.
• Development Team – self-organized and responsible for final delivery at the end of each sprint. The three-to-nine members (developers, designers, writers, testers, etc.) complete their activities and collaborate with other business teams when necessary.
• Scrum Master – helps the team and is responsible for removing any blockers reported during the daily scrum meetings. They also act as a go-between and prevent distractions to the team.

Finally, Scrum is built upon three pillars:  transparency, inspection, and adaptation and has its own five values: commitment, courage, focus, openness, and respect.

Tiny chunks

As you’re now aware, Agile works by delivery-in-stages or tiny chunks. It might surprise you to know that these stages are not actually called “tiny chunks” (Who’d have thunk it?) and are instead known as iterations (the letter I was taken by an important Agile value that I didn’t want you to miss, can you remember it?)

Anyway, it’s these tiny chunks, sorry, iterations, that make Agile … well, agile. Iterations allow developers to make changes as they go, instead of getting too far into development and then realizing that something isn’t quite right. Then changes are made as they’re needed.

Now, how might this be applied to ITSM? Here’s the ITIL v3 lifecycle: strategy-design-transition-operation-improve. An Agile methodology would sit well in the design and transition stages – developing services for operations in a more flexible and faster manner. (I wrote this blog before ITIL 4 was released and – given that ITIL 4 takes onboard the Agile approach – it’s not surprising that ITIL 4 now has an activity called “design and transition” within its new service value chain.)

Unnecessary and necessary rework

Using Agile, workers are very often faced with rework due to the changing, flexible nature of the methodology. Sometimes this rework is absolutely necessary – think of a completed iteration that receives customer feedback and something needs to change. Maybe the customer has thought of a way to improve their original request after seeing a live demo, or possibly it doesn’t work the way they thought it would after all – and so bigger change is required. Whatever it might be, this is called: necessary rework.

Unnecessary rework, however, can damage motivation and expectations. Remember the “rolling-waves approach” for planning which starts by using high-level assumptions. When requirements are vague, developers make assumptions which might take their work in the wrong direction. This then has to be reworked when requirements become clearer, which is one example of unnecessary rework.

Agile workers need to take steps to minimize this unnecessary rework as much as possible – due to the lasting damage it can cause to moral and customer expectations (plus budgets and delivery dates) if there’s too much of it.

Value delivery

The Agile manifesto recognizes that, to deliver value, individuals and interactions need to be prioritized, customers/stakeholders need to be involved throughout the journey, employees need to be able to respond to changes, and working software is the primary way to measure progress.

Less time is spent on documentation, contract negotiation, and planning because these areas do not add value to the customer. For these reasons, Agile is not of course without its critics –but those who celebrate Agile will say that it’s the best way to deliver value, particularly to customers who may struggle to explain exactly what it is they need.

Working software

The fourth and final Agile value is “working software over comprehensive documentation.”

This takes the view that working software is what adds value, rather than spending time creating in-depth documentation which, prior to the Manifesto, was one area developers recognized as a barrier to progress.

While the Agile Manifesto still recognizes that documentation has its place, it’s believed that minimal documentation is needed and not every detail needs to be written down. Thus, this value doesn’t eliminate documentation, but it does put working software ahead of the overly-elaborate documentation related to requirements, specifications, or plans.

XP (extreme programming)

XP is another Agile software development method (I wasn’t going to mention any others, but it was a quick win for the letter X that I don’t usually have the luxury of when writing these A – Z posts).

This method sits well in an Agile environment because it encourages regular releases in short cycles (think of the Agile iterations that we’ve already explored). This is very useful when the “gathering of requirements” stage highlights that the customer isn’t quite sure about what their needs are. The solution can be improved upon within each release and XP uses a checkpoint method where new customer requirements can be added easily.

Your way

A key point about Agile is that, like other practices, it’s a way of working that should be adapted to fit your organization, to let you work “your way.”

Agile practices must be customized if they’re going to be successful – no two organizations are the same, and thus Agile is not designed to be rigidly followed. So, stay true to the values and principles of Agile, and customize it to fit your way of working as needed.

Zero problems

That’s what you’ll have if you adopt an Agile working environment.

It’s not true of course, I doubt there’s any one framework, methodology, or practice that’ll eliminate any and all problems – but if your organization is feeling sluggish and bogged down by slow processes, change resistance, or too much planning, Agile could be one such approach that will help you out.

So, that’s my A – Z of Agile done. What would change or add? Please let me know in the comments.

Note: This comment was posted to LinkedIn by Dave Smith: 

“I was prepared for this to be yet another misinterpreted iteration of the Scrum Guide but.. it’s actually pretty good: it’s definitely approaching from an Agile viewpoint and doesn’t seek to conflate it with Scrum. One point I’ll contend: I disagree with “The whole point of being Agile is to deliver at speed”.  The underlying principle of agile is about being flexible, embracing change and accepting that plans aren’t cast in stone – new things emerge as more is learned, so don’t presume things won’t change; treat it as a learning journey for all involved. Now, whilst it’s not about “deliver at speed” I’ll agree that its iterative-incremental nature means you dripfeed small increments quickly rather than wait until everything’s complete then deploy in one huge go.  This “little and often” frequent delivery cycle can be perceived as delivering results quickly, but the underlying philosophy here is that everything you design, build, test etc delivers no returns until it’s in the hands of the user, so it’s better to deliver a small self-contained working piece than leave it unused on the shelf whilst the rest is still under construction. Other than that – a very informative read.“

This is an awesome point, and in light of this comment, letter H for ‘High Speed’ has been updated accordingly.