Chapter 2: What Can Agile Do For My Organisation? – Agile: An Executive Guide – Real results from IT budgets

CHAPTER 2: WHAT CAN AGILE DO FOR MY ORGANISATION?

Agile is not for everyone

Agile is not the answer for every organisation. Dynamic organisations and organisations with unsustainable IT overheads are likely to receive a much greater ROI from implementing Agile methodologies than organisations that are not facing these challenges.

Agile methodologies are primarily intended to manage the risk of change in software requirements, including the need to incorporate information that emerges during the development process. Accordingly, Agile is ideally suited for situations where the outcomes are dependent on variable factors, such as resource availability, customer preferences and market fluctuation. It allows organisations to manage these unforeseen circumstances by expecting – and embracing – the impact that these changes can have on ongoing software solution requirements.

Equally, Agile is intended to improve the quality and sustainability of software solutions by creating a more positive and productive work environment, by encouraging greater communication between technical teams and business areas, and by instituting quality control measures throughout the software development process. Therefore, Agile methodologies are ideally suited to organisations where there are ongoing issues with:

  • the quality of the delivered solutions
  • the ability to deliver software solutions within agreed time lines and/or budgets
  • the ability for delivered solutions to adequately support business requirements
  • high turnover rates (or low productivity levels) in their IT departments.

The level of benefit that your organisation is likely to receive from utilising Agile methodologies is directly correlated to the following risk factors:

  • your organisation’s level of exposure to external change, including changes in customer requirements, fluctuations in market demand, announcements from competitors, and the availability of new technologies
  • your organisation’s level of exposure to internal change, including changes in user requirements, staff departures, business priority shifts, and funding reallocations
  • the sustainability of your current IT overheads, including costs of development, implementation, maintenance and support.

Therefore, if your software solutions are based on highly predictable and replicable business processes with a minimal likelihood of changing requirements, then your organisation will not achieve the same level of benefit from Agile as an organisation that is more susceptible to solution requirements that are likely to change over time.20

The same is true for organisations where current software solutions are delivered on time, align well to business requirements and require minimal ongoing support to address quality and usability issues.

In each of these situations, Agile methodologies can provide some degree of benefit to the organisation, but not the dramatic benefits that organisations with more dynamic (and less sustainable) software solutions can achieve.

The bottom line is that the more that your organisation is faced with changing requirements and/or unsustainable IT overheads, the better positioned you are to receive substantial returns on your Agile investment. Yet, before we identify what Agile methodologies can do for your organisation, it is important to identify what they cannot do; and to clear up some common misconceptions surrounding these methodologies.

Dispelling Agile myths

Agile is a ‘quick fix’ solution

Implementing Agile methodologies in your organisation will not change your IT balance sheet from red to black in a matter of weeks, or even months. Time is needed for staff to become familiar with these approaches; to refine their use of Agile to align with the specific requirements of your organisation; and to organically grow the use of Agile to a sufficiently critical mass of IT projects that can offset the losses from traditionally managed software projects.

Instead, think of Agile as an investment in your organisation’s IT future, particularly in reducing the whole-of-life costs of maintaining, supporting and extending the software solutions that you deliver.

Agile projects do not require planning

Agile methodologies have, at times, received an unjustified reputation for being an ‘ad hoc’ approach to software delivery. However, nothing could be further from the truth. In reality, Agile methodologies replace one-time up-front planning with the ongoing refinement, re-confirmation and adjustment of plans throughout the delivery process to reflect the most current information available to the organisation. In this way, Agile surpasses more traditional approaches that rely upon a large up-front plan which is likely to become obsolete by the time it reaches the printer.

Agile projects do not require documentation

In the same way that Agile methodologies have been mistakenly believed to be ‘ad hoc’ software development approaches without proper planning, these methodologies also fall victim to the misunderstanding that they can be implemented without system or business documentation. This is also untrue. Agile practitioners understand that organisations rely on formal documentation for compliance purposes, as a record of communication, etc. In fact, for some Agile methodologies, such as DSDM, the production of formal documentation (e.g. the Feasibility Report) is a mandatory requirement for teams to progress to the next stage of work.

