Agile Manifesto 20 years

I participated in the amazing global celebration of Agile 20 Reflect Festival’s event “An Agile Manifesto Futurespective” which was both nostalgic and thought-provoking. This means that Agile Manifesto turned 20 years old last weekend! Isn’t that amazing!?

What is Agile Manifesto you may ask. Many of course are very familiar with it but every year new people learn about agile software development and Agile Manifesto is the first thing they learn about.

Agile Manifesto was written in 2001 as a result of a get-together of several advocates for lightweight software development ways of working. They wanted to see what is common to all of their methodologies, and what they believe in. Thus, a manifesto with adjacent agile values was created and put into the internet for all the world to sign (yes, I agree!) and adopt. The manifesto to this day is here http://agilemanifesto.org/ and you can still sign it if and when you agree.

The manifesto reads:

Manifesto for Agile Software Development

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.

It was amazing to participate in the global celebrations for Agile Manifesto 20 years. There were people who had been to the weekend when the manifesto was created. There were people who had lived through the time from when the ideas that would be put under the umbrella of agile were created to the present time when agile is mainstream. There were people newer to the Agile. And as some of the panelists pointed out, every day there are new people who still learn about agile - probably even participating the celebrations.

One of the speakers was Laura M Powers who put it out well. Each of us has their own line of dots that leads to being part of agile, one way or another.

How I got into agile

This inspires me to tell my own line of dots. I first encountered agile in the pre-agile days of late 90s. Extreme Programming (XP) started appearing in many magazines. XP is probably the biggest contributor to agile values, at least from my point of view. Anyway, as I was then, as I’m today, a tester and testing trainer, I immediately noticed the amazing concept of doing unit tests before code. Test Driven Development (TDD) they called it. I adopted the TDD concept as something I would always point out to my software testing classes as something to strive for. See, this is how far you can go. You don’t have to be satisfied with testing as a last step of the development process. However, organizations in Finland that time were very traditional, and this piece of news remained an interesting idea only in my sphere of experience.

Then the Agile Manifesto was published. When I heard that it had been written in the ski resort Snowbird in the USA, my first thought was that hopefully they got the chance to go snowboarding, too, not just spend all the time inside… But seriously, what they came up with was an excellent set of ideas and values that caught attention of really many people globally.

Incorporating agile into software testing

Of course, every country and industry had its own pace in adopting agile ideas. Coming from testing perspective, all these agile ideas seemed more developer country. In addition to that, I was mostly working with finance industry customers’ acceptance testing those early years so agile teams didn’t really fit that world. Neither the customer nor the system integrators would use agile, yet. However, software testing ideas that were born in agile contexts or somewhere similar were also out there, and I was quick in adopting those: exploratory testing, risk-based testing, quick feedback through end user involvement.

Gradually more and more of technical teams started applying Agile and especially Scrum out of all agile methodologies. In Finland this started with more technical product companies first, so you would see it first at Nokia and slowly in others. However, the tide started rising and soon there was a company example in any industry that would be at least piloting agile. I remember a defining moment in some Central European conference when I heard for the first time that even a healthcare sector company had started using agile. I thought that was great! I was talking about this news with enthusiasm any time the talk turned to trends.

Then Janet Gregory and Lisa Crispin published the Agile Testing book. Suddenly we testers had access to that developer domain. That was really a great feeling! Bit by bit people wanted to hear how we should test in agile context. To me it was both strange and a relief. On the other hand, I had always felt that much of the testing is really similar regardless of where you test – test automation, test techniques, heuristics. It was mainly the “when you test” and “by whom” which was different in agile -more of the testing was within development teams. On the other hand, it was good that agile teams now wanted to learn to test – it had seemed that many of the agile teams just didn’t think they need testing. In the Agile 20 years webinar some people even commented that at some point agile was a swear word, meaning software rushed through with too hectic pace. There was unfortunately some of that in the early years of agile. My view was that bringing testing closer to agile helped in getting agile to deliver better quality.

I started adding more agile content to my software testing courses. Then ISTQB also started creating Agile Tester syllabus. I was happily in that team, contributing. Soon after, I co-authored with six other ISTQB people the Agile Testing Foundations book, based on the ISTQB syllabus. Agile testing had taken yet another step.

Teaching and coaching goes agile

Somewhere around these times I had also started teaching and coaching Agile in general, not just the agile testing. I did a Scrum Master certification and a SAFe Agilist certification. All this was a natural progression in software testing coming closer to software developer. In practice our testers often moved into Agile Teams with some reorganization, depending on the customer. Testers would often adopt Scrum Master roles as this sort of overall view was not that far from the overall view to quality that is the natural domain of a tester. Put it another way, from coaching about good quality to coaching about agile is not a big step.

Finally, agile is in the mainstream

Soon, DevOps started emerging into the mainstream. That, to me, seemed to finally accomplish what agile had promised to do but in many cases failed to accomplish: deliver often to customer. All too often Scrum teams would create something that was only put to production much later. It was of course the general challenge of early agile. As someone in the Agile 20 years webinar said, Agile started with developers but later expanded into rest of the company, including management. In order to the agile team to get its products out to the customer with the agility envisioned the agile manifesto, the teams actually needed the rest of the company to come along. I think this happens more easily with DevOps, which builds on agile and lean practices. Management all too often still see agile as only a development team thing. For me, anyway, jumping into DevOps, using DASA approach for coaching and training was the obvious choice to get our customers to truly deliver to their end-users in a more agile fashion.

So, agile is in the mainstream and it is now even almost synonym to good development practices. Still, even though many of the teams are agile, or they say they are agile, there is much to change for whole companies to be agile. And that is needed so that the agile teams can actually be fully agile. Anyway, I’m happy to help in this journey!

The Agile 20 years webinar is available here.