What does Agile really mean?
If you work in software development or project management, the term ''agile'' should not be new for you. However, there're a lot of misconceptions and misinterpretations of this term that I've decided to walk you through what being agile really means in developing software projects. If you're completely new to software projects, but looking for ways how to enter this industry, stay and read on as you will also benefit from this article.
The simplest way to define Agile is to say that it's a way of working. Even though it's a commonly used term in software development (thanks to its origins), it has started to expand into other industries as well. The more expanded definition is that Agile is an iterative approach to project management and software development consisting of a set a practices intended to improve the effectiveness of individuals, teams and organisations towards value delivery to their customers. However, the best way to describe Agile is that it's an umbrella term. Let's take a look at the so-called ''tree of agility'' down below.
Values - at the very bottom of our tree we have roots. Roots stand for values. These are 4 statements that explain what behaviour we value in developing projects. Though they are very high-level, this is the foundation of Agile. These values are included into a well-known Agile manifesto that I'll elaborate on a bit later.
Principles - there are 12 principles that really just provide more details to the values.
Frameworks - now comes the realisation part. Values and principles are realised in agile frameworks, e.g. Scrum, XP, Kanban etc. That's crucial to keep in mind - no frameworks or practices exist on their own. There are always some principles behind each practice.
Practices - the leaves of our tree represent practices. Examples include daily stand-up meeting, definition of done, sprint, product backlog, product increment and many more.
One of the reasons many teams fail with implementing Agile is because they blindly follow the practices. They are not told about what's behind each practice. A small example can be a daily stand-up when instead of being a sync for the team to plan the daily activities and stay focused on iteration goals, it becomes a status meeting when the team just reports to management about the work done that results in the team seeing no value (obviously) in this meeting.
01. Responding to change over following a plan
No matter how long or how hard we work at the start of the project to identify all desired features and plan the project upfront, we cannot succeed. There are always some things that users and developers cannot be expected to think of until they start to see the system takes shape. Iterative and incremental development is about generating feedback, learning from it, and then adapting what we are building and how we are building it. Sprints provide teams the mechanisms for doing this.
02. Working software over full documentation
Traditional approach to managing projects is to plan everything upfront. This approach is usually called Waterfall, when you have discreet project phases. You do all the planning in advance, then all development, after that all testing etc. That requires not only a lot of time, but also a heavyweight documentation. Plenty of time is spent on writing specifications, describing requirements that are constantly changing. Hence planning too much upfront can be considered as wasteful activity. While we still have documentation in Agile, the goal is to have just enough documentation to factor in changing environment and keep focus on delivering working software each iteration.
03. Individuals interactions over processes and tools
Face-to-face conversations should be encouraged and practiced whenever possible. Of course our work environment can seem unrealistic without some processes and tools - but they should not become the end goal. We have to value people and their interactions over processes or tools, because it's people who drive the development process and create products that solve our problems or satisfy our needs.
04. Customer collaboration over contract negotiation
We already know that with big traditionally managed projects you would try to plan everything upfront so you'll need to create a contract outlining all the details of the project. If something goes wrong with your project, i.e. it's behind schedule, you might incur losses and/or start having endless disputes around your agreement with the customer. On the flip side, Agile values customer collaboration over contract negotiation. Engaging your clients into planning process, sprint reviews, constantly exchanging feedback with them and building the product together significantly improve your chances for success.
Agile is a mindset, approach, it's a way of working. Agile principles are embedded into the processes through a number of practices that agile teams follow. All agile frameworks like Scrum are sets of practices that represent specific principles that help teams deliver more value faster and with fewer headaches.
If you like this post, please share it and subscribe to get notified of the next one!
P.S. Looking for additional guidance on Scrum framework as a whole? I’ve created Agile Scrum Master training course for beginners with everything from A to Z needed for you to succeed with Agile.