The difference with Agile methodologies is that active face-to-face communication is generally the preferred method for exchanging information; whereas formal documentation is produced to the extent that it is appropriate for the organisation.

For example, Agile teams prefer to replace the need for extensive formal system requirements documentation with interactive sessions where participants can discuss business and technical requirements face to face, ask targeted questions, and provide direct feedback to refine these requirements. The ‘documentation’ of these sessions is generally done through the ongoing production of working software that reflects the outcome of the discussions.

Where formal requirements documentation is required by the organisation, it is often produced retrospectively, during (or even after) the release of the system. This not only allows the technical team to focus on their core work during the development process, it results in documentation which is often more cost-effective to produce (e.g. by using screen captures from the actual system), and which tends to better reflect the actual behaviour of the released system.

Agile projects are unmanaged

Agile methodologies encourage a different form of management than traditional organisations may be used to. Instead of top-down mandates and closely monitored staff, technical teams are empowered to do the work that is required under the guidance and oversight of stakeholders. This results in the establishment of self-organised teams.

The following quote from General George S. Patton, Jr. is an amazing testament to the power of self-organised teams:

Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.

Even in a military environment, General Patton understood the value of directing his troops and then trusting them to get the job done. Agile methodologies are based upon the same underlying premise of both guiding and empowering people in order to get the most value from their work.

Self-organised teams can provide the organisation with several benefits, including:

  • planning based on specialist, hands-on knowledge of the work that is required to achieve business objectives
  • more realistic estimates of the work that the team can achieve
  • motivation for the team to want to achieve the work that they have actively committed to
  • natural skills and strengths compensation, where technical teams divide and conquer the work required based on the relative skills and strengths of each team member.

Management is able to oversee the productivity and value of each technical team’s work through Agile measuring and monitoring tools, such as executive dashboards, product backlogs and Kanban boards. Arguably, however, the most definitive method of oversight is the team’s ongoing production of tangible, high business-value outcomes.

Agile is too risky (or radical) for our organisation

The idea of implementing methodologies that:

  • encourage the evolution of business requirements, instead of relying upon up-front signed-off documentation
  • empower the technical team to self-organise, instead of controlling their daily activities
  • replace reams of documentation with face-to-face communication

may seem a bit daunting for some executives (and terms like eXtreme Programming probably do not do much to allay these concerns).

The Who uses Agile? section in the previous chapter identified a number of highly reputable organisations worldwide that use Agile methodologies, including several (e.g. Microsoft, Yahoo!) who have published case studies documenting the benefits of these approaches. These are not rogue start-up organisations with radical notions of success; they are organisations with structured key performance indicators (KPIs), bottom-line imperatives and accountability to shareholders. If Agile methodologies are able to deliver significant business-value benefits to these organisations, it is reasonable to expect comparable returns in your organisation. The challenge is in turning these benefits into ROI metrics that align with the specific challenges that your organisation is facing.

Your Agile ROI

Identifying the potential return on your Agile investment (‘your Agile ROI’) is contingent upon four primary factors:

  • the business value that your software solutions generate
  • your current costs to develop and implement software solutions
  • your current costs to support, maintain and extend the software solutions that you deliver
  • your current costs in managing staff turnover, including hiring costs, re-skilling, and loss of corporate memory.

Although there are indirect costs involved in calculating your Agile ROI, such as the loss of prospective business due to problems in previously delivered software solutions, the four primary factors above represent the most tangible (and quantifiable) costs for you to consider in your decision to implement (or not to implement) Agile methodologies.

The ROI that your organisation can expect to achieve by implementing Agile methodologies is directly aligned to the 10 core Agile business benefits identified in the previous chapter, specifically:

