Agile is about a particular mindset – a focus on delivering a minimum increment of tangible work to the customer and getting frequent feedback on it to validate your way of thinking. 

In Agile you will have only two out of three constraints locked; TIME, which will be locked by the duration of a Sprint, and a BUDGET, which is fixed as we exactly know how much it takes to run a Team for a Sprint (an Agile Team is fixed and does not change). The SCOPE however is flexible, so for example if you know that you have to deliver something to a fixed timeline then you are going to negotiate and think – what’s absolutely crucial and must be done and what can slip beyond that timeline and be delivered at a later stage. 

Alternatively, on rare occasions you might have a fixed scope, then the timeline has to be flexible (for example you know it will take you another Sprint or two to deliver a particular increment of work), so you can have only two constraints out of three locked. And QUALITY is embedded in the development and creation process.  So you never jeopardize the QUALITY. 

In traditional Project Management all three constraints; TIME, BUDGET and SCOPE are locked. Unfortunately this leads to the QUALITY being frequently compromised.  

Traditional Project Management is less successful than Agile approach mainly due to the fact that we are currently living in VUCA world (Volatile Uncertain Complex and Ambiguous),which is very dynamic, and characterized by a very high speed of change. For that reason it’s very difficult to accurately plan ahead for the duration of the whole project. According to the study conducted by the Standish Group an average 65 percent of requirements will change during the software development process causing waterfall projects to have an 11 percent worldwide success rate during that period 2011 and 2015. However, the high rate of change requests is not only limited to

software development projects, other types of projects are also affected by the high volume of changes requested. 

That’s one of the reasons why the Project Management Institute advocates for adopting some Agile approaches for successful project delivery.

So let’s dive deeper,  what  Agile is.

Agile is a big umbrella under which you have different tools, frameworks and techniques, which all share the same roots – the value system. Agile mindset is a set of beliefs and principles, and a way of thinking and working together in a particular manner. It’s beyond the mechanics – it’s not about tools or techniques and methodology – Agile is a cultural change. It’s how we work and think to enable innovation and more effective decision making. 

“Agile mindset is about responding to change in uncertain and turbulent environments, and it’s about thinking through how you can

understand what’s going on in the environment, identify what uncertainty you are facing, and figure out how to adapt as you go along”. Agile mindset is about responding to change in a positive manner – seeking an opportunity in every challenge. It’s about accepting the fact you cannot foresee everything in the future, and you need to make decisions without the full information available and then pivot if needed. It’s about taking action in little steps and adapting – validating if your way of thinking works and build on it or change the direction. 

Agile techniques have been in practice since the 80s, however officially Agile was formalized in early 2000s with the creation of the Agile Manifesto for Software Development, which is built around four values. 

If you remove the terminology relevant to software development, it can be widely applied to any other department, sector or industry. 

• Individuals and interactions over processes and tools

Value: human-centricity / respect to People

We will change the process and procedures if we get feedback from the staff that the current ways of working could be improved and we won’t be forcing people just to follow the process for the sake of following it, especially when the feedback received about that process is less than satisfactory. 

• Working software over comprehensive documentation

Value: delivered work provides an opportunity to gather feedback and validate the idea

We do need documentation, but we only document to the level of useful and helpful. In the traditional approach, frequently the  documentation is very lengthy and everything is documented for the sake of being documented. Significant effort goes into creation of that documentations, but nearly nobody reads it, as it’s too heavy and time consuming. In an Agile environment, documentation is a placeholder for a conversation. It doesn’t replace the in person interactions. 

• Customer collaboration over contract negotiation

Value: collaboration / transparency

A quite common misunderstanding is that we do not need contracts. That’s a myth. Of course, we have contracts in place,  but then we are open to conversation with the customers regarding how the product/service is shaping and potential changes. 

We are open-minded, and if the customer wants to change or pivot we make that process as easy as possible. The change doesn’t come for free, but through the partnership we will establish the best way

to go forward; possibly to de-scope something else and deliver the changes instead, or to develop the changes at the additional cost. The most important part here is to develop a strong relationship with the customer and engage them in the development and creation process. 

• Responding to change over following a plan

Value: adaptability / positively responding to change, unknown or unpredicted

The last value is about adaptability and responding to change over following a plan.

Additionally, we also have 12 agile principles, which guides us further. 

The aim is to satisfy the customers through early and continuous delivery of valuable work. Changing requirements are welcome throughout the duration of the project. Agile processes harness change for the customer’s competitive advantage. The tangible work is delivered frequently and incrementally. Daily collaboration throughout the project duration is highly recommended. The projects are built around motivated individuals. Organizations give the staff the environment where they can thrive and support them, and trust that they will get the job done. Delivered work is the primary measure of progress. Agile processes promote sustainable work pace. All involved in the project should be able to maintain a constant pace indefinitely, to avoid a risk of burning out. Quality is embedded into a creation process – continuous attention to technical excellence and good design enhances agility. Simplicity–the art of maximizing the amount of work not done–is essential. Self-organization of the teams is crucial in obtaining the best possible outcome. And finally, the focus is on the continuous improvement and learning – at regular intervals, the team reflects on how to become more effective, then

tunes and adjusts its behavior accordingly. Reflection is a key element, because one cannot improve without allocating time to inspect if the working practices are the most efficient or could be (further) improved. 

 There is also one more principle stating that in person (face-to-face) communication is the most efficient way of communicating. However,  recently this point is being challenged and more and more organizations are experimenting with asynchronous ways of communicating, which supports the concept of remote work. 

So what are the benefits of following Agile values and principles?

Having a strong market position today does not mean a company will have it tomorrow and that’s why there is a need to adapt to changing circumstances, or market demands, challenge the status quo  and experiment with different approaches, solutions or products. 

Scrum is the most commonly used Agile framework. Around 80 percent of organizations use Scrum. 

So what is Scrum?

Scrum is a lightweight framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value.

Scrum operates in Sprints – a time box period, which gives some benchmark to monitor the performance and gather a consistent feedback on tangible* work increment. 

Each sprint starts with the Sprint Planning, to plan the Sprint ahead – to create a valuable increment of work. Every day the Team will meet for 15mins during the Daily Scrum to align and assess the collective progress towards the Sprint Goal (established during the Sprint Planning). Then at the end of the Sprint there is a Sprint Review, involving stakeholders and customers, during which we show a completely finished increment of work and seek feedback on it.  And the last Scrum event is a Sprint Retrospective, during which the Team assesses what went well during the last sprint and what can be improved in the future, as well as looks at various impediments they encountered during that Sprint.