Ways of Working: Reframing the Conversation About Agile

It is time to reframe.  Instead of talking about agile, talk about ‘ways of working’.  The end result is the same, although getting there will be a lot easier.  In particular, the conversation is likely to be a lot more powerful as a result.      

Take Care Using the Word ‘Agile’

It seems like everybody is talking about agile these days. Once the preserve of software developers it is now a hot topic in management circles too. As leaders, we are told that a fast changing and unpredictable world demands nothing less!

There is agile strategy and agile execution, as well as agile marketing, operations and just about everything else. So much so that the word ‘agile’ is in danger of being over-used. Some leaders are beginning to see it as just another over-hyped management fad.

While ‘agile’ is now a commonly used term, it is not yet a widely understood concept.  Indeed, for many leaders it can generate anxiety and concern.  The word ‘agile’ can scare some people off.  All this points to the need to be more selective in the use of the word ‘agile’.

The debate about agile is really a debate about ‘ways of working’ – that is finding the most efficient way of getting the work done. As the following event from a client organization shows, starting the conversation there can be a powerful way of delivering ‘agile by the back door’.

Talking About ‘Ways of Working’

The conversation was going really well. There was continuous nodding and agreement as the project leader and the consultant discussed ways of working on the project.  However, it was not until to the end of the conversation that the word ‘agile’ slipped-in.  That was deliberate,  the newly appointed development lead – an experienced consultant – knew that the term ‘agile’ , although two decades old, could still cause confusion and even anxiety. 

‘I am not an expert in agile’ was the project leader’s response, ‘…but everything we have discussed makes perfect sense.’ she added.  

Agreeing Shared Principles

The conversation was aimed at agreeing the right way of working on the new app – an interface to the bank’s legacy systems. The project manager and development consultant had quickly agreed on the first two points:

• There will be documentation, but not reams of it.  Instead, we will focus on usable software released regularly. 
• We will work to the plan but will be ready to adapt based on progress, obstacles that emerge, changing requirements and so on. 

Care had been taken in the words used. In particular the inclusive nature of the language. For example:

• ‘There will be documentation but…’ 
• ‘We will follow the plan but…’ 

This careful wording was aimed at tackling ‘head-on’ a concern held by many: That ‘agile means chaos’. The consultant was anxious to say there will be a plan and there will be documentation, although they are – in the consultant’s words – not the ‘main event’ and that there ‘won’t be much ink wasted’ in creating them (i.e. they will be short).  

Principles to Guide the Work

There were two more practical aspects of working on the project, which the manager and development lead were of one mind:

• Let’s interact regularly via zoom to tackle any issues as they arise.  

• Let’s bring the stakeholders inside the fence and enlist their collaboration throughout the process.

These two points were clearly common ground.  As it turns out, both people disliked surprises and preferred to be kept up to date on a regular basis.  They also believed that it was often better to have a conversation than to write long emails or reports.  

The project leader was determined that bureaucracy – something that his organization did quite well – would not get in the way of the work being done.

When it comes to stakeholders, both held similarly customer-centric views.  It is not that they did not find stakeholders frustrating at times, but they were determined to prevent a ‘them and us’ situation arising.  Collaboration with the customer was regarded as essential and the key to preventing surprises.  It would ensure that the project stayed focused on the customer’s needs and, equally important, it would enable customer and stakeholder expectations to be managed.

Agile by the Back Door

‘I often try to have full conversations without using the term agile’ the consultant said after the meeting.  ‘Yet, what is been talked about is very agile’ he added.  

The focus is on finding the most practical and efficient way of working.  It just makes sense to most people, that: 

• It is better to check progress every week rather than every 6 weeks 
• The output should be inspected regularly as it is created, rather than just when it is finished. 

It is common sense really – however when you start to put labels on it – calling it ‘agile’ – that is when things can get complicated, even scary.

The Agile Manifesto

When it comes to the right way of working it is hard to be original. Without knowing it, the project lead who professed to ‘not being an expert on agile’ had in effect just outlined the key points of the Agile Manifesto.  The 4 ways of working now agreed, mirrored the 4 key tenets of agile almost point by point.  

‘That is the great thing about agile…’ thought the development lead.  ‘…You don’t need to be an expert in agile’.  ‘It is not like Scrum or Kanban – there is no specific methodology to follow or to be certified in’ he added.   

‘Agile is a philosophy (about a way of working) more than a methodology. What it boils down to is whether you can embrace the values and principles.  That to me is what being agile means’.

‘You let the principles guide how you act – the details then whether there is a lengthy project plan, stand-up meetings or post-it notes and Kanban, is informed by the principles’ the consultant explained in a passionate tone.