Let’s take the simple example of Symptai Consulting Limited. As a consulting firm, we do not focus on software development, however, we have adopted Agile principles in how we conduct our various projects/engagement by doing things like providing incremental reports and having the clients involved in finalising the reports throughout the reporting process.

The traditional project approach for consulting firms, whether it be penetration testing, solution selection or business process re-engineering, typically includes planning, testing, assessment and then reporting after all the procedures have been completed. This approach can generally lead to multiple iterations of the final draft report as client feedback might lead to re-work, additional testing or a change of scope which then leads to extended project timelines and scope creep. The Agile approach, however, would see issues/findings being reported in real-time throughout the lifecycle of the project. This provides an opportunity for the client to respond immediately so that the identified issues can be addressed in real-time which leads to project risk mitigation. Such an approach to consultancy projects brings out a few of Agile’s core principles, including:

• Customer (client) satisfaction comes first.

• Delivering a working product i.e. A report that provides good business value; and

• Working together with the business persons/client throughout the project.

Why Agile?

Agile is a bottom-up approach. It focuses on empowering the end-user to increase adoption which leads to increased productivity. Take for example a solution selection project: Agile simply says, in order to be successful, you must consider and include the opinions of all stakeholders. All too often we identify the major stakeholders to be the Heads of Department and assume their opinions are the only ones of true value. However, agile requires you to bring together all the relevant stakeholders which would in most cases be the end-users. End-users have granular insight into all your processes and procedures which allows them to inject the daily functional requirements into the selection process on a continuous basis to make iterations and changes based on actual system performance needs.

Is Agile a Waste of Resources?

Agile does not have to be resource-intensive since it can rely on smaller teams and smaller time outputs thus breaking up larger project life-cycles into smaller brief touchpoints. This decreases the time demand on human resources who are still required to perform their regular day-to-day functions. The biggest challenge to the Agile methodology today, however, is, Agile operating in a traditional work environment.

Agile adaptations that still operate within a procedural infrastructure and choose to implement Agile in isolated teams or departments are usually subject to the time constraints of the traditional procedures. Take for example, an organization trying to adapt to Agile as a way of working for the entirety of their organization. The departments that are operating in an Agile manner still rely on traditional departments to approve or implement changes. An Agile sprint may put out a change to an application or process in 2 weeks to a month, but internal processes dictate that change has to go through 4 weeks of user acceptance testing, security testing and 3 weeks of vetting by Risk and Compliance before it can be released to production. So while the development team is ready to implement a change in 2 weeks, the application update is not released for another 7 weeks.

The Agile methodology would require a member of the various departments to be involved in the Agile team so as to perform ongoing tests for quality assurance, risk and compliance, legal etc. to allow for any issues/concerns to be addressed/mitigated throughout the development of these changes. To ensure that at the end of 2 weeks the change(s) are ready to go to market rather than needing separate project timelines for each department and having issues being raised for resolution late in the process.

Final Thoughts

Agile is necessary because it is logical and is very adaptive! We are now recognising the need to do things that are practical. If we take the traditional waterfall approach where the customer says I want a mode of transportation from point A to point B, we may identify that the best and quickest way to travel (based on the customer needs) is a car. But building this car may take us several months to a year to build, test and release to production. In the interim, a bicycle may be the best substitute, which would take us 3 weeks to build. We could also build on top of the bicycle to then deliver the customer a motorcycle in 3 months. Neither as effective as a car, but still providing more value to the client than the one-third of a car we might have built to this point. And with each iteration, we take lessons learned and use them to build a better car than what we would have conceptually designed from scratch. With this, we are immediately getting a return from each stage simultaneously providing the customer with tangible value as opposed to receiving no value for up to a year and then giving them a car they may not be satisfied with.

In addition, the customer’s needs may have changed throughout the year and they have now moved on from the need for a car to needing an aeroplane and had we not had continuous dialogue with the client we would not be aware of this change until we have completed the process of building, testing and implementing a car only to then recognize the market has already moved on. In order to adapt the Agile methodology, one should take time to understand the twelve principles and then identify where they can be applied in their current processes/procedures. One should also embrace change and sensitize anyone impacted by the change, this includes customers and process owners.