Next Stop Agile: All Change?

“Before we become agile, do we really need to change everything?”

I was recently asked this question by a client who is just starting on their agile journey.

The potential of agile to change everything often leads people to think that they have to change everything before they can become agile. Instead of seeing opportunities and potential they see obstacles and barriers, to the extent that they’re sometimes too scared to even dip their toes in the agile waters.

The introduction of agile values, and in particular agile practices such as iterative planning and backlog-driven development, will lead to changes in the quality and timeliness of the software produced. This in turn will provide you with lots of opportunities to improve other things such as organizational structures, communication channels, and funding procedures.

To get started there are a few things that definitely need to be changed. These will be focussed in three key areas:

  • Resourcing teams – the agile and iterative approach requires cross-functional teams. Testers for example will now be needed through-out the project, as will test environments;
  • Reporting progress – the regular iterative assessments can be used to replace monthly or other reports. There will be a switch towards concrete measures and away from “pseudo-measures” such as earned value;
  • Planning projects – projects will now be iterative and incremental rather than waterfall. The number and nature of the milestones will change, although you may choose to start your initial agile projects with a “requirements” phase and end with and “acceptance testing” phase. Note: the development will still be done iteratively with testing done every iteration - there will just be some priming of the pump before the iterations start, and some additional acceptance testing once the development is complete.

Once the teams have developed the capability to produce high quality software quickly and effectively, the door opens for even more improvements – in particular:

  • Just in time and just enough requirements – affecting the product owners, product managers and the business
  • Progressive funding models – affecting how you fund your projects
  • Agile contracts with suppliers – affecting your supplier relationships and contracts
  • Improved team cohesion and longevity – affecting line management and resourcing
  • Agile business change – affecting business projects and business programmes
  • Tools and infrastructure – affecting licensing and environments

And finally, opportunities are opened up for an agile organization, with further improvements to:

  • Line management
  • HR
  • Governance
  • Organizational Structures
  • Company Culture

It is always a good idea to brief all the management and business people involved in the projects and teams as they will be affected by the initial round of change, and will benefit from seeing the opportunities that an improved, agile, software development approach will provide.

The good thing is you don’t need to change everything at once, or even at all in many cases. Personally I would always bed in the first round of changes before worrying about the second and third lists of things. This approach values individuals and interactions over processes and tools, as it enables the development teams to improve without dictating to the other parties involved in the business. Once they see the opportunities opened up by agile development practices they will also want to embrace agility and improve their own ways of working.


1 Comment
  1. Mohan | July 6, 2012 at 4:59 am Reply

    avatar

    I have a specific question about your categorization of EVM as ‘pseudo-measures’. I am a fan of agility but I am also interested in learning about EVM. I read that earned value accounts for the money spent and it is widely used by US DOD projects. I work on Capacity planning initiatives and we use statistical trends. Similarly large projects could be using EVM, Cost uncertainty analysis, risk measures etc. These seem to be real concerns.

    So specifically I wanted to know why EVM is considered ‘pseudo’.

    Thanks,
    Mohan