Everything you want to know about Agile: How to get Agile results in a less-than-agile organization

INTRODUCTION

The Harvard Business Journal recently advised that the successful delivery of IT initiatives is a joint responsibility between the people who develop solutions and the business areas that require those solutions¹²:

Success requires a sustained commitment for the managers who will use and benefit from the initiative, not just IT.

Agile approaches are built around the very concept of collaborative work between IT staff and business areas; however, Agile takes the idea further by advocating that the only way to truly know whether IT initiatives are consistently meeting business requirements is to actively involve the business area (the customer) in the regular review and refinement of fully functional, fully tested system capabilities. Agile works on the premise that detailed user requirements specification documents and prototype screens are no substitute for getting direct feedback from the customer’s hands-on review of working capabilities in their solutions. Equally, there is no better way to measure quality, relevance and progress than having the project team consistently deliver fully functional, fully tested, production-ready software capabilities.

As an IT director, you know that staff can spend as much – if not more – of their time reworking delivered software than they spent developing the original solution. One of the greatest advantages of allowing customers to review fully functional capabilities during the development process is that it provides them with the opportunity to see how the business requirements that they envisaged actually behave. This allows them to adjust system functionality, screen layouts and business rules to most effectively meet their needs while the solution is being developed (i.e. the time when your staff will be able to implement these changes more quickly, with fewer overhead costs, and less risk to the overall system). It means that the solution that your staff deliver will be more valuable to the business, more likely to be accepted for production release, and more likely to result in satisfied users. However, the benefits of Agile approaches extend far beyond the significant reduction in time that your staff will spend reworking solutions at the end of the development life cycle.

IT projects traditionally include endless piles of planning and specification documents that need to be created before development work on a project can even begin. Although creating these documents can be a very time-consuming activity, it often pales in comparison to the amount of time that staff spend reworking them as the project progresses to accommodate:

•   Adjustments to system capabilities based on constraints found during software development

•   Updated business requirements based on changes that occur within the organization (e.g. new management directives, staff departures, funding reallocations)

•   Updated business requirements based on changes that occur external to the organization (e.g. fluctuations in market demand, announcements from competitors, the availability of new technologies)

•   User requests to change system behavior as a result of acceptance testing

•   User requests to change system behavior after it has been released in the live environment.

No amount of detailed planning – even by the most experienced IT resources – can accurately predict the changes that will occur during the course of a project. This is why Agile approaches replace upfront planning with incremental planning based on the collaborative work between the project team and the customer. Working jointly with the customer provides staff with an ongoing opportunity to more easily adapt solutions (and supporting documentation) to reflect the changes that occur within the organization – and external to the organization – as the project progresses. It enables your staff to refocus their day-to-day efforts on delivering outcomes instead of endless documentation, and to focus on incremental planning instead of spending time making retrospective adjustments to originally agreed upfront project plans.

This focus on high productivity is also why Agile approaches require project teams to produce fully functional, fully tested, production-ready software throughout the project. This allows the project team to identify – and resolve – technical and usability issues as early in the process as possible.

The end result is that Agile approaches enable staff to shift from a heavy reliance on the inaccuracies of predictive development work to the efficiencies of emergent development work that is aligned with the ongoing needs of the organization. This would be an ideal model, were it not for the fact that most organizations manage their work in exactly the opposite way.

One of the greatest difficulties in successfully implementing Agile approaches comes from the fact that organizations generally structure their overall operations around upfront planning. Annual reports, yearly budget allocations, business plans, sales forecasts, marketing plans and staffing strategies are generally developed well before the scheduled work is undertaken. Departments are expected to reasonably estimate (i.e. predict) their workloads, budget utilization, resourcing requirements and outputs at the start of the reporting cycle; and managers are then measured by how well the actual work undertaken meets their original estimations. No matter how productive Agile approaches are for IT initiatives, they still need to fit within the core constraints of the overall organization. So, how does an approach that is based on adapting work as it progresses fit within an organizational environment that is based almost exclusively on upfront commitments? Answering that question is the core objective of this