General enquiries :
+44 (0)20 7602 6000

How to be Truly Agile: Mindset Over Process

Monday 8 June 2020 Project Management

Victoria Shakspeare's picture
By Victoria Shakspeare

So, you think you’re Agile but you’re not getting the results you expected. You’ve applied all the right things: you work in Sprints rather than to milestones, you’ve got a Scrum master and you have user stories rather than requirements.  All the boxes have been ticked so you can call your teams Agile. But it doesn’t feel Agile.

Your organisation isn’t alone.  The transition into new working practices isn’t easy or quick.  Without understanding the core values behind this transition it’s easy to expend a lot of effort doing Agile rather than being Agile.

The Agile Manifesto

The first step is understanding the core values of Agile:

The manifesto aims to unearth better ways of developing software. Whilst the items on the right are still valuable, the items on the left are of higher importance.

Key Conundrums

Do any of these resonate with you?

1. But that’s the way we’ve been told to do it...

Your team has adopted a new process but because they don’t understand why, they don’t evolve it to the changing needs of the team, customer or project. By following multiple processes as a tick-box exercise, your teams don’t get the full value that working in a new way can bring. Sure, you have daily stand-ups, but no one listens to each other and it’s just a distraction from the day job.

2. But the documentation hasn’t been signed off yet...

For development teams that have been used to working in a waterfall environment, the idea of releasing subsets of functionality with partial documentation into the wild can be scary.  So instead of incrementally releasing functionality that can be run past the user community, capabilities are still released in a big-bang, milestone style, losing the opportunity to incorporate feedback as you go.

3. It’s not my fault/But I didn’t think that was my responsibility...

Despite being described as cross-functional, your project teams still sit in silos of stakeholders, architects, developers and testers and despite sharing a project backlog, people don’t really talk to each other or understand what others are doing. The idea of a one team culture has been floated but the project team is still ‘us’, the customer is still ‘them’, and the concept of really breaking down those walls rather than paying lip-service to it is alien.

4. But that’s not what the requirements say

Signing up to a well written, stable user requirements document is a comfortable place for a development team to be, but that’s not what Agile is designed for.  If your development team doesn’t feel empowered or motivated to adapt what they’re doing to meet their customers’ evolving requirements, both sides of the partnership can end up feeling like they have reached an unsatisfactory compromise.

If you recognise any of these four scenarios, it’s a key indicator that your organisation is falling short of understanding the core values of Agile. Next, we’ll discuss how to tackle these issues.

Overcome the Barriers to Success

The following solutions offer a way to avoid the common pitfalls when trying to get Agile right.

Understand the Core Values

For your organisation to maximise the benefits that Agile working practices bring, you need to understand the essential components of what Agile actually is.  It’s not about becoming experts in the use of Scrum, Kanban or SAFe, but focusing on collaboration and flexibility. Getting these essential components right and  applying them to the way your team works results in better software, happier developers and stickier customers.

Team Buy-In

You may understand the core values, but they’ll only work in action if every member of your team, supplier and customer, is bought into them. One way to do this is to ensure that each team regularly evolves their version of agile, personalising the process so that they have ownership of how they work. Running ideas sharing sessions with customers to establish open communication helps eliminate the ‘us and them’ mentality, ensuring your customers are fully bought in to this way of working too.

Stay Flexible

Without a culture of supported agility, new ways of working will never stick. Agile is not just about following a process but adapting constantly. Embedding this change is essential, which means regular check-ins on projects and emphasising the ability to divert from plans if needed.

There are many ways to mix up how your team is working:

  • Stand-ups becoming repetitive? At the end put someone in the hot seat to explain what another member of their team has done and what their blockers are.
  • Retrospectives feeling tedious? Rotate the person hosting and mix up the format.
  • Sprint lengths not giving the team the right amount of time to get through tasks? Change them. There are no hard and fast rules.

Don’t Dwell on Documentation

Incorporating feedback as you move along a project is one of the essential facets of Agile, but one of the most difficult for teams to adjust to. This can mean changing the usual rigorous – and rigid – user requirements documents and adapting to evolving customer needs. This doesn’t mean documentation should be abandoned altogether, but it should play a more flexible role.

As an organisation, we have successfully delivered a huge variety of Agile projects to a wide range of customers. We have positively evolved our Agile working practices to meet both our customers and internal needs. Adapting has enabled us to embark on exciting and challenging projects, keeping our Engineers happy and, in turn, our customers even happier.

Want to know why you've set up your team to be agile but you haven't got the results you were expecting yet? You may find the answers here.

How to be Truly Agile: Mindset Over Process