What is Agile?
The term “agile software development” emerged from a gathering of industry thought-leaders in Snowbird, UT in 2001. The term was first used in this manner and published in the now famous (or infamous) Agile Manifesto. It was used as an umbrella reference to a family of emerging lightweight software development methods such as Scrum, Extreme Programming, DSDM, FDD, Crystal, and Adaptive Software Development. Instead of emphasizing up-front planning and detailed requirements, these methods placed significant emphasis on continual planning, empowered teams, collaboration, emergent design, a test-early and often philosophy, and, most importantly, the frequent delivery of working software in short, rapid iterations.
Although not stated in the description, one of the 12 principles in the Agile Manifesto states “Business people and developers must work together daily throughout the project.” Although Agile essentially changes the way developers are working, it intends to break the barrier between developers and the business, in the essence removing the role of business analyst.
Agile allowed developers to respond faster to the evolving needs of the business, but it left one element untouched: the process of taking the newly developed version into production.
What is DevOps?
The initial stages of the DevOps history start with Patrick Debois in 2008. He highlighted the conflict between the developers and operations teams when it comes to getting great work done quickly. In 2009, two Flickr engineers talked about the cooperation between Dev and Ops at Flickr, and Debois launches the first Devopsdays in Ghent.
While agile focuses on the collaboration between the business and developers, DevOps reduces the time it takes to bring the developed functionality to market by having development and operations cooperating. This is challenging as both teams often have contradicting needs. Where developers look at flexibility and innovation in their choices of technologies, operations prefers standardization and stability.
What is the problem?
Things could have stayed there, but agile brought with it an additional burden to operations. Instead of taking a new version of software in production once a year, the scrum approach lent itself to many releases per year, increasing the workload on the operations teams. DevOps lent itself to automation, and several open source projects appeared to develop tools for automation of testing and deployment. It quickly became obvious that those tools benefited all parties as it removed human error, standardized deployment processes and increased the speed at which the functionality was installed. Where agile is a synonym for an approach, DevOps is increasingly becoming a synonym for automation.
DevOps and agile remain two different topics though. Sure you can do DevOps with applications that are developed using a waterfall model, but that requires you develop the automation to be used only occasionally. Does that really makes sense?
Think Lean, think Supply Chain
Software development used to be somewhat of an art. The agile/DevOps revolution is slowly turning it into an industrialized process. So, why not look at it from that perspective? I would argue that the development of new functionality is like a supply chain. It responds to a demand (the availability of a certain functionality) by creating, testing, releasing and deploying a piece of software that delivers the required functionality, and in doing so allows the business to fulfill the demand.
If we take for granted that the response to the demand needs to be fast, then agile and DevOps need to work hand in hand. They are no longer two different concepts that occasionally operate in parallel, but two sides of the same coin. So, why keep different names? I’d suggest that, in a supply chain spirit, we call it BusDevOps, getting the business people, developers and operations closely working together towards a common objective: to quickly address the needs of the market.
Let’s add lean thinking and review this BusDevOps process in terms of removing waste (Muda). From the 7 wastes recognized in manufacturing, four are relevant to software development:
· Waiting. The time a developer is waiting for the provisioning of an environment, the operator is waiting for an installation to be finalized; these are examples of wasted time, time during which the developer or operator could perform other tasks.
· Motion (in the context of software development). I’m thinking about motion every time a piece of work is handed over to somebody else to be performed. As this requires the person to be instructed on what needs to be done and why, time is lost, and again that is waste.
· Rework. The later a problem is found in a software module the more complex it is to fix. Automated testing facilitates the thorough testing in early phases in the development, reducing rework down the line.
· Over Processing. This one is interesting. In manufacturing it relates to the use of inappropriate techniques or equipment, the use of too tight tolerances, performing processes not required by the customer etc. In software development we occasionally overcomplicate things, such as using technologies that may be an overkill. What’s good enough, should be our key question.
Go through your BusDevOps process and review where you have waste. You may want to remove it. To do so, you may want to go as far as using Kanban (or Just In Time) techniques to make waste visible.
BusDevOps and the Digital Enterprise
As companies evolve to digital, as they embrace the new style of business, business and IT need ever increasing integration to respond to the evolving needs of the market. BusDevOps is a key element in IT adding value to the process, and frankly, avoiding increasingly IT literate business people to develop their own solutions behind the back of IT.
Increasing the speed to market, reducing waste, and standardizing deployments are all elements that help companies become more responsive to change while reducing costs. Taking a true BusDevOps approach enables this, combining the best of agile with DevOps. Do you agree?
This article was first published on CloudSource in January 2016