Part 1 of this post suggested that we should recognize that the shift to a DevOps world is not a revolution, but an evolution of our rich heritage of delivery practices. In part 2 I conclude my summary of the different eras of “best practice” before addressing the questions originally posed.
Scaled Agile Development Practices
Most agile approaches have an idealized view of an agile team – such as the team being small and co-located. However, in many organizations, teams are large and distributed. There are also other considerations – such as the relationship to enterprise capabilities like enterprise architecture and portfolio management, as well as constraining factors such as the need to conform to regulatory requirements. Scaled agile development approaches, such as the Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD), attempt to address such challenges using practices such as the following:
- Measured Performance. This practice allows project and portfolio-level measurements to inform key business decisions. For example, knowing that the burndown of a project’s product backlog is not on a downward trajectory may indicate that more (or better-skilled) resources are required on the project. Similarly, observing a lot of requirements churn (changes to already-defined requirements) may indicate that the project’s business representative may not have the domain knowledge required.
- Formal Change Management. This practice provides a controlled approach for managing changes and is (as the name suggests) more formal than the Team Change Management practice. This practice is often applied when approval is required from stakeholders outside of the project team, or when a deliverable has been baselined as part of a contract and the deliverable needs to be modified.
- Concurrent Testing. While a project team may embrace test-driven development, there is often an independent test team present (especially in larger organizations) that typically provide a level of user acceptance testing before the solution is put into production. The purpose of this practice is to bring this “external” team in sync with the project team and have them work in step with the project so that their work isn’t compressed into a separate activity at the end of an iteration or release.
The previous four eras are focused primarily on software development. DevOps brings this thinking into the world of continuous delivery, where we not only consider both development and operations (as the DevOps moniker suggests), but the entire pipeline of how an idea gets into production and feedback obtained.
- Collaborative Delivery. This practice is focused on ensuring that everyone involved in the delivery of a solution collaborates, especially Dev and Ops. For example, those with operations knowledge (such as skills in service management) should be involved early (and continuously) throughout the life of a project, such as being involved in any requirements definition so that non-functional requirements (including qualities that they know much about, such as performance and reliability) are considered from the outset.
- Continuous Testing. The process of executing automated tests as part of the software delivery pipeline, as software packages are moved through each environment in the deployment pipeline, is a fundamental practice in a DevOps approach.
- Continuous Release. Another DevOps best practice is releasing to a production-like environment early, and often. This ensures that the deployment and release processes are themselves de-risked as part of the natural progression of a project.
- Continuous Monitoring and Optimization. A key aspect of a DevOps approach is enabling feedback on the fitness-for-purpose of the delivered solution. This practice places a focus on ensuring that visibility and feedback is continuous through the life of a delivery project, and beyond (when the solution is in production), as well as actions take to manage and optimize application and infrastructure performance.
In Conclusion – From Theory to Practice
I took this thinking to a major European bank who had all of the concerns raised at the start of this post. Here’s what we did in an all-day workshop with the bank’s DevOps transformation team:
- We ensured that everyone in the room had a clear understanding of the meaning of each of the practices.
- Based on the challenges faced by the bank we identified the practices that we felt would add value.
- We assigned a priority to each of the practices considered “in scope”.
- We looked at other attributes, such as dependencies between practices, the effort to implement, the skills required and so on that would influence the implementation of each practice.
- We developed a DevOps adoption roadmap that indicated which practices would be introduced, and when.
This approach addressed the first two concerns mentioned earlier; the bank felt that the introduction of DevOps could be managed as it was incrementally introduced, and they certainly knew how they would start.
But what of practitioners feeling anxious about changing their ways of working? The key here is to recognize that everyone is an individual and comes from a different starting point. Given the practices considered in scope at the bank, and using a table of practices similar to the one shown at the start of this post, each practitioner was able to recognize which practices they were already comfortable with, and practicing, and those that would be new to them. This understanding led to the creation of a personalized enablement roadmap that would bring each individual up to speed, at a pace in line with introduction of DevOps practices at the bank.
Transforming to any new way of working can be daunting, but I hope that the approach outlined in this post can give you some inspiration, and a starting point.
Click here to learn more on how IBM Bluemix Garage Method takes the best of design thinking, lean startup, agile development, DevOps, and cloud to help enterprises accelerate application design, development, and delivery.