New methodologies continue being created to improve software production, while benefits increase and deficits decrease. However, methodologies always fall down at the human element. As one looks at the more recent agile flavors, the weaknesses tend to be based on human failings: What if the requirements are poorly determined? What if people are incompetent leaders or lacking in social or technical skills? What if the inter-team meeting is poorly run? If a Waterfall model approach used people who rapidly move through their phases, requiring no backtracking with successful results in a single cycle, would this be more successful than an advanced Agile method using poorly-skilled people and bad leadership?
I say this to make a point, not to suggest a return to weaker methodologies. It is unfair to compare the best of the worst to the worst of the best – it is only fair to acknowledge that older methodologies are less dependent on more advanced skills, in much the same way that automated testing performed by manual-only testers will suffer failure. But then again, engaging people for a job they are unprepared for would be an HR mistake. We cannot fault a methodology for assuming that testers can test, developers can code and operations can maintain. To properly understand, we must walk through different methodologies to see how we got to DevOps so that we can predict future improvements based on the path we have taken. The point I want to make is that methodology expectations should match the design.
The granddaddy of all methodologies and the most simplistic, is the Waterfall model, illustrated by my horrible photo editing. This takes a sequential, non-iterative approach of walking through every stage of creating software. It is easy to implement, easy to manage, uses minimum resources, and has high visibility – sounds good, yes? On the down side, it is expensive, time-consuming, high-risk, non-realistic, ignores “what if there’s a problem requiring us to backtrack?”, and produces software very late in the game, which may not even be very usable and could be too late to market to compete. Yes, it is possible to luck out with a rapid attempt, but the odds are very much against you – the design is bad. QA is a bump in the road (buried in Verification), having no role regarding requirements or design, and no process for addressing any bugs uncovered except to proceed to release.
Next, let’s proceed to the Rapid Application Development (RAD) methodology and see how things have progressed (you thought I was jumping to agile next – jump a paragraph to that if you must). RAD allows backtracking. RAD lets you go back to the user and say, “Can we tweak the design and I’ll just go ahead and do it”. RAD adds flexibility. Quality, risk, timeliness and cost (the last 2 contributing to the all-import ROI) are much easier to control. Yes, it is tougher to manage and has less visibility than Waterfall but the risk, timeliness, and cost are all reduced. It is not suited for very large projects, requires more expertise from everyone, and the social component means more meetings that require inter-departmental availability (not necessarily a bad thing).
Now let’s look at agile. Back in 2001, agile was defined by the Agile Manifesto. Agile is a mindset, while Scrum and Kanban are methods of achieving that mindset. Scrum and Kanban certainly saw that improvements could be made to agile, perhaps without losing the agile identity. But I digress – agile is a big tent, and the Internet is full of people arguing over whether agile means the original 2001 Manifesto, newer variants, or the whole collection. Defining “agile” means offending some people. Some may argue that agile is more of a movement away from the highly structured and less adaptive, where the behavior is so different it is hard to consider pre-agile and post-agile as both being methodologies. In these more enlightened times, we say little-a “agile” instead of big-A “Agile” to indicate acknowledgment of the newer side of the agile spectrum. And Lean is like agile with a Six Sigma manufacturing attitude.
So, back to agile with a little history; 17 developers got together at the Snowbird resort in Utah in 2001 and came up with the Agile Manifesto. One of the things it sets in stone that it is bad to set things in stone. Like RAD, they began with some lightweight flexible concerns, and proclaimed the following anti-Waterfall primary ideas:
These are backed by the following 12 principles:
Combining these lets you evolve agile itself, potentially allowing yourself to create new rules that can get you to Scrum or Kanban or even DevOps. The Agile Manifesto is a common ancestor of later variants/offshoots/descendants/progressions; and as RAD is more advanced than Waterfall, agile is more advanced than RAD. But there are some basic rules or principles that have been put in place, and I’ve rambled on ad nauseam without hitting the “benefits vs. deficits” part yet. Teamwork, collaboration and adaptability beget cross-functionality, lower risk, higher quality and multiple iterative attack. Communication is integral, so problems/surprises cannot fester in secret (I say this having once been on a non-QualiTest, non-agile project where several months in we suddenly saw we were behind by more than the length of the project).
Sounds great, doesn’t it? So, what’s problematic with agile? The lack of documentation can lead to lack of design (agile’s flip-side is that too much time can still be lost to prepping and planning). You need a structure outside of agile to manage large projects (which is doable). In Scrum, the Scrum Master must not take on too many tasks or risk losing control as a facilitator. Technical debt of non-functional testing may accumulate. The project may fail if people are partly or fully pulled from the project. Nothing prevents siloing of roles.
DevOps, based on agile ideologies, has advances over agile, but first we must admit that there is dispute over calling DevOps a methodology. It is a set of processes, but the real focus is on this being a cultural shift (whereas agile was a mindset shift). DevOps has organizational changes defined to follow through on some of agile’s ambitions. DevOps is a union of Development, Operations and QA (highly cross-functional), obliterating siloed roles, and causing everyone to empower each other as needed (and there’s a lot of need). Communication and collaboration are a focused improvement area over agile, leading to faster feedback of issues and increased throughput from idea to production.
QA automates testing (functional and non-functional), so that there is immediate feedback on builds. QA automates metric delivery so that Operations is always in the loop. Everyone talks in a behavior-driven manner, so that even non-technical people can talk about details of the work. Continuous Improvement, Continuous Integration (tested code), Continuous Delivery (deployable code) and Continuous Deployment (deployed code) are all components. Processes are highly automated, rewarding you with high stability, greater accountability, managed and consistent environments and few production issues.
DevOps is the new normal, where other methodologies cannot keep up. Well, that sounds great with everybody working together and helping each other, and communicating well and streamlining whatever they can. So, before we picture everyone holding hands and singing, what’s the downside? It can be hard to find people trained in all the cross-functional skills that DevOps requires, and like agile, it helps if you begin with experience; and there are expenses to the buy-in with all the automated tools/environments needed.
Let’s talk about those automation tools that enable continuous everything through automated everything. The stages (yes, we still have stages despite being far past Waterfall) software development, software check-in, automated builds, automated testing, automated deployment (to actual, virtual and/or mobile environments), and monitoring and operations. Tools, therefore, should cover infrastructure (AWS, OpenStack, etc.), server monitoring (Ruxit, Nagios, New Relic, Zabbix, etc.), Platform Virtualization (VMWare, Vagrant, etc.), log analysis (ELK, Logz.io, etc.), service discovery (Consul.io), collaboration (Atlassian, et.c), test and build (Jenkins, Bamboo, Gradle, etc.), Deployment (Automic, Capistrano, Commando.io, etc.), containerization (LXC, Docker, etc.), configuration management (Chef, Puppet) and security (Tripwire, Veracode, etc.). It is essential that DevOps uses established automation tools, instead of writing ad-hoc management utilities that could introduce procedural stumbling blocks.
So, if this is as good as it gets, what comes next? Some have argued that security comes next. While security falls under the title “non-functional testing”, it may not necessarily be part of the non-functional testing in DevOps. Unsurprisingly, vendors of security testing software are the first to point this out, especially at conference seminars before pointing you towards their booth. However, it is a valid point – baking security into how Developers think and how QA tests makes for a better product with a better ROI through a shift-left approach. Security tools are starting to integrate in to the Continuous Integration/Continuous Delivery process to ensure that all built code is secure as well as functional.
People with a mobile background look back to RAD and realize that user experience could benefit from having a baked-in shift-left influence as well. On the Ops side, social media input can be scanned, where a stakeholder can use A.I. techniques to scan for popular words or seek similarities in the worst reviews. On the QA/Dev side, managed crowd testing can periodically supplement the automatic testing results. After all, the best way ensure that your users are happy is to ask them. Somehow this Usability component that ensured value to the user disappeared in the advancement of RAD to agile, bringing this back in to the fold can help improve the quality of the delivered product.
Others believe that all the managed services, the ones that make all of the Continuous whatever happen, will cause people to focus less on the other gains of DevOps, if we could only remember what they are. Let me remind you of those gains: there’s the improved communication at a human level, QA’s role empowering the DevOps team, and lots of cross-function. What about people objecting to the ROI of all the automated tools for setting up a DevOps shop? I imagine that cloud and tool prices will drop, weakening those arguments as well.
A part of me wonders if a hybrid will be next, incorporating anti-agile structures that are so sensible (possibly as developed managed services) that they can be added back into the overall process. Maybe there is a way to improve the communication that permits a drop in cross-function, allowing a lower mixed skills threshold for success, or a technology solution that simplifies the skills needed. Or perhaps there is a paradigm shift so severe that we cannot yet perceive it, that will break all the rules yet again. I’m not sure what will come next, but I’m sure we’ll look back and say that it was a good thing, and wonder how we lived with whatever deficits we currently experience.
Some level of control will again leverage some human failing, as DevOps has done with cultural mindset. RAD broke out of slow forced waterfall stages. Agile was more principle-focused. DevOps had a cultural shift and cross-function. The real goal here involves an environment that encourages people can be most effective (… at creating great software) rather than the creation of great software itself.
