Agile and the Agile Mindset

When dealing with companies moving towards Agile as a process, occasionally I will deliver a presentation offering an overview of Agile to set a context for the future conversation. The presentation itself is not an in depth treatise on Agile processes; in fact it’s pretty lightweight as these things go, but it does serve as a catalyst for conversations and offers a forum for questions, which is the real purpose.

As organisations begin to change their processes, there is a natural tendency for people to resist that change because change takes us outside of our comfort zone. Resistance then is often cry for ‘help’ or maybe a cry for ‘bring me with you’. It’s easy to get a blinkered view on Agile, to assume that not only does everyone recognise the benefits, but also to assume that everyone knows what exactly Agile is.

The presentation, which I’ll post somewhere soon to let you see what I’m talking about, offers a whistle-stop tour of the Agile Manifesto to set the stage followed by a review of the shopping list of different Agile / Lean / XP processes / methodologies  / approaches (I’m going to call them systems from now on) that all refer back to that manifesto. Just a note that currently there’s 15 systems listed in the presentation, and that’s trimmed back.

The Bluffers Guide

I then offer my own ‘Bluffers Guide’ to agile, which I’ve reproduced here.  If you find yourself stuck for dinner conversation, you might want to give it a go – I offer no warranties to the outcome.

• Build working code, not documents
• Deliver in small incremental cycles
• Reflect on what happened
• Repeat the good, eliminate the bad (I attribute this to Charles Darwin (sort of))
• Communicate directly, frequently and honestly
• Be transparent
• Let teams self-organise
• Create an explicit definition of done
• Create simple rules and be uncompromising in their application

Adapt to Survive

From there I remind the group of the single most important point of any agile process: it’s empirical.

• The processes changes to fit the organisation
  • Transparency, Inspection, Adaptation
  • The organisation then gets some new capabilities
• The organisation adapts to the new capabilities
  • Starting the cycle again
• There is no ‘one true way’
  • Other than the way your organisation defines
• Focus on what adds value
  • Don’t waste your time on wasted processes

There’s usually a bit of a disappointed sigh as the realisation dawns that in fact there’s no silver bullet, no magic wand or fairy dust that will be sprinkled to help the organisation fly; they just need to put their heads down and get on with defining their own process.

Now, before all of the agile purists and internet trolls start calling for my head, I don’t mean to imply that Scrum, Kanban, TDD, FDD, BDD, DSDM or any of the other catalogue of methodologies, frameworks or processes are in any way wrong, better or worse than each other. If you examine any of the above systems, you will discover that they all clearly state that they are empirical processes, and as such should be adjusted based on what is observed to be working. By logical extension then, whichever one you pick is a starting point for a journey, not a final destination.

Use Common Sense

Worse is yet to come in this presentation where I highlight that none of the major systems deal with all of the other processes that an organisation from the smallest to the largest will need to deal with. Performance reviews, sales functions, customer acquisition, marketing, human resources to name a few are all outside of the purview of agile systems (generally). The upshot is that if you have perfectly effective processes before the adopting agile, then will want to hold on to those if the new agile process doesn’t offer an alternative. Sounds logical, right? You’d be amazed how often I have to have this conversation. The message then is apply common sense:

• The Agile processes are not all encompassing
  • Purely development, not organisational
• An agile mentality must extend beyond the development teams
• The best approach is a hybrid approach
  • You can’t test what isn’t developed
  • You can’t code what isn’t specified
  • You can’t deploy what isn’t built
• Waterfall, Agile or Lean will all fail without appropriate behaviours
• Your approach must meet the business needs

At the earliest stages of a project the progress can and does look very ‘waterfall’. Kanban, or lean, can also look very waterfall but nobody seems to be terribly enthusiastic about acknowledging that. But why should this be a problem? In the final equation, we must focus on the outcome, we should’t be wary of a waterfall style process blended in with our agile processes if that’s what’s going to deliver the best outcome.

While involved with one organisation I was challenged with the the question:

“When we were doing waterfall we used to have this approach to testing to ensure that quality was maintained, but now that we’ve moved towards agile we’ve left that behind but what should we replace it with?”

My first question was ‘WHY?’ This organisation has been in business for twenty plus years, and has a reputation for producing high quality systems. Why would you change your acceptable quality levels? Why would you throw out a process that was clearly highly effective and acknowledged by the people who are paying for your services? Ultimately we brought large portions of the old process back into the system, adjusting it slightly to deal with iterative / incremental deliveries. Don’t throw the baby out with the bathwater!

It’s a Mindset, not a Process

Naturally, particularly since I charge for my efforts, my audience are looking for some useful result from the presentation.

I encourage them to consider that the success of their undertaking is not contingent on the process, but rather on the mentality of the team engaged in the transition. Remember to bring your people with you, in parallel to presenting value to the organisation, you must also demonstrate the value of the future state to your people. When considering that future state I offer the following story:

Imagine your team is a special forces military unit. You’ve trained them, mentored them and now you’re dropping them into the jungle to achieve a goal. Every one of the team successfully lands safely, pack up their chutes and prepare to move out. They immediately notice that there’s a tree in their path – a tree in the jungle who could have foreseen that? – a team with the right training and an agile mindset will chop down the tree, or blow it up, or work around it or tie a rope to it and ‘Tarzan’ their way around it. What they won’t do is stop; they won’t let this thing get in the way of achieving their goal.

On the other hand a team, even with the right training, but with the wrong mindset are more likely to call home to there superiors. You can imagine the conversation:

“Ehh sir, we’ve encountered an impediment, there’s a tree here – it wasn’t marked on the map”

“Not on the map? How can that be, we planned this mission to a granular level”

“I’m not entirely sure sir, but it’s definitely a tree and it’s definitely in the path – what would you like us to do?”

“Let me get some experts in to discuss this”

“Thank you sir, we’ll just wait to hear from you”

And so the team waits for head office to confirm their next course of action.

Create Space

Agility, then, is a two way street, the organisation must want to change their behaviours to move towards an agile agenda, and they must put mechanisms in place that allows agile to operate.

Equally, the people in the organisation must have an appetite for change and that appetite cannot be dictated – you’re not going to be able to order someone to have an agile mindset. You can mentor, train and engage with them, but you must also demonstrate the value to them so that they can make the mental leap.

Finally you must create the space for the process to thrive. Leaping in to micromanage at the first sign of an issue will stifle any change and ensure that all motivation and enthusiasm for that change will dissipate.