Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
In a recent post on InformationWeek, Erik Weber, a professional Scrum trainer and Agile expert, explores four signs that you’re doing Agile development wrong. Upon finishing the article, I was reminded that Agile in theory is often very different from Agile in practice, and when that gap exists within IT, it can have massive consequences on both development operations and the business.
At the risk of stealing some of Mr. Weber’s thunder, I’m going to spoil the first two signs he discusses – namely, “failure to ‘get done’” and “failure to launch” – because I believe they are common challenges for many IT groups. The good news is, organizations can close their gaps and realize the true value of Agile development by incorporating DevOps processes and tools into their systems development life cycle (SDLC).
Getting to “Done” Faster
“If it takes you longer than a few weeks to turn an idea into a production-ready feature, you are not Agile – full stop,” says Weber, and I would agree. The whole point of Agile was to move away from the slow, monolithic development methodologies of the past by breaking the process into smaller chunks and having developers, testers and business development people working concurrently to speed new features to market. Most Agile practitioners would say they’re doing just that, but many are still not “getting to done” as fast as they would like. Why is that?
According to Weber, the biggest problem is that many IT groups leverage Agile techniques for development, but then do all of the testing at the end. Obviously, this creates numerous problems that can delay project completion. As we all know, the later bugs and glitches appear in the SDLC, the longer it takes to fix them. When that happens, costs go up, delivery pushes out and customers are unhappy.
The DevOps principle to employ here is getting the operations team involved in testing earlier in the SDLC – essentially shifting their work left – and the tool that can help is service virtualization. By simulating constrained or unavailable systems across the SDLC, service virtualization enables developers, testers and performance teams to work in parallel for faster delivery and higher application quality and reliability. With DevOps, they can realize truly parallel Agile development without constraints – and ultimately get to “done” faster.
From “Failure to Launch” to Continuous Delivery
“If you haven’t actually released your software to production – and on to customers – for three or more months, you are missing the big picture,” argues Weber. He believes that many product managers and executives hold back official product releases because they “must have all the features,” and when this happens, they forfeit the ability to both get new features into customers’ hands on a regular basis and react more nimbly to their wants and needs.
There are numerous reasons why the “all features” mindset persists, but a good way to prove its obsolescence is by incorporating the DevOps principle of continuous delivery into the development process. Continuous delivery means always being in a ready state for pushing applications and services through the SDLC and into customers’ hands – and release automation is the tool that helps organizations reach that state.
Release automation enables continuous delivery by automating complex, multi-tier release deployments through orchestration and promotion of applications from development through production. As a result, visibility improves across an organization’s deployment chain, giving it the flexibility and agility to continually release new features to market and react quickly to changing market demands. Once an IT organization reaches a state of continuous delivery, it becomes easier for executives and product managers to pull the trigger on a given release – because they know that the next one isn’t far behind.
Agile is as Agile Does
Weber offers four signs of ineffective Agile development in his article, but I would argue that there is a unified idea running through them all: It’s not enough to employ Agile practices; you have to follow through until you meet your Agile goals. Ask yourself, “Are we really delivering releases to market faster, at a higher quality and at lower cost to the business?” If the answer is “no,” the right DevOps methodologies and tools might be just what you need to put these failures behind you and finally realize the true value of Agile development.
