Software Engineering
20 Years of the Agile Manifesto
Reflections on two decades of Agility practice
On February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground — and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.
February 2021 is the 20th anniversary of the Manifesto for Agile Software Development — a revolution in the software market and an influence across many industries.
Even if the manifesto has not changed, the application of its understanding varies from place to place. I’ve been working with Agile software development for more than a decade. During this period, as a freelance engineer I have witnessed over ten companies using agility —all implementing it differently.
I have seen:
- Teams that dropped out estimation because they did not see a concrete benefit from it.
- A scrum master who did not allow any story to be added to a sprint if it was not ready and missing some details according to at least one developer. By applying this constraint, the team ended spending about 30% of its time discussing clarity, readiness, and estimating stories. The experience was stressful for the product owner who was accused of not doing his job properly and preparing poorly-described stories.
- A developer was accused of being against scrum because they have improved the UI and cleaned code, which wasn’t required in the stories planned for that sprint.
- People interpreting agility as a room for creativity and a method where you can show your new ideas and challenge the existing state.
- A scrum team with about 13 members: UX designer, testers, devOps, backend, frontend, iOS, and Android developers. All the developers in that team were taking part in estimation meetings for every story. Then, to enhance to implementation of agility and reduce the gap between roles, the team started applying pair-programming. Each developer had to pair-program with each one of his teammates — an iOS-developer with Java-developer, a JavaScript-developer with an Android developer, an Android developer with an iOS developer, etc.
The daily standup was the only practice I’ve seen used by all my Agile or scrum teams.
In this post, we’ll have a look at the concept of agility, how the practice has changed over time, and where it’s headed in a changing world.
What is Agile all About?
The team of Taiga has distilled two principles from almost 15 years of Agile experience. The first principle is:
Teams exist as an expression of collective solidarity and alignment
“… A team such as we state in this principle can cope with ups and down and understand the reasons behind every decision that takes place. Less cognitive dissonance, more empathy, and a more sustainable process altogether can flourish here.”
According to internal research at Google, psychological safety was the most critical factor in team success. While the world focuses on Agile tips and tricks, the central message of “Individuals and interactions over processes and tools” is still challenging to get right.
We need to “build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” as the fifth principle behind the Agile Manifesto insists.
The second Agile principle for Taiga’s team is this:
Waste is tolerable, what it isn’t tolerable is not tracking it
“Agile has been often considered as an exceptionally good waste reducer. Waste comes in all shapes and colors. Finished work that wasn’t needed, meetings without the relevant stakeholders, no proper prioritisation, early optimisation, technical debt (in software development), low bus factor… The more waste, the less predictability.
As long as the team is aware of the sources of such waste and has some way of accepting it under certain circumstances, the pressure can be lifted up a bit and allow some extra degrees of freedom, which might ironically lead to less overall waste.”
The Change in the Agile Practice
In a changing world, expectations of what software should do have grown and single programmers have been replaced by teams. This added communication and coordination complexity, which made sticking to traditional methodologies of software engineering a poor option.
In her post “20 Jahre Agiles Manifest — definitiv den Kinderschuhen entwachsen,” business coach and change manager Jutta Eckstein provides a list of changes in agility. Here is an extract:
- There is no longer any added value seen in estimating. If teams make sure that stories are always about the same size, it becomes unnecessary to estimate every single story.
- For a long time, stories were only recognized or accepted as such if they corresponded to the Connextra format (“As a … I want …, so …”). Rather, one is now referring again to the fact that stories only serve as a kind of memo for a conversation about the content of the story (and there is no format for conversation notes).
- Flow is becoming increasingly important. This includes the fact that the sprints or iterations often no longer play an important role. This means that teams do not plan more every two weeks, but rather coordinate daily in Kanban mode what can be completed and what is then added from the backlog. That means that planning is more likely to be continuous, and the retrospectives are often also a continuous reflection and correction.
- Particularly during the climax of the Black Lives Matter demonstrations, calls were made to rename the Scrum Master role (since the term “master” historically served to differentiate it from the slave). However, the Scrum community has passed the suggestion. (In contrast to GitHub, where the Master was renamed Main in the course of the discussion.)
- With the increase of development speed, new movements like DevOps have contributed to creating a better way to look at software development in a broader context. However, the underlying idea of DevOps is not always understood. More and more companies are placing a DevOps team next to the development team or occupying the role of a DevOps engineer. They overlook the fact that DevOps is an attitude, a culture, and not a function, role, or special task.
Jutta Eckstein adds that few of the “lightweight” methods that were the basis of the manifesto still play a role today. These include, for example, the crystal methods or adaptive software development. Extreme Programming (XP) has experienced an upswing in recent years, among other things, because Kent Beck has reported back to the community after he had not appeared for many years for personal reasons.
It’s also worth noticing that there was a short-sight in the third Agile Manifesto principle which limits the frequency of software delivery to “a couple of weeks” but DevOps and continuous delivery cycles nowadays allow us multiple software releases in a single day. Uncle Bob’s answer to this point is as follows:
“At the time in 2001, we couldn’t imagine doing anything faster than a couple of weeks. Tom Gilb was the one person in the community who could, but he wasn’t present at the meeting. We thought two weeks was the lower limit, and no one bothered to challenge it, and that was clearly shortsighted.”
Where is Agile Going?
Agility is no longer understood only in the context of software development, even if the manifest clearly had that exact focus. We have seen “Scaling Agile” as a response based on the belief that the entire organization needs to operate on Agile principles. Business agility is now a topic experiencing more and more momentum.
To apply the Agile philosophy to traditional corporate processes, Bjarte Bogsnes highlighted a major challenge in his post “Agile Transformation and the Elephant in the Room”:
“it is hard to scale Agile using the same framework and the same language that worked so well for transforming software development. “Scrum” might sound like a skin disease for executives unfamiliar with rugby. A “Sprint” is not about running faster. “Slack” is not about laziness. “Continuous delivery” is not about efficient assembly lines.
We need a translation, something that helps executive teams better understand what Agile means at a corporate level. What does Business Agility really mean in practice?”
“The elephant in the room” according to Bogsnes is the old management process: budgeting. Because it was seen as a law of business, unavoidable and untouchable, and at the same time if it’s not changed, any Agile transformation will struggle.
“We are talking about the budget, probably the most fundamental barrier there is to an Agile transformation. Not just the annual budget and the budgeting process itself, but just as much the mindset behind it. Both are in so many ways the antithesis of Agile. Budgeting is built on two fundamental assumptions: the future is predictable, and that people can’t be trusted. It doesn’t get more un-Agile.” Bogsnes wrote.
Many organizations across the world have solved this problem and added business agility to their processes by following the 12 Beyond Budgeting principles according to Bjarte Bogsnes. Instead of being used in its narrow sense of planning and control, “budgeting” could be a leadership culture and a performance management system.
Final Thought
Although various other manifestos have emerged in recent years — such as Agile Marketing Manifesto, Agile HR Manifesto, Agile 2, Heart of Agile, and Modern Agile — these alternatives do not replace the original manifesto.
Developments like Working out Loud and New Work that focuses on one aspect of agility, also show that the Agile idea is still current despite the 20 years since the manifesto was written.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
🧠💡 I write about engineering, technology, and leadership for a community of smart, curious people. Join my free email newsletter for exclusive access or sign up for Medium here.