Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

I am in the airport, finishing up a business trip that took me from Paris to Stockholm and finished in Los Angeles.

Last night I presented at cool Meetup session for the AgileSoCal group (thanks for having me!) where we talked about testing in the context of Agile and DevOps. During the session, I even went as far as to present the Modern Testing principles, and we had a cool discussion about them.

One of the points that came up the end of the presentation was that in many places testers are still doing all the testing, (ergo, developers are not doing any testing at all). And my question to the group was if we should consider these organizations as working under Agile or not?

Who Am I to Define How People Work?!

I am not sure I can comment on this, definitely, I cannot pass judgment, but I can have an opinion, right?

For me, you can say you are working iteratively if you are organizing your testing under relatively short sprints, but this does not make you an Agile team.

Agile, at least in my mind, is when the whole team enrolls in the whole project together. We all do analysis, design, development, and testing. If you are working in a DevOps team, then the whole team will continue to deploy, monitor and sometimes fix the issues found in production.

If you still have "clear" separation of tasks, and, God forbid you dare to mix between the classes, then you are not an Agile team.

My proposal for you is to call your working approach a Mini-Waterfall. I also heard some people call this "Fragile," "Waterfragile," and even "Scrummerfall."

Agile Is a Mindset for The Organization, and Not Only For the Team

Along the same thoughts, many people will agree that it is very hard to define Agile. Each organization can and even should adapt "their Agile approach" based on their constraints, reality, objectives, etc.

With this in mind, it is easier for me to define Agile as a mindset or an approach (or both) more than a methodology.

And in order for the team to be able to correctly work Agile, you need that the whole organization or company agrees and accepts the Agile mindset or approach. Especially the management team.

Why Is This So? Well, It Is Simple.

Most organizations work based on specialized roles. Devs write code, testers break code, POs define what to do, etc. And as I wrote at the beginning of this post, this is not compatible with the way I see Agile.

If I hear a developer saying that he/she does not need to test and that the testers should do it, then Mr. or Mrs. Developer, you are not working Agile. I am not saying you are not doing a good job as a developer, I have not seen your work! But I can say that your working approach is not Agile in nature.

This being the case, and since in most places testers cannot dictate to developers what to do, we will need management to explain to our developer friend that it is part of the work to test software and not only to write it. As long as management will not enforce this small point, it will be close to impossible to make it happen by itself.

There are obviously some exceptions, with teams that align themselves with the Agile mindset without needing a hard stand from the big bosses, but in most cases, this is not the case.

I Wonder How Many Agile Teams Really Work Agile...?

This being the case, I will leave you with an open question for you to think about.