Agile has become one of the buzz words of the last year with organisations moving towards an agile approach to help with problem solving and projects within their businesses during lockdown. However, the underlying concepts of Agile development were first introduced by the Agile Manifesto in 2001. Firms can now look at how they might continue to use Agile as we forward beyond the pandemic.

Here, we talk through how some these principles work in practice, and take you through how the team at Clarasys applied those tenets to a project we worked on a while back.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Of the 12 principles set out by the manifesto, the first (displayed above) very succinctly captures the central philosophy of Agile methodologies. Delivering early and continuously, putting the customer first and, most importantly, delivering a product that is perfectly aligned with customer expectations, are all vital factors in any project, be it solution-based or otherwise.

For this project, we used Agile to help a charity properly implement their Salesforce system. This organisation was seeking to grow; it had already opened one new office and had plans to open further branches. However, the charity’s inability to use Salesforce effectively to help organise its events, internships and mentoring programmes was putting a spanner in the works of its expansion plans.

“Welcome changing requirements, even late in development. Agile process harness change for the customer’s competitive advantage.”

We chose Agile because of the way it lends itself to changing project requirements – no matter how late in development the project may be – and because of the importance it places upon individuals and interactions, rather than just on tools and processes. In the early days, the path towards the solution was by no means clear. But by applying Agile to Salesforce, we were able to make this uncertainty productive by building and creating until the path became clear.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Agile’s emphasis upon using working software rather than solely written documentation was also a significant factor, alongside the focus upon customer collaboration over and above utilising contract negotiation. Finally, we knew that Agile’s ethos of responding to change, rather than following the set plan no matter the costs, would offer real advantages to the project.

And, in turn, Salesforce really lends itself to Agile, since its an easily-adaptable system and enables all of the team to work on the system simultaneously: creating, building and testing. We were able to create and build in safe environments by utilising sandboxes that mirror the live production environment, but simultaneously ensure that if something goes wrong during a build the real data will not be affected. Using sandboxes, we were able to create live working models to demonstrate to key stakeholders at the end of every week – a crucial part of the Agile method.

In short, Agile allowed to work productively and effectively without the necessity of knowing the project’s final destination, using what we knew and developing along the way. With Agile, we we were to respond and adapt iteratively to make certain that the final product we delivered was the right solution.

Starting the project

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

As with every project, at the beginning the sheer volume of work appeared enormous and finding out where exactly we should start was our first preoccupation. We had the team, we had the motivation, but we needed to break the work down into bite-sized, easily digestible chunks.

We kicked off by running through the business process we had discerned via client workshops and, based upon this material, gathered and generated user stories. These user stories were then organised into epics and roles from these epics were delegated to the development team. In this way we created our project backlog. Next were timings, which described how much time needed to be allocated to complete each of the tasks we had identified. Then, the backlog needed to be stored, in a way that enabled teams to track which tasks within it had been done, which are in progress and which are yet to be tackled, for which we used Version One on this occasion.

With all this in place, it was time to plan our first sprint.

Sprint planning

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This project was just six weeks long, so to keep track we decided our sprints should be weekly. At the beginning of every week we held sprint-planning sessions. These meetings were a crucial part of the process, enabling us to assess where we were headed for during the forthcoming sprint and what we had left to complete. We would supplement this weekly meeting with a daily 15-minute standup, where we would discuss our plans for the day, what we had achieved yesterday and what still needed addressing.

Both the sprint-planning meeting and the standup were carried out with Agile principles of continuous development, changing requirements and regular interaction in mind, to enable us to be a successful and self-sufficient team.

Whilst deciding what to take on within our first sprint, we opted for the Sunshine Path approach. This involves understanding what is the organisation’s main function – that is, what delivers the most value – and focusing upon delivering it. By making sure we didn’t get caught up with fringe cases we could ensure that we delivered the most value at the earliest possible opportunity for our client.

We felt that this approach would not only help us to structure our first sprint but would also be the key to subsequent sprints.

Sprint demos

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

One of the most important facets of the Agile method is to include the client at all stages of development and to have a working demonstration ready to go by the end of a sprint. During this project, we had weekly demonstrations, as well as regular meetings with the charity’s CEO to inform him of progress.

These demonstrations proved enormously useful for two reasons: firstly, it meant that every employee at the charity could see where the project was headed and secondly it meant that any implementation problems that may appear at go-live could be identified early and worked through.

This second point is really significant. Frank and meaningful conversations about potential solutions need to be sustained every single step of the way. Waiting to raise issues at the end of the project may well be too late. With Agile, solutions are flexible and the client’s wishes are incorporated every single step of the way.

Sprint retrospectives

“At regular intervals, the team reflects on how to become more effective, then adjusts its behavior accordingly.”

Understanding where things can be improved and how to change your approach or style of working to achieve this in the next sprint – together with ensuring that you align your efforts with your client’s goals by staying on the Sunshine Path – are all very important.

The sprint retrospective is the place where all this can be done in a safe environment – here problems are addressed and successes celebrated. Using the Agile methodology in this way means everyone within the team can air their grievances and talk what should and should not have happened – meaning everyone can begin the next sprint fresh and ready to tackle the next challenges.

So why follow these Agile principles?

Agile comes from the Latin agere meaning “to do”, and by definition Agile principles challenge a team to get on and do: become a cross-functioning, effective team. It works well for projects with uncertainty in the early stages; you work with what you are sure of until you can tackle all of the elements that first appeared unclear.

Agile ensures that the interval between the conception of an idea and its delivery is short, meaning corrections can be made immediately and solutions provided to satisfy the customer.
Agile ensures that the feedback time between an idea and its delivery is short, meaning corrections can be made straight away, and solutions provided.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Agile provides a steady rhythm for everyone to follow which invariably improves the team’s productivity and quality. By providing a framework against which to track progress, the team can build – and, more importantly, work to – predictable, realistic schedules that are more likely to be met.

Agile worked for us because it promotes open, honest communication and emphasises the importance of always gaining feedback, improving potential solutions and working realistically with what you have available. Whilst teams aren’t constrained, and creativity and exploration are always encouraged, this methodology ensures that you always have something to deliver for the customer.

Ultimately, Agile represents a way of working that is realistic and effective, ensuring that teams don’t get lost in a max of complicated solutions, but can take the Sunshine Path to effectively deliver business benefits to the client.

You might also like