Has the agile product delivery model has been too widely adopted?

Posted on : 30-01-2019 | By : richard.gale | In : Uncategorized

Tags: , , , ,

0

As a consultancy, we have the benefit of working with many clients across almost all industry verticals. Specifically, over the last 7-8 years we have seen a huge uptake in the shift from traditional project delivery models towards more agile techniques.

The combination of people, process and technology with this delivery model has been hugely beneficial in increasing both the speed of execution and alignment of business requirements with products. That said, in more recent years we have observed an almost “religious like” adoption of agile often, in our view, at the expense of pragmatism and execution focus. A purist approach to agile—where traditional development is completely replaced in one fell swoop— results in failure for many organisations, especially those that rely on tight controls, rigid structures and cost-benefit analysis.

Despite its advantages, many organisations struggle to successfully transition to agile, leading to an unnecessarily high agile project failure rate. While there are several common causes for this failure rate, one of the top causes—if not the leading cause—is the lack of an agile-ready culture.

This has been evident with our own client discussions which have centred around “organisational culture at odds with agile values” and “lack of business customer or product owner availability” as challenges for adopting and scaling agile.  Agile as a methodology does require a corresponding agile culture to ensure success.  It’s no good committing to implementing in an agile way when the organisation is anything but agile!

Doing Agile v Being Agile

Adopting an Agile methodology in an organisation which has not fully embraced Agile can still reap results (various estimates but benchmark around a 20% increase in benefits). If, on the other hand, the firm has truly embraced an agile approach in the organisation from CEO to receptionist then the sky is the limit and improvements of 200% plus have been experienced!

Investing in the change management required to build an agile culture is the key to making a successful transition to agile and experiencing all of the competitive advantages it affords. Through this investment, your business leadership, IT leadership and IT teams can align, collaborate and deliver quality solutions for customers, as well as drive organisational transformation—both today and into the future.

There are certain projects, where shoehorning them into agile processes just serves to slow down the delivery with no benefit. Some of this may come from the increase in devops delivery but we see it stifling many infrastructure or underpinning projects, which still lend themselves to a more waterfall delivery approach.

The main difference between agile methodologies and waterfall methodologies is the phased approach that waterfall takes (define requirements, freeze requirements, begin coding, move to testing, etc.) as opposed to the iterative approach of agile. However, there are different ways to implement a waterfall methodology, including iterative waterfall, which still practices the phased approach but delivers in smaller release cycles.

Today, more and more teams would say that they are using an agile methodology. When in fact, many of those teams are likely to be using a hybrid model that includes elements of several agile methodologies as well as waterfall.

It is crucial to bring together people, processes and technologies and identify where it makes business sense to implement agile; agile is not a silver bullet. An assessment of the areas where agile would work best is required, which will then guide the transition. Many organisations kick off an agile project without carrying out this assessment and find following this path is just too difficult. A well-defined transitional approach is a prerequisite for success.

We all understand that today’s business units need to be flexible and agile to survive but following an agile delivery model is not always the only solution.

Agile. Is it the new name for in-sourcing?

Posted on : 30-01-2015 | By : richard.gale | In : Innovation

Tags: , , , , , , , , , , , , , , ,

0

Business, IT, clothing are all similar in so much that they can lead and follow fashions & trends.

Looking at IT specifically there is a trend to commoditise and outsource as much as possible to concentrate on the core ‘business’ of growing a business. As we all know this has many advantages for the bottom line and keeps the board happy as there is a certainty of service & cost, headcount is down and the CIO has something to talk about in the exec meetings.

At the coalface the story is often a different one with users growing increasingly frustrated with the SLA driven service, business initiatives start to be strangled by a cumbersome change processes and support often rests in the hands of the dwindling number of IT staff with deep experience of the applications and organisation.

So a key question is –  How to tackle both the upward looking cost/headcount/service mentality whilst keeping the ability to support and change the business in a dynamic fulfilling way?

Agile is a hot topic in most IT and business departments, it emerged from several methodologies from the 1990’s with roots back to the ‘60s and has taken hold as a way of delivering change quickly to a rapidly changing business topology.

At its core Agile relies on:

  • Individuals & interaction – over process and tools
  • Customer communication & collaboration in the creation process – over agreeing scope/deliverables up front
  • Reactive to changing demands and environment – over a blinkered adherence to a plan

