Ian Spence avatar

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.

Measuring Outcomes not Causes – Making Measures Inspirational not Punitive

As discussed in an earlier blog post, you need to measure the desired results.  If Agility and Agile Transformation is going to make you better, then look at the things it is going to make better and set some targets.  If it is going to make you faster, then look at the things it is going to make faster and again set some targets and track against them.  If it is going to make you cheaper and happier, then focus on those things.  This approach begins to make your measurement framework much more inspirational.

Historically, many organisations struggle with their Organisational Measurement getting any traction.  I have seen many organisations where every year they introduce some key performance indicators and by the end of they year, they have abandoned them.  I have seen many organisations with large dashboards with graphs no one understands and no one looks at but a lot of money is spent on them.

You need to change this whole approach.  Measurement needs to change at the organisational level to become more agile – valuing people over processes – collaboration over contracts etc. All the great things from the Agile Manifesto should be visible within your measurement program as well. 

A balanced scorecard organized around the four goals of better, faster, cheaper and happier is a great place to start.  Recently, we worked with KPN and implemented a organizational measurement program using the better, faster cheaper, happier framework. It was an excellent framework for their organisation. It allowed them to look at what is important in terms of getting better – Were they becoming more predictable and were they delivering a higher level of quality?, faster – cheaper - , and happier -    The framework allowed them to look at the problem areas and phrase questions that business and IT could understand. It was so successful that everyone in the whole organization, including the business, embraced the measures with both enthusiasm and commitment. See the case study / webinar for more details.

A better, faster, cheaper, happier balanced scorecard provides a way to communicate the effectiveness of IT in a way that everybody in the organisation can embrace and understand. It also allows you to measure success in a way that is independent of the processes used by the projects and teams being measured – essential if you want to demonstrate that an agile approach is better than more traditional approaches or build a platform to enable you to continually improve and adapt your agile way-of-working.

Better, Faster, Cheaper, Happier: An Agile Balanced Scorecard

Better, Faster, Cheaper, Happier: An Agile Balanced ScorecardAdopting an agile approach has a lot of benefits, not just when developing software and improving team working but for all aspects of our business. When it comes to measurement, I recommend that we all take an agile approach and keep things simple, open and adaptive to change. 

A simple, intuitive score-card is essential for any team or organization embarking on any form of agile adoption or transformation. The Better, Faster, Cheaper, Happier framework provides a great starting point for motivating and measuring your changes.

Agile: What’s the Point?

Let’s stop and think about why businesses get involved in agility.  What is the promise of agility that is so attractive to businesses?  What we at IJI have found when talking to business people is that agility is appealing because of the belief that better products will be built.  Not only will they be better software products but they will be built faster and cheaper than before. The promise is certainly there  and this is what people want to see as they make investments in agile adoption and, in particular, any kind of large scale agile transformation. 

The other significant result claimed for agile ways-of-working is that there will be an overall increase in everyone’s happiness - happier customers; happier users; happier sponsors; happier purchasers, and happier developers. Read More

Let’s measure the things that really matter

Let’s measure the things that really matterAs technologists, we tend to collect very detailed information and present it in a very technical way.  We talk about things like process maturity levels, and productivity indexes. I have even seen some measurement data about Agile maturity models that attempt to show how agile we are.  The problem with this kind of approach is it doesn’t provide anything that the business and the customers can relate to. 

The business does not really care how agile we are, they want to see results.  They want to be able to set targets, see improvements, and understand the benefits and the quality of the results being generated by IT. Only then can they begin to put the value of Agility into context – the context of the value and improvement generated by the move to agility. Read More