The Agile Mindset

First, what is Agile?

Plainly, agile means swift, adaptive and flexible. In the world of software development, it is in fact a ‘way of management’ or a specific mindset that emphasises outcome over process, and people over tasks.

It all began in 2001 in Snowbird, Utah, where several people met to discuss the future of software development. This came from a deep-seated frustration of having to do excessive documentation of their software development cycles, preventing them from focusing on what truly mattered. This brought about a whole new type of mindset to attain optimal efficiency within a team, be it of time, cost, or whatever the goal is. Agile does not tell you what to do but simply prescribes the ideal state. Hence, you cannot simply ‘apply’ Agile.

You may, however, apply various tools to help you 'implement' this mindset. KanBan, Scrum and Lean are some frameworks you can wield to achieve the ideal state of Agile.

Understanding Agile is not rocket science

To understand Agile, it’s worth examining the tools used to achieve this mindset.

For instance, take Lean, where its core purpose is to create value with fewer resources and less waste. From a business standpoint, the main goal is to create more value to the customers without incurring more cost to the business. This comes with continuous experimentation to optimise.

The most popular framework is Scrum which is often compared side by side to the traditional Waterfall framework. Both are product delivery process that aim to take a particular product or feature from its inception to the market. However, they have marked differences in the way they approach tasks leading to specific goals.

Big goals are broken into milestones, with good reasons

Imagine you have to build a house from the ground up and in doing so, you want to be agile and as efficient as possible, while sticking to your budget and timelines. Assuming you have 1 year to build your house. Instead of running the long marathon in a single attempt i.e. Waterfall, you can break that goal down into several sprints where you would achieve one milestone at a time, until the goal is achieved.

You may choose to break the goal up into several modules encompassing e.g. the bedroom, the living room, the bathroom etc. The idea is to build them independently and piece them together thereafter.

Now, there are several advantages with this approach:

• You do not have to wait long to finally see something tangible.
• You minimise the risk of failure. Imagine taking this project on using the waterfall approach. If the base structure fails, everything else falls with it.
• You can deal with uncertainties better. With Agile, you can be adaptable to change by taking the affected component out, fixing it and integrating it back into the main frame.

So how far should you be breaking things apart?

Sprint lengths can vary from one task to another. We are talking about 1 week or even a month depending on the duration of the project. There are no hard and fast rules when it comes to planning your sprints, it is only a framework after all.

While every project has a duration, there are no set project timelines when it comes to implementing things the Agile way. What is known as ‘go-live’ in the Waterfall context is incrementally achieved with sprints where the business team sets the direction and the technical team performs iterations on a feature to produce functional minimum viable products (MVP). The business team may then choose to launch these MVPs, test them out as early as possible and reiterate based on customers’ feedback - without having the final product yet.

Learn how SCRUM adopts the Agile mindset

These are the aspects that SCRUM emphasises on:

1. Backlog -

A session where the product owner describes her vision and the team prioritises the backlog of products or features to be built.

• Takes place at least once a week or even daily.
• Can be recurring or as and when needed.
• To be broken down as detailed as possible covering all possible scenarios, and even build user stories.

2. Sprint planning -

A session to discuss the backlog as a team, and how much of this can be delivered in the next sprint.

• Takes place before the start of every sprint.
• Focus on the goal more than the tasks. You’d be surprised how creative you can get in finding alternative ways to achieve a goal.

3. Task selection -

With Agile, work is taken, not given.

• People choose their tasks because they are seen as the most competent person in the team to undertake the task in the most efficient way.

4. Daily stand up -

A session to update and highlight issues that matter to the team.

• Encouraged to be quick and succinct (hence standing).
• Everyone in the team should be present.

5. Sprint showcase -

A session to bring the team and stakeholders together to demonstrate the work of the team after every sprint.

• Also known as iteration review.
• A time to celebrate accomplishments and gather immediate feedback.

6. Sprint retro -

A session to review a sprint as a team at the end of an iteration.

• What we should continue doing.
• What we should stop.
• What we should introduce.

To start, you just have to adopt the mindset as a team

Fortunately or unfortunately, there is no training to be Agile per se. You just have to adopt the mindset and roll-out any Agile framework of your choosing. The key success factor is trust among team members. Once you have achieved this, technically, there is no need for a team manager as the team is largely self-managed. Instead, you need Scrum masters who act as advocates in propagating the Agile mindset across the organisation.

Ideally, these individuals should already embody this mindset and be familiar with its rituals and ceremonies. They are the change agents who guide the team on what needs to be done based on the framework. For instance, a Scrum master may quickly identify the need to realign the team based on the outcome of a sprint, and proactively call for a sprint retro. In essence, their job is to plan and find ways to optimise the way people work.

Accountability is also a key principle of Agile, and this is placed on the product owner who owns the successes (and risks) associated with the product. Needless to say, they are in the position to make product decisions and should have the final say.

Final thoughts

Contrary to popular belief, Agile is not the answer to everything. As easy as it sounds, Agile is often misunderstood and 'force fed' top-down in many organisations as it is touted to be the answer to all product management problems. This is largely untrue as Waterfall proves to be a more superior framework than Agile when it comes to building essential products that are less tolerant to mistakes, and require more intricate planning and coordination between teams.

Agile works best when you do not have all the answers to valid concerns, and where the only way to move forward is to test different possibilities and learn in a managed environment. You should also be comfortable working with an open timeline as with Agile, there is no ‘end date’ - every sprint is an iteration of a product or feature version. Knowing when and when not to adopt Agile is equally as important as knowing how to implement it effectively within an organisation.