Table of contents
An overview of where this project management approach came from and what it means today
Agile is a set of values and principles that were written to make software development projects more efficient. Contrary to popular belief Agile is not just Scrum or Kanban explicitly, it is not a certain set of rules and furthermore, it is not a methodology. When asking what Agile is, we focus on the 4 values and 12 principles defined in the Agile manifesto as a guide to more adaptive and responsive project management.
Today Agile is more of an umbrella term that holds various project management frameworks underneath it.
As long as the framework fits the core values and principles it can be called Agile, thus this list is not definite and still growing. Keep in mind though, that while all of such frameworks are Agile none of them represent the Agile concept explicitly. Agile is not about practices or tools, it is a mindset that helps reach a more adaptive way of organizing projects.
To better understand Agile, you should know what project management looked like before it. In fact, the traditional project management approach of running all projects in phases is still widely used today. In case you are not familiar, here is how it works.
At the start of a project, management sits down, divides the work into particular stages like Requirements – Design – Implementation – Verification – Delivery, plans out the work, and then executes the project one stage at a time. This approach allows getting a good grasp of everything that will be happening during the project at the very beginning of it and plan accordingly to ensure the team delivers the required results. It was first introduced as a way of running software projects in 1956 and is now known as the traditional or Waterfall model.
Waterfall works great for static environments and was a big improvement to the previous project management approaches. However, as the market became incrementally faster and more difficult to predict, planning large projects in advance sometimes meant what the teams designed a few months back was no longer relevant and needed to be changed. Software development teams were amongst the first ones to notice this flaw in the Waterfall approach. As technology innovation gained speed, planning out the whole project at the start meant they could be delivering an irrelevant product by the end of it and if changes were made, deadlines would never be met.
It was as early as the 1970s when these teams started looking for lighter and less micro-managed approaches that could work. In fact, many of the frameworks we now know as Agile started forming before Agile was even a term. Rapid application development (RAD), Unified Process (UP), Dynamic systems development method (DSDM), Scrum, Extreme programming (XP), and others were first introduced in the ’90s. All talking about creating a more feature-driven process that can adapt to changes even late in the process.
More on Agile vs Waterfall.
With all the buzz going on and new methods being created, it was only a matter of time before a new philosophy was born. And it did in 2001 when 17 developers met to discuss the need for change and ways of introducing it. What came out of this meeting in Utah was the Agile Manifesto stating 4 values and 12 principles to help guide and ease the process of software development. The term Agile was chosen as it perfectly fits the adaptive and result-oriented mindset the values were describing.
When we talk about Agile it is these 4 values and 12 principles listed in the Manifesto we should have in mind. The 4 values read:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
It is important to note, that the writers stated there is value on both sides of these statements. However, the values on the left should take priority.
To help teams implement these core values and understand the benefits of Agile, the creators also came up with the Agile Manifesto 12 principles:
1 – Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
2 – Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3 – Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4 – Business people and developers must work together daily throughout the project.
5 – Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6 – The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7 – Working software is the primary measure of progress.
8 – Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9 – Continuous attention to technical excellence and good design enhances agility.
10 – Simplicity–the art of maximizing the amount of work not done–is essential.
11 – The best architectures, requirements, and designs emerge from self-organizing teams.
12 – At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
When reading through these values and principles and comparing them to Waterfall we can immediately spot the differences. While Waterfall aims to control the process and plan ahead, Agile is all about creating a way to adapt. To better understand the Agile approach to project management, we can summarize these statements into these 4 ideas.
Little can be done in a company where communication is lacking and Agile really gets that. To get teams, management, and customers talking, the practice asks for face-to-face communication and client involvement in the process. Different approaches use different techniques for this, but generally, teams meet to discuss progress daily and either has a dedicated customer representative within a team or schedule regular meetings with the customer to gather feedback on the progress.
Delivering a functional product to the client takes precedent over planning or documentation in the Agile manifesto. This means the team prioritizes customer requests and changes over the plan. To accommodate such an approach, Agile teams work in iterations instead of building the whole project from a to z. In most frameworks, the team looks over customer requirements before each new iteration, picks the most important ones, and uses the next iteration to deliver them to the customer. This way making sure, the customer has a working product with the most important features after each iteration and can express their comments on what needs to be improved.
To make the process efficient, deliver a relevant product, and have the right team for the job, Agile approaches promote evolution in every step. The teams are asked to review their process after each iteration and make improvements for the next one. Client feedback and requirements are reviewed and taken into account after each product increment to make sure the team works on what is needed. Lastly, project teams are reviewed and formed for each new project or even project phase to ensure they are cross-functional and self-sufficient.
All of this allows teams to create an Agile environment that can take on changes at any stage of the project. In fact, changes are not only accepted, they are welcomed as a way to improve and provide a better solution to the customer. The Agile manifesto looks for improvement and quality in all processes, thus taking in the newest technology and delivering the best possible product is one of its key goals. Which turns out to be one of the main benefits of Agile development.
The Agile Manifesto was a breath of fresh air for the software development community, however, it did not describe an actual way of working. Thus, various Agile methodology variations soon followed aiming to fulfill the values and principles described. Some frameworks like Scrum were already introduced to the software development community, while many others came after. Even today the number of frameworks keeps growing and expanding the Agile term with new regular and scaled approaches.
Agile frameworks are an important part of Agile as they give teams specific tools to implement the practice. In fact, the more described ones like Scrum can even act as a guide into Agile for first-time practitioners. It is most likely due to the descriptive nature and clear processes of Scrum that it has retained the number 1 position as the most popular Agile framework for several years now. However, you should be careful not to confuse Agile and Scrum and make sure instilling the Agile mindset is still your number one priority.
Agile frameworks differ in their processes, tools, and application, but they are all focused on iterative, feature-driven, and evolutionary processes. And with such a variety to choose from, each team can find something that works for them.
Find out more about which Agile framework is right for you in this comparison of Kanban vs Scrum vs Scrumban.
Since its beginning in 2001, Agile has come a long way. However, it was clear from the beginning that Agile in IT is just one application and that the Agile Manifesto is much more versatile. It has been successfully adopted by engineering, sales, marketing, design, accounting, government, and many other teams. Thus, proving iterative processes and responding to change have become important aspect valued in various industries.
While software developers were the first ones that felt an impact of a fast-moving market and changing requirements, by now this is relevant to everyone. There is a need to respond to new technology, trends, and market changes, and Agile was built specifically for this. Thus, there is no surprise more and more industries are instilling Agile pm values and reforming their processes to fit the new ways.
One of the latest developments in the Agile evolution is the growing need for scaling Agile that describes how to make the whole company operate in an Agile way. As Agile popularity grows, companies are looking for a way to transform their whole process instead of only focusing on small isolated teams and this requires a whole new application and tools. One of the most popular scaled Agile frameworks today is SAFe, outlining an Agile process for several layers of management and explaining what is Agile on an enterprise level.
Another recent development in Agile is the introduction of new metrics. A variation of lead time, actionable Agile metrics offer teams a new look into their projects and how to reach the best results. Compared to others, actionable metrics not only evaluate the current situation but also provide insights on which tasks should be completed next. Thus, giving teams an action plan to follow out of tough situations.
To help you implement Agile values and principles, we at Teamhood are focused on creating a tool that eases collaboration, visualizes the process, and allows you to optimize and deliver the best results. With the help of our workspace templates you can quickly create a Scrum or Kanban board to track your tasks or pick an industry-specific template and track your process in an Agile board catered to your projects.
The Teamhood task board is visual and easy to modify with custom columns, rows, and secondary processes to track subtasks. Use automation to move tasks between boards and ensure you deliver the optimal end result to your clients. Enjoy real Agile processes with Teamhood.
Sign up for free, no credit card required.