Are you really Agile?

“Agile” is most definitely one of those words which is used liberally in sales brochures, delivery reports and in fact any form of communication which is attempting to show the reader that the team at hand is working “differently”.

Under the banner of Agile are a number of “processes” – although we have to be careful with that term of course as that could eradicate the core principles..

Two such processes are Scrum and Lean. Scrum is a software development framework that focuses on the people and Lean is intended to optimise and focus on the process. Fundamentally Lean introduces two core concepts – eliminating waste and improving flow. Six Sigma follows the same two concepts – its main difference is how it identifies the root cause of waste.  The main difference (as I understand it) is the Lean’s focus on waste is determined by whether a customer is willing to pay for it and therefore anything that does not add value is removed (whereas Six Sigma would assert that the waste comes from unnecessary variation). Of course in reality, anyone looking at something seriously would try and take both points into account

Everyone (well anyone that has looked into it) will know the Agile Manifesto, but what about the Lean principles. Given its focus on removing/reducing waste – as you would expect it is cyclical process that constantly reviews and checks the value from the customer perspective and identifies all the right steps to get to that maximum value position

Lean talks about “flow”; which is how smooth the interaction should be within the system – no matter what system is being referred to from a production system or knowledge worker – the latter being why Kanban boards are used in order for work not to get “stuck” at any particular stage

So, lots of strong reference material but are you agile/is the organisation you are working within agile? Interestingly but nor surprisingly, if you google “how agile am I” the most common responses are from the big Consulting organisations who would love to see a big bundle of work to tell you….

So I have found a few simpler anecdotes and some real points to clarify:

The anti-patterns of Agile: (in other words, these are the “old-world” ways of working)

  • The ‘Send/Receive’ and ‘Save As’ buttons initiate most team communication
  • Your white boards are mostly white
  • “Test-driven” still refers to your car
  • You don’t yet know what  MVP stands for
  • You spend more time trying to manage project dependencies than remove them
  • Someone still believes the Gantt Chart
  • Developers only develop, testers only test, and managers just manage
  • Simplicity is presumed to be simple, and
  • A Change  (Decision) Control Board meets…

So taking the more Agile-positive approach, some more structured assessment points:

  • Team Comms – minimal vs open/trusting/face to face
  • User Accessibility – limited offsite vs constant on site
  • Team Location – highly distributed vs co-located
  • Team structure – department top down vs cross functional small teams
  • Delivery frequency – infrequent vs frequent
  • Measurement of progress – phases, tasks, documents vs features, business value, working software
  • Ability to change direction – low vs high
  • Testing – manual, post code vs integrated, automated, test-driven
  • Planning approach – up front and detailed, vs just enough adapative, continuous
  • Process philosophy vs  – static, audited vs analyse, adapt, improve


So firstly, it may be obvious but a fundamental point is that “Being Agile” and “following a Lean framework” isn’t binary i.e. its not that one day you weren’t Agile and the next day you are .  Even from the lists above it is clear each is on scale from nothing to something.  It’s  very much a cultural, organisational and personal change. Looking at the all various checkpoints and assessments queries, it is very likely that you/your organisation will start off reading the points and agreeing they sound right but you know in reality you are not putting them into practice. So like anything in the “big problem” space, bite off a smaller manageable activity and test it out.  There will be some factors and constraints that are very difficult initially and of course I would suggest the biggest constraint of all is how you manage the customer both at a working level and at a Contractual level.   If your customer hasn’t moved at a relatively similar pace they will be asking for all the things you are suggesting are no longer required and this will create a tension.  So don’t start your next transformation program to be immediately Agile but hive off a small customer request to try out some of the techniques.  Remember one of the key mottos – fail fast…but even this at a cultural level could be a significant challenge – so be sensitive

Finally, there is an additional perspective ( What Simon Wardley is advocating is actually that you should use the correct method at the correct time, there is definitely not one size fits all but agile, lean, Six Sigma most definitely have a good place to sit

To quote: Personally, I’d learn to map and use all the methods. Personally, I think the idea of being ALL agile, ALL lean or ALL six sigma should die. The concern is whether this would ever happen and this is because of Law of Requisite Variety (Ashby’s Law of Requisite Variety in management -). which means (in simplistic terms) that you either have to accept the complexity or pretend that it is actually simple and apply a single method  – and unfortunately the latter tends to rule





Leave a Reply

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

You are commenting using your 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