What is Agile anyway?

I get asked a lot, what does it mean to be Agile? The word Agile is now used so much that it has perhaps lost some credibility.  I’ll blog/present about Post-Agile soon (you lucky bunch).

A lot of companies would rather be seen to be “Agile” rather than really understanding it and gaining the organisational, cultural and financial benefits it should deliver.

So what does Agile mean, at least what does it mean to ‘me’?

‘Me’, in this context of being a former Scrumdamentalist (or Scrum bore, #theonlywayisscrum, Scrum preacher teacher) and a now more considered Agile evangelist.

Well, I’ve found it useful to use the below, an annotation of the Agile manifesto for software development as a help sheet when talking people through it.

photo (11)

I also get asked which courses/training I would recommend for Agile, as it’s a set of values and principles and not a set of fixed rules and processes.  The courses available can at times differ in content, context and approach.  Thought leaders in Agile tend to disagree not only on the most appropriate courses to take but also the actual validity of them.   The value is not in the course but in the application of the principles to your organisation. That is not to say that there aren’t any good learning resources available, we just have to find them.  There is also a vibrant Agile community in London and the wider UK, Europe and the World that we are tapping into.

Anyway I digress.

Looking at the above doodles I’ll expand on the points that I picked out:

Firstly priority; Agile encourages a list of value based, small and easily understood prioritised items of work.  To understand the value of something to our business and our customers we work on the highest value things first.  To help avoid an impossible situation of “it’s all top priority” whilst something might be dependant on something else, we can always produce a value based absolute priority list; by that I mean there is only one thing at the top of the pile.  That is what we work on next….

Lean underpins Agile and the keywords in Lean are based around removing waste, delays, defects and deviation, delivering value, small batches and working closely with the customer.  I like Lean a lot too.  Lean will be another great thing in the reed.co.uk toolkit.

In Lean we aim to learn, so learning from failure is just as important as delivering a successful product.   Learning is how we improve.  Early and continuous delivery is what the customer values, and by that we are delivering working/usable and valuable things (software or in the context of a non-software team a product or service).

In Agile we also welcome changing requirements.  By working together daily and making visible the things we are creating, being open to having our work inspected and being willing to adapt means we will get the best possible result.  We should make changes as early in the creation of something to avoid lots of waste and re-work later.  It also means the outcome is what the customer needs rather than being something they wanted some time in the past.

Constant pace is another important principle.  Being predictable about the quality and consistency in our ability to deliver things.  Not through long hours working to unrealistic dates but by having the autonomy to be in control of our workload, in control of what we are committing to.  Importantly then also having focus to deliver what we committed to, not being distracted by things and trying to work on multiple things at once (the dreaded context switching).

Technical excellence and MVP (Minimum Viable Product) – the misunderstanding that getting the minimum delivered means poor quality.  Not so; we must pride ourselves on high quality and finding new ways to make ourselves more efficient and effective.

As we value learning we must utilise the art of defining MVP (delivering the minimum viable first step into the market).  This means we can start learning from the customer and make positive changes to the experience without waiting until we deliver the whole feature list.  No one likes building or creating something that either isn’t used or is completely re-worked.

We should always be solving a customer problem and as such have a hypothesis to be tested, this then lets customers critique our original ideas and to challenge our thinking.

Self organising teams – part of having autonomy is to also organise ourselves in the most efficient way possible, rather than having pre-defined and dictated teams with set titles and fixed boundaries.

Retrospectives, boy do I love retrospectives.  This self organising autonomous team must have a trusting environment.  Nothing is off limits.  We discuss all things that we can change to make us the best we can be.

Culture eats strategy for breakfast so we are all responsible in making sure the culture is the best it can be.

I had an Agile conversation with a colleague, that is a conversation about Agile and he was kind enough to record my mutterings….

If the scope of a project is known, what is the best way to approach it?

You said (roughly):

– break the task into small chunks of work

– build one element end to end to test

What is the best way to approach a project in general?

You said:

– Aim to deliver the minimum viable product (what is the simplest thing we can do to get the benefit?)

– Traditional Waterfall style projects with x% completion tend to overrun as people tend to hide issues/delays until late on in the project

– Agile methodology encourages a more even pace across the life of a project

What about regular pieces of work with repeated elements?

You said:

– Techniques such as Lean and Kanban can be useful

– Map out the different parts of the project and identify where value is added in order to minimise the wait/waste

– Until something is delivered, the task is 0% complete

If the project is 0% complete until a deliverable has been produced, for these type of projects how would you report on the stage of completion?

You said:

– The project is divided into different phases with items of value being delivered regularly. Stage of completion is determined by the number of deliverables produced

Other comments:

– In any project it is difficult (impossible) to fix the time, quality, and scope without compromising on one of them

– In an Agile project, it is determined at the start of each phase what can realistically be delivered. This should mean the team work at a constant pace, which (in theory) eliminates overtime

– Test early, fail fast

– Retrospectives – regular meetings to discuss how the team are working together.

Opportunities to air annoyances and identify ways to improve working practices

– Whole premise of agile is to keep the needs of the end user/customer in mind by keeping them close to the project throughout its duration


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: