How I Came to Understand Agile and DevOps: A Journey of Discovery [Part 2]

You may recall from the post last week that I was struggling to come up with a good mental image of what Agile and DevOps really “are” and how they differ from one another. I had the graphic that came to me via an Analyze Consulting LinkedIn post which seemed to help at first, but still left me feeling I was missing something important. It felt like I was missing a key piece of the puzzle.

So I showed the picture to Mark Medlin, one of the founders of Paragon and our CTO. Mark has been directing our transformation into an Agile organization for several years and has researched Agile and DevOps in depth.

As we talked, I had an epiphany of sorts and started to realize that I would have to stop thinking about process and people and product as separate quantities, but as three interconnected and complementary parts of the same entity.  It may have taken me longer than most to figure this out, but in my defense, there are literally millions of different references to the concepts posted on the web, with many containing words like “confusion,” “overlap” and even “defy definition.”

In any event, it started to make sense to me:

• The product needs to be designed and built in such a way that it can be managed and manipulated for rapid change, e.g. microservices vs monolithic  

• Agile processes and tools are used to help manage the work done on the product

• The people in the process need to adopt and execute the Agile methodology

And then there is one more thing that needs to get added to the mix: organization.  I think this is where the real difference is between Agile and DevOps:

• In your standard (if there is such a thing) Agile environment, teams of people work within the Agile framework, i.e. designers work with coders, who work with testers, who work with the operations team to deploy software

• In the DevOps scenario; the designers, coders, testers and operations people are all the same team

Again, some of this may have been obvious, but I searched a lot of sites and did not really find anything that looked quite like the picture in my head.  Here is what I came up with:

It was hard to draw something that fits on a single piece of paper and gets the job done properly, so I will have to add a few qualifiers: 

• Overall, the Waterfall approach requires much more time for a release cycle than Agile and DevOps. In the previous post, I talked about 24 – 36 month release cycles for Waterfall. Using 2-week sprints, a typical Agile shop would run through many release cycles in that same amount of time. At Paragon, we run 2-week sprints and deliver a new release of our core products every month.
   

• The Waterfall approach is built around a few major decision points and milestones, e.g. design review and sign-off, code completed, etc. Agile is all about getting started quickly, incremental enhancements, rapid prototyping, testing and validation. Time to value (TtV) is much improved and there are more and frequent opportunities to engage with business users/clients to make sure things are on track or to make mid-course corrections as necessary. At the same time, Agile is all about working on the most important things first.
   

• Your product/software architecture is a critical component in the overall equation.  You want to things to be as modular and atomic as possible, e.g. microservices so that you can actually “deploy” any time that you have a feature/function/change that is deployable.
   

• Organizational constructs are also a very important consideration. Not every company can or will decide to push people into DevOps teams and much has been written about the need for these changes to start at the very top of an organization to be effective and successful.

• There are also product managers, product owners, clients and prospects, i.e. stakeholders, involved on the front end of these processes who define what they want and what the market needs.

There is one key issue here that requires little additional clarification or definition – and that is the need to test. Having a well thought out and executed test plan is a critical part of any successful development methodology. With that said, the legacy tools and processes used in Waterfall will no longer be sufficient to support the pace of change in an Agile or DevOps environment. Automation and integration will be required to achieve success there. This is perhaps the biggest difference between Waterfall and Agile/DevOps, the shift toward a test-driven approach to development, i.e. testing everything all the time.

Where Are You on the Journey?

We recognize, of course, that every organization has their own business strategy, a unique set of resources and circumstances, as well as their own approach to developing products and services. The good news is that no matter where you are on the spectrum from Waterfall to Agile to DevOps, you can still improve your payment testing capabilities.

You need a solution specifically designed to give you maximum flexibility and control of your payments testing environment. You can begin by automating your first sets of regression tests (e.g. Robotic Process Automation). If you already have automated tests, use an API to integrate those with other systems in your development ecosystem – and you’ve begun your journey from Waterfall to Agile to DevOps, eventually progressing to a Continuous Testing scenario in which you automatically test and validate components in your system whenever one of those components change.

We would very much like to talk to you about your unique payment testing requirements and explore how our team and our Web FASTest product can help your organization in your progression to Agile/DevOps.

As far as my journey toward understanding Agile and DevOps goes, I think I have made significant process. Even though my picture may still be a bit fuzzy, I feel much better about the image in my head and about how the pieces fit together. Given the importance of the subject, all the people involved and everything that has been said and written so far, I am sure that this will not be the last word on the subject.