The basis of Agile though relies on a highly skilled, articulate, business & technology aware project team that is close to and includes the business. This in theory is not the opposite of an outsourced, commodity driven approach but in reality the outcome often is.

When we started working on projects in investment organisations in the early ‘90s most IT departments were small, focused on a specific part of the business and the team often sat next to the trader, accountant or fund manager. Projects were formal but the day to day interaction, prototyping, ideas and information gathering could be very informal with a mutual trust and respect between the participants. The development cycle was often lengthy but any proposed changes and enhancements could be story boarded and walked through on paper to ensure the end result would be close to the requirement.

In the front office programmers would sit next to the dealer and systems, changes and tweaks would be delivered almost real time to react to a change in trading conditions or new opportunities (it is true to say this is still the case in the more esoteric trading world where the split between trader and programmer is very blurry).  This world, although unstructured, is not that far away from Agile today.

Our thinking is that businesses & IT departments are increasingly using Agile not only for its approach to delivering projects but also, unconsciously perhaps,  as a method of bypassing the constraints of the outsourced IT model – the utilisation of experienced, skilled, articulate, geographically close resources who can think through and around business problems are starting to move otherwise stalled projects forward so enabling the business to develop & grow.

The danger is – of course – that as it becomes more fashionable – Agile will be in danger of becoming mainstream (some organisations have already built offshore Agile teams) and then ‘last years model’ or obsolete. We have no doubt that a new improved ‘next big thing’ will come along to supplant it.

 

Agile – Is it the new Insourcing?

Posted on : 23-08-2011 | By : richard.gale | In : Innovation

Tags: , , , ,

0

Business, IT, clothing are all similar in so much that they can lead and follow fashions & trends.

Looking at IT specifically there is a trend to commoditise and outsource as much as possible to concentrate on the core ‘business’ of growing a business. As we all know this has many advantages for the bottom line and keeps the board happy as there is a certainty of service & cost, headcount is down and the CIO has something to talk about in the exec meetings.

At the coalface the story is often a different one with users growing increasingly frustrated with the SLA driven service, business initiatives start to be strangled by a cumbersome change processes and support often rests in the hands of the dwindling number of IT staff with deep experience of the applications and organisation.

So a key question is –  How to tackle both the upward looking cost/headcount/service mentality whilst keeping the ability to support and change the business in a dynamic fulfilling way?

Agile is a hot topic in most IT and business departments, it emerged from several methodologies from the 1990’s with roots back to the ‘60s and has taken hold as a way of delivering change quickly to a rapidly changing business topology.

At its core Agile relies on:

  • Individuals & interaction – over process and tools
  • Customer communication & collaboration in the creation process – over agreeing scope/deliverables up front
  • Reactive to changing demands and environment – over a blinkered adherence to a plan

The basis of Agile though relies on a highly skilled, articulate, business & technology aware project team that is close to and includes the business. This in theory is not the opposite of an outsourced, commodity driven approach but in reality the outcome often is.

When we started working on projects in investment organisations in the early ‘90s most IT departments were small, focused on a specific part of the business and the team often sat next to the trader, accountant or fund manager. Projects were formal but the day to day interaction, prototyping, ideas and information gathering could be very informal with a mutual trust and respect between the participants. The development cycle was often lengthy but any proposed changes and enhancements could story boarded and walked through on paper to ensure the end result would be close to the requirement.

In the front office programmers would sit next to the dealer and systems, changes and tweaks would be delivered almost real time to react to a change in trading conditions or new opportunities (it is true to say this is still the case in the more esoteric trading world where the split between trader and programmer is very blurry).  This world, although unstructured, is not that far away from Agile today.

Our thinking is that businesses & IT departments are increasingly using Agile not only for its approach to delivering projects but also, unconsciously perhaps,  as a method of bypassing the constraints of the outsourced IT model – the utilisation of experienced, skilled, articulate, geographically close resources who can think through and around business problems are starting to move otherwise stalled projects forward so enabling the business to develop & grow.

The danger is – of course – that as it becomes more fashionable – Agile will be in danger of becoming mainstream (some organisations have already built offshore Agile teams) and then ‘last years model’ or obsolete. We have no doubt that a new improved ‘next big thing’ will come along to supplant it.