For both commercial and in-house software solutions:

  • Containment of software development and implementation costs by:
    • reducing the risk of development budgets being squandered on low business-value or misaligned features
    • reducing the risk of software development budget blow-outs due to technical and architectural issues that are discovered only after significant investment has been made
    • controlling ongoing budget expenditure at each iteration by deciding to proceed with, adjust, postpone, or stop ongoing iterations based on the business value of demonstrated results to date.
  • Greater ongoing return on software development investments by:
    • receiving valuable, tangible outcomes every month, instead of waiting until the end of a year-long initiative before any ROI is achieved
    • accommodating organisational, industry and technology changes throughout the software development process, so that previously undertaken work can retain much of its business value.
  • Reduction in whole-of-life software costs by:
    • minimising the potential for software errors, usability issues, or misalignment with business needs
    • increasing the extensibility of the software solution to accommodate ongoing changes.
  • Reduction in employee turnover rates (technical team members) by giving them a more positive, rewarding and supportive work environment, with fewer last-minute ‘fire-fighting’ activities that create unnecessary stress in the workplace.

In addition, organisations who deliver commercial software solutions can expect to achieve the following ROI benefits:

  • greater customer retention rates (and potential for add-on sales) by consistently delivering higher-quality software solutions that are more relevant to customer needs
  • stronger market positioning for the positive reputation that results from the delivery of higher quality and more relevant software solutions.

Similarly, organisations who deliver in-house software solutions can expect to achieve the following additional ROI benefits:

  • reduction in operational costs by having software solutions that more closely align with the needs of the business
  • a corresponding reduction in the employee turnover rates of business users by providing a work environment that encourages the communication of their requirements, and software solutions that genuinely meet their ongoing needs.

It is important to note that the introduction of Agile methodologies is not likely to result in a substantial decrease in software development costs. In fact, in the initial implementation of these methodologies, there are likely to be additional overheads associated with training and knowledge sharing, establishing supporting technologies (e.g. automated testing environments), and establishing centralised locations for technical teams to work and collaborate.

Instead, Agile methodologies are far more likely to result in cost savings by delivering software solutions that are of a significantly higher quality, have far greater usability, and are much more aligned to the highest priority business needs of the organisation.

Therefore, the most relevant ROI calculation for your organisation is not likely to be a side-by-side comparison of software development costs for projects using traditional processes versus Agile methodologies; it is a side-by-side comparison of the whole-of-life costs of developing, maintaining, supporting and extending each of these software solutions, as well as tracking turnover rates for both IT staff and (where appropriate) the business areas utilising these solutions.

In Chapter 3: Five Steps to Agile Success, strategies and guidelines are provided to enable you to measure quantitative and qualitative returns from your organisation’s Agile work.

Your organisational culture

Earlier in this chapter, it was identified that Agile methodologies are not for every organisation, explaining that dynamic organisations and organisations with unsustainable IT overheads are better positioned to receive substantial benefits from using these methodologies. There is, however, another element in the ‘Is Agile right for my organisation?’ equation: your organisational culture.

In order to determine if Agile methodologies are truly suited to your organisation, you need to ask yourself the following three critical questions:

  • Is management willing to trust staff to get work done without constant supervision?
  • Could the structure and culture of the organisation support a distributed, self-organising team management model, i.e. where management is not at the centre of all activity?
  • Is the organisation prepared to change their ‘business as usual’ routines?

If the answer to any of these questions is No, then implementing Agile methodologies in your organisation may be a challenge (if not an impossibility) without a significant change in your organisational culture. Thankfully, you are likely to be in a far better position than others in your organisation to institute this change.

The following sections outline the core cultural factors that are necessary for Agile methodologies to succeed in your organisation.

Trusting the team

At the heart of Agile methodologies is the firm belief that people can – and will – do the right thing by the organisation if they are given the opportunity. If the senior management of an organisation sees employees as unmotivated people who have to be supervised closely in order to get any work done, they will be far less willing to entrust technical teams to self-organise. (The irony is that these same managers rarely appreciate that a corporate culture of mistrust breeds unmotivated people.)

Agile methodologies rely on the mutual trust (and dependency) that emerges between stakeholders and technical team members:

  • technical teams depend upon the expertise of stakeholders to accurately identify, communicate and prioritise the business requirements
  • stakeholders equally depend upon the expertise of the technical team members to regularly produce outcomes that meet these requirements.

The stakeholders determine what high-priority goals the organisation needs to meet; the technical team determines what high-priority work they are in a position to deliver, and the technical solution which is best suited to achieve these goals. If either group falters, the process fails.

Equally important is the establishment of trust within the technical teams. Open communication, skills and strengths compensation, and camaraderie can only be achieved in a work environment that values teamwork and discourages finger pointing. If the technical team is not working as a cohesive whole, then the benefits of Agile methodologies may be lost before the process even begins.

Relinquishing the need for management to control everything

In Dispelling Agile Myths, it was identified that self-organised teams are ideally positioned to provide the organisation with:

  • specialist, hands-on knowledge of the actual work required (versus top-down mandates from managers with more limited knowledge of the technology)
  • more realistic estimates of the work that can be achieved (versus ‘paper plans’ that are based on assumed levels of productivity and limited awareness of competing staff commitments)
  • motivation for the team to want to achieve the work that they have actively committed to (versus the work that is thrust upon them)
  • natural skills and strengths compensation (versus allocating roles, responsibilities and recognition to individual members of the team).

It was further identified that the structure of Agile methodologies means that managers do not need to keep a close watch on every step that the technical team makes, because they know that they are never more than a few weeks away from seeing the tangible results of their work.

The interesting thing about the dynamic of self-organising teams is that, as they progress, they are able to create ongoing motivation for employees. Technical team members know that their continued ability to self-manage their work depends on their regular delivery of high-value business outcomes. Additionally, because they are the ones who identify what work can (and cannot) be achieved in each iteration, they are motivated by their personal responsibility to achieve these outcomes. This combination of factors is heightened by the satisfaction and pride that technical team members feel when they produce tangible outputs that truly meet the needs of the organisation.

Therefore, in order for Agile methodologies to work, managers who have traditionally maintained heavy-handed control over the day-to-day work of their staff will need to be willing to relinquish that control in favour of trusting and empowering their staff. As an executive, the power rests in your hands to promote this shift in management style, or to strategically select the right managers when introducing Agile projects to the organisation. (See Choosing the right kick-off point for further information on selecting the most suitable Agile projects for your organisation.)

Eliminating the ‘business as usual’ mindset

There is no doubt that Agile methodologies require organisations to act – and think – differently to the way that they have in the past. Those organisations which are self-aware (and humble) enough to recognise that their business practices of the past may not sustain them into the future, will be more amenable to considering Agile methodologies, especially given their widespread support and long history of success. In contrast, employees who are committed to ‘the way we do things around here’ are likely to see Agile approaches as too radical for their organisation. The bottom line is that Agile methodologies are a significant change in the way in which an organisation will operate – but change can be for the better.

Even if your organisation is facing all three of these cultural barriers, it is important to realise that they are not insurmountable obstacles. There are proven approaches for laying the groundwork that will allow your organisational culture to support Agile methodologies. In Chapter 3: Five Steps to Agile Success, guidelines are provided for selecting, implementing and expanding Agile projects to suit even the most conservative organisation.

Your decision

The decision to shift to (or even trial) a new way of doing business can be daunting for any organisation. There may be inefficiencies in your current business processes – and times when you wish that staff were more productive – but is this enough of an argument to forego the ‘devil you know’ in favour of unchartered territory? Moreover, even if you are convinced that your organisation has room for improvement, that does not necessarily mean that moving to Agile methodologies is the answer.

Agile methodologies may seem like a radical shift for some organisations, but they have also been proven to produce radically improved outcomes for those organisations that have applied them.

The most compelling argument in favour of trialling Agile methodologies is the fact that it costs your organisation very little to get started. In the same way that Agile protects the organisation from the risk of large up-front commitments, equally it does not require a large up-front commitment from the organisation in order to be used. This can make trialling Agile approaches in an organisation a cost-contained activity, which the organisation can opt to expand (or reduce) without having jeopardised a significant financial investment.

In Chapter 3: Five Steps to Agile Success, strategies and guidelines are provided to help your organisation choose the right starting point for introducing Agile methodologies, for baselining and monitoring the ROI in your Agile projects, and for expanding the use of Agile, as appropriate, to meet the ongoing needs of your organisation.

20 Organisations with highly predictable and replicable processes may achieve greater benefit from the use of lean manufacturing techniques to minimise their overheads in these processes. See More Information on Agile for resources on lean manufacturing.