Making Agile work for you – a practical guide

In a growing number of cases, we are asked to assure projects that employ some form of Agile development process. It is clear the Agile approach is gaining in mainstream acceptance. However, no methodology has all of the answers and we are seeing some recurring, specific challenges in its deployment. In this piece, we examine one of the key challenges: how to embed Agile thinking into your organisation. It really does require a complete change in point-of-view if you are historically organised around traditional ‘waterfall’ gated development processes.

We are continuing to investigate the boundaries, whilst building an agenda for the next Intelligent Projects Forum to be held on Wednesday 11^th June. We will continue this series of articles to explore some of the other challenges that we have encountered, including:

• Can Agile be successful in technically complex ‘greenfield’ developments?
• Managing Agile in a fixed price/fixed scope environment
• Managing test and acceptance around the sprint process
• Agile and offshore developments

Part 1:  Organisational change for Agile

Agile is appealing, as colleagues and experts idealistically describe it as:

“… Leaner, faster, cheaper”

“… The best way to deliver value and change”

“…Visualisation supports quickly informed decisions”.

For business users the benefits are usually less clear but it’s entirely possible to create a collaborative working team to deliver true added business value.

It sounds tempting, but there really is no such thing as a free lunch; for your first Agile project you will need to invest time and money, creating the right environment to enable the method to deliver.

Enabling cultural change at all levels

There is a school of thought that Agile allows projects to deliver ‘faster, better, cheaper’, but this is not the complete story.  More precisely, it is the impact of a more collaborative culture that improves performance. ‘Faster, better, cheaper’ relies on collaboration within the combined business and development team – the cultural change is the dynamic, not the method itself.

Agile requires a fundamental change to many organisations and people’s thinking. It recognises that things change in real life – in real time. It allows us to highlight issues more quickly and to focus on what is valuable first. It challenges people, culture and structure.

Agile is about delivering value to the business, and will require engagement at all levels of the company. It is not a ‘techie thing’ - if considered a ‘techie thing’ it will not work or deliver the efficiencies that are possible. The key challenge is getting the business to understand the way it needs to collaborate with a development team using an Agile approach. Collaborative working is tough in large organisations - and this new way of working should be considered a change programme, as it involves emotion and needs managing as such.

Enabling individual change

Agile encourages people to think and act differently. Teams are smaller, with collective responsibility and participation, through daily stand-ups, planning, demos and retrospectives. Thus, individuals are constantly on-show, receiving constant feedback from within the team and from the sponsor.

The shift from a predictive to an adaptive approach, and the increased transparency, can unnerve some team members - especially when confronted with ‘fail fast, learn faster’.

Doffing a cap to the Satir model (which illustrates the lifecycle of a change process), we need to:

• Encourage team members to seek improvement information and concepts from outside the group
• Help team members to open up, become aware, and overcome the reaction to deny, avoid or blame
• Help build a safe environment that enables people to focus on their feelings, acknowledge their fear, and offer reassurance or help the team find new methods for coping with difficulties
• Help management avoid any attempt to short circuit this stage with ‘magical’ solutions

The high performing team

The manual says: “cross-functional teams of around 5-7 people should come together to work on a project”, allowing the whole to ‘swarm’ a feature. [Note the impact on peoples’ perspectives if they complete a feature in an hour!]

Here are a few nuggets we picked-up, to enable the team to become high performing:

• Empower the team to resolve issues within the team, resist the temptation to ‘chuck it up the chain’.
• In building the culture it is critical that ‘the team is seen as the team’. Treat them all the same – regardless of seniority, employment status or longevity
• Ensure experts/key specialists are not working in silos - knowledge is shared and enables succession planning
• Always ensure that they add business value, rather than just ‘being clever’.

It is also worth considering Tuckman’s model for newly formed teams:

Building the team

When starting out with Agile, full and comprehensive training is essential for all business and development team members, the necessary senior executive, and the sponsorship team. This means a change of emphasis for the project manager/team leader – they are there to ensure focus and to remove barriers to progress. Begin by trialling Agile with a small non-critical project alongside a combined business and development team that want to do it.

Above all, recognise that every team is unique, every project is unique, and the organisational context is unique. Whilst this may seem obvious, we continually see projects dealing with issues as a result of trying to shoe-horn delivery into a ‘one-size-fits-all’ approach. Examine the key roles and ask yourself who is best to fill them, ignoring each individual’s current job title and focusing on their capabilities to do the job in hand.

Co-location

Co-location of user and development teams is always preferable and enhances iterations and business relationships. It is especially important for business users to see and understand how iterations develop, not just be passive recipients of them.

Working in an Agile way when the project team is not co-located can prove difficult. Time zones make Scrum impossible (real time rituals don’t work), however there are tools to help. With committed and respectful leadership it can work, but only once the organisation has some experience of managing in an Agile way. For your first Agile project co-location is a must.

Co-location does not just mean putting everyone in the same building. The most effective collaboration happens when people are in the same room, with whiteboards containing key information, updated as it happens.

Co-ordinating/planning/prioritisation

A key principle of Agile is that teams organise themselves once they understand their objectives. Managers (and Scrum Masters) manage the optimisation of the teams, ensuring structure to allow team co-ordination and to remove impediments, without meddling and tinkering.

Establishing the overall priority of development must come from the business value being added by any specific feature.  The product owner, or whole team, will provide input as to what should be done next (there are arguments for doing the most valuable first, or where there is high risk to be mitigated).

Agile encourages us to review the portfolio of work on a more regular basis.  It is critical that executives do not tell the Agile team what to do next week; dependent on the business, they should be looking three months ahead or more.

Leadership and performance

We all recognise that there are advantages to an Agile approach. In a traditional project approach we are not necessarily encouraged to ask questions as soon as we think of them. Yet in Agile, ‘fail fast / learn faster’ is most definitely encouraged.

It can be difficult for leaders to recognise who is performing and who isn’t.  To team members, it is more apparent, and if individual members are not working well – they should be encouraged to discuss, share and coach.   Leaders need to be confident and lead by example.

Business Users, Project Managers and Team Leaders should together work to:

• Create the design framework
• Remove system-wide impediments
• Create the right environment (no ‘them’ and ‘us’)
• Create the strategy
• Manage the portfolio
• Have confidence in the system

This article does not provide all the answers, but hopefully it contributes towards the discussion.  To be continued at our Intelligent Projects Forum on Wednesday 11^th June.

Footnote: Many thanks to Johanna Rothman, Cameron Black at GiffGaff, and Qualitest, as well as Pelicam's Adrian Keefe and Phil Butterworth for their contributions.

Comments

[Dan Payne]

Article definitely contributes to the debate.

Other things to consider in future articles/discussions:

- 'Appropriate documentation' shouldn't be interpreted as 'no documentation'
- Need to think carefully about how to keep the wider group of stakeholders informed about what's expected to be delivered and by when, as this requires more effort when things are changing quickly.