A brave new world for digital leaders

May 2017

Skier performing stuntPete Jones, a partner at nlighten, shares some personal experiences concerning the introduction of agile methods into companies. He hopes that they will help you to maximise value and minimise pain related to your agile change.

Some businesses adopt agile ways of working to make the firm more ‘nimble’ - able to react to changes in market conditions and customer needs. Some expect agility to increase the throughput of development teams.

The former may succeed, the later unfortunately will not. Agility is about delivering more of the right stuff and less of the wrong stuff, not more stuff.

Despite agile having been around for almost 20 years there remains some confusion about what agility actually means. In practice a significant number of transitions to agile fail to deliver the expected improvements. The text below gives some insight into possible causes and offers some solutions

What is agility?

Agility was initially defined in the agile manifesto (2001). The manifesto defines a set of behaviours expected from agile teams. There are a number of frameworks that support agile ways of working and can be used as a basis for an agile implementation. (Some still see agile as a synonym for one commonly used framework).

These frameworks present tools and techniques that help agile teams operate, however, they typically cannot encompass the mind-set change required to support true agile behaviours and it is these that bring real value.

Further, some frameworks focus entirely on process steps within technical teams and ignore critical topics like governance, budgeting etc. A good approach is to understand the various frameworks and select the one that is the best fit for your business then evolve that framework to meet your needs based on experience.

It is important to resist the urge to adapt the framework before you start as there will be a natural tendency to incorporate aspects of traditional ‘waterfall’ ways of working.

Primary agile frameworks:

  • Scaled Agile Framework (SAFe), scope: enterprise, introduced in 2011, delivery involves very complex change
  • Agile Business Framework, scope: enterprise, introduced in 1994 as DSDM
  • Scrum, scope: technical team, introduced: forever.mature; a simple agile process / excludes governance and other enterprise aspects
  • XP, scope: technical team, introduced: 1996-1999, simple agile process / excludes governance and enterprise aspects.

Key mind-set enablers for agile

Adopting a framework alone will not make your organisation agile. Any framework adoption must be accompanied by substantial mind-set change in order to deliver maximum value to your business.

Some of the key mind-set changes that face organisations that are transitioning to agile working are described below:

Fail fast and learn:

  • Agile teams need to learn from failures and rapidly learn and correct failures, whether in the product or in their development process
  • Many developers from the traditional development world are used to being punished for failure so will be uncomfortable putting failures on the table
  • Agile organisations need to develop an environment of trust where team members can openly discuss failures early so the team can come together and jointly do what is needed to resolve the issues. The earlier this happens the better for all.

Respond to changing customer needs:

In traditional development environments, requirements are frozen before development work starts. In practice, needs and requirements have and will always change during development.

There are a few things that need to happen here;

  1. Development teams need to learn to be receptive to changes to requirements during the development process. This could be either new thinking for the solution under development or re-prioritisation of pending work
  2. The business needs to understand the consequence of change. Introducing better (higher priority) ideas into the backlog of work that has not started is a good thing, however, this does mean that things will fall off the bottom of the backlog
  3. The business needs to accept this does not mean that everything can remain fluid for the duration of the development. If work has started on something that is about to change there will be a related impact on the development.

Rapid decision making:

In traditional ways of working we accept delays to development whilst points are clarified. Such latency would destroy the flow of agile teams. The agile world needs business to be engaged with development on a daily basis and making decisions as needed.

HR considerations

It is important that teams work together well. For this reason, agile introduces the idea of self-organising teams that bring the right mix of skills and personalities together. Both supporting portability of staff between teams and hiring resource with an appropriate personality to fit a team will no doubt stress traditional HR organisations so it needs some thought.

Further, bonus schemes that reward individual team members are not ideal in agile environments so team bonuses should also be considered.

Take home

If you would like your business to become more nimble by taking the agile route you can maximise the value of the change by managing it at the enterprise-wide level. More than a development process change it needs to involve both mind-set and cultural change in many parts of the business.

About the author
Pete Jones is a partner in the firm nlighten, an Anglo-Swiss agile change consultancy specialising in the adoption of the Agile Business Change Framework. He has over 20 years change experience working in the UK, Denmark, the Netherlands and now Switzerland.
 

More articles relating specifically to Project Management can be found in the two latest editions of our Digital Leaders publication: bcs.org/digitalleaders

Image: iStock.com/CreativeImage

Comments (2)

Leave Comment
  • 1
    John McGarvey wrote on 3rd May 2017

    Hi Peter,

    Re - Primary agile frameworks: Hirotaka Takeuchi and Ikujiro Nonaka introduced the word 'scrum' as a term in the context of product development in 1986 in their article on the New New Product Development Game.

    It is therefore not 'forever' but generally accepted as 1986. Several comparative sources agree on this date.

    Kind rgds
    John

    Report Comment

  • 2
    Pete Jones wrote on 3rd May 2017

    Hi John,

    Yes, I am aware of the paper, IIRC it was published in the HBR. It was certainly the starting point for much agile work and as such the birth of agility.

    I should strictly have referred to this date, you're correct.

    Regards,
    Pete

    Report Comment

Post a comment