Decoding Agile Terminology

We’ve had a lot of positive interest in our recent blogs focusing on the hot topics of Agile and agile. But we’ve also heard from a number of clients and readers that there’d be real value in demystifying and decoding Agile terminology or jargon. So, here goes!

Firstly, let’s reiterate the difference between Agile with a big ‘A’ and agile.  ‘Agile’ is an approach to project management (we recently published an article on integrating change management within an Agile project environment) and ‘agile’ (we also published a blog on what it means to have an agile mindset) is a mentality or trait.

Today I’m focussing on Agile and some of the key terminology which goes along with it.  This is really important, not least because your feedback indicated so, but also we’re now seeing Agile being adopted much wider than the software industry where it started out – we’re working on Agile projects with clients in industries as diverse as pharmaceutical and construction, and we see a lot of terminology get used and misused.

You don’t have to be an Agile expert to leverage some of the principles and get the most out of your people. Here are some of the main terms/concepts and what they mean, how they can be useful in a business change context, and of course, everyday team working.

Scrum

Scrum is an Agile process framework – not to be confused with Agile methodology. Scrum encompasses ‘scrum team’, ‘scrum master’ and ‘daily scrum.’ A daily scrum or huddle is one of the easiest Agile concepts to introduce into your day-to-day business context. When working through an intense period of work (e.g. leading up to a major project milestone, a launch or other major deadline) – daily ‘scrums’ bring the core team responsible for meeting that deadline together for a short, focused meeting, typically at the start of each day. This is an excellent way to level-set and make sure a) progress from the previous 24 hours is shared and b) priorities for the day ahead are agreed. It’s also a great way to share issues or concerns – and diffuse any feelings of anxiety or pressure among the team.

Sprint

A set period of time during which specific work has to be completed and made ready for review or use. There are often many ‘sprints’ during the lifecycle of product or project development and each sprint can vary in duration – typically between one and four weeks.   They can be done virtually – but are by far most valuable when conducted face-to-face.  From a change and communication perspective – getting people together for a focused period of time, with a specific target, is one of the most productive ways to work because you rapidly build rapport and relationships (stakeholder management), learn useful business insights ‘on the ground’ (change context) and absorb the language and tone of the organisation, program or initiative.

Minimal Viable Product

A product that will meet the fundamental needs of your customer. Although ‘MVP’ isn’t typically associated with everyday business strategy or deliverables – it’s a fantastic way to motivate and focus efforts to produce a basic product, by a clear date, rather than getting side-tracked or caught up in details which can cause delays. For example, devising a clear organisational change strategy in which key sponsors and stakeholders agree and accept can be challenging. There is no ‘right way’ to deliver change, but senior leaders often have a strong opinion of how it should be done.   The focused environment of an Agile sprint and the pressure of a deadline helps to drive through the complexity and various number of opinions. The MVP also encourages teams to rally around this goal. All team members feel invested in the result, so they naturally pitch in to ensure problems are solved and roadblocks overcome.  If the team is made up of cross-functional representatives – there is also great benefit from different approaches and perspectives to solve the problem.

Products

A product is a tangible ‘thing’ that needs to be designed, re-designed and tested thoroughly.  When applying these principles to a change strategy or stakeholder map for example – it results in a far more robust and accurate outcome.

The elements that create the MVP. When dealing with the people side of change – we don’t often think of change and engagement activity as ‘products’ – but in an Agile context, all deliverables are defined up front as work packages or products. In this way, it forces you to think about your outputs a little differently.  A product is a tangible ‘thing’ that needs to be designed, re-designed and tested thoroughly.  When applying these principles to a change strategy or stakeholder map for example – it results in a far more robust and accurate outcome. Of course, we are accustomed to drafting, seeking input and reviewing documents, but the Agile environment supports you to ‘road test’ more rigorously and effectively because the people you need are on call and they understand the urgency and importance of what is needed.

KANBAN

Roughly translates to ‘Billboard’ in Japanese. It’s a visual ‘to do list’ with clear sections to show progress of each product. As tasks are completed – you move through the stages from ‘not yet started’, ‘in progress’ to ‘complete’. The KANBAN board becomes the ‘playbook’ of work that needs to be completed by the people in the room. Physically displaying the MVP in the space the team is working in is incredibly beneficial. It’s not a spreadsheet or a set of bullet-points in an email. Seeing what must be delivered, and who owns each item – makes it much easier to see who is accountable for what and how people can help each other. It also promotes a fair split of work as it’s clear where people’s time is being spent. In the context of change management and communication – visibility is incredibly useful for strategy alignment and message consistency. Because everyone’s work is discussed iteratively, consistency is naturally woven into the work. Everyone is working on the latest version or evolution of an idea – which saves a lot of time and makes the product more powerful.

At Afiniti, we regularly work with clients, building their change management capability and integrating with their Agile projects.  If this is a topic you’ve been thinking about recently and you’d like some advice on how to get started integrating change into your Agile projects, or how to set your Agile projects up for success, get in touch and we would be happy to discuss this further.

Likewise, if you have any examples you would like to share around integrating change management within an Agile project, it would be great to hear from you too.