With fear of jumping on a using a portmanteau trend (a shortening a number of words and linking them together such as done with DevOps, SecOps, DevSecOps, NetOps, NetSecOps, DBAOps, WinOps, and DataOps etc.) let’s cover what the principles of DevOps are (we’ll then leave it at the discretion of the reader if further analysis of these terms is required). According to Wikipedia, DevOps is a set of software development practices that combines software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.[1]
Whilst Agile is intended to close the gap between the customers (business) and the development team, DevOps aims to close the gap between the development team and operations that typically operate in siloes. You can therefore see how utilising both can bring about operational effectiveness of the idea to value for the business. And likewise to Agile, DevOps also requires a cultural change within the enterprise.
DevOps has the following 7 key principles[2] to follow:
-
Foster a collaborative environment
-
Impose end-to-end responsibility
-
Encourage continuous improvement
-
Automate (almost) everything
-
Focus on the customers’ needs
-
Embrace failure, and learn from it
-
Embrace failure and learn
DevOps has the principle of continuous improvement, and as such has a continuous lifecycle as follows:
.png)
It should be noted that these individual activities can be carried out within a sprint focused on that activity, as well as during other sprints. The naming convention of these activities has an associated role (see the A-Team). In addition, we have lifecycles for all our work items, whether they are the Epic itself, or its’ Capabilities, Features, Tasks, Improvements or Bugs.
When we first meet the client, we go into a discovery stage. This is our time to start building the backlog. We talk more about this in the Customer meeting section. This forms our requirements. The requirements will be iteratively amended, improved and re-prioritized throughout the project.
Generally work items in this stage are the responsibility of the prepper (an analyst) to further define. We may have Features in this stage that have been loosely declared as being desirable, and it is the analysts job to put some meet on the bones and create child user stories (and maybe some tasks) to these Features.
During this stage we are generally working in our requirements capturing tool (such as Microsoft DevOps) and will form the majority of the workload in the early Sprints (or before the Sprints).
Once we have client approval, items can move into the design stage. The design includes activities such as adding further clarity to the backlog, creating information architecture and wireframes, as well as graphic designs.
Work items in this stage are generally the responsibility of the Technical Designer and/or UX/UI Designer. In this stage we might create wireframes, data dictionaries, workflows, taxonomy and technical design documentation (remember we try and keep documentation down so ideally no big lengthy technical design documents!). As we’ll talk about later, an important aspect of this methodology is that the “Test Pilots” (QA) are involved early on and during this stage they can be starting to create the Test Cases for the Epic.
While we’re on the subject of design. Be cautious getting all your screens wireframed up and then each individually designed. My suggestion is to spend the time on creating wireframes yes, but create a common design language document rather than try and then “colour in” each and every screen. When changes come, and they will come, you will be in a losing battle to keep the development, graphic designs, and wireframes all in sync.
With regards to the artefacts that come out of the design stage, try and keep them nicely coupled to the Features and User Stories. Putting these assets into a tool such as InVision is not only a great way for developers to grab CSS and HTML code from the designs, but it’s also possible to put “notes” on the screens that link to the relevant User Story. For example, you may have a “Delete” button next to a record in the wireframes that has a note to the User Story “I need to be able to delete a record”. Likewise, the User Story can have a link back to the relevant wireframe in InVision.
Remember though, “working software over comprehensive documentation” from our Agile Manifesto, so don’t go to unnecessary levels of documentation that won’t be read anyway – you’ve worked with software developers right?! For example, don’t spend weeks creating mock-ups for each and every page if they are going to be time consuming, but instead create wireframes of the various pages (to save time) and instead create a set of brand guidelines to follow. That way if the design styles need to be changed, we don’t need to retrospectively go back and amend everything. Likewise, our designs and actual delivery won’t get out of sync and cause confusion about what should actual be delivered.
During this stage we are generally working in our requirements capturing tool (Microsoft DevOps) and our design tool (such as InVision) and will be the majority of the work involved in Sprint 0 (zero).
OK, we’re getting to the fun stuff. This is where actual development (engineering of both architectural and software parts) of the solution is carried out. By this stage there should be sufficient clarity in the backlog items to commence development. User Stories will have acceptance criteria populated, sub-tasks created and alike – we’re ready to rock!
Following the principles of “infrastructure-as-code” we’re building not just the software solution but a “coded” environment. That is, even the infrastructure is written down in the form of templates and put into source control (the server configuration, or even better, the platform service definitions). These templates will follow the application lifecycle management that code follows – no fiddling with settings for this and that in production environments in other words! Hands-off our production environments cowboys! We’ll talk more about this in section 11.3 Infrastructure-as-code.
Work items in this stage are generally the responsibility of the Development Engineer and Operations Engineer.
OK, we’ve engineered the solution. It’s ready to deploy to production right? Not so fast cowboy! One of our values is to deliver high-quality high-value (HQHV), so we need to ensure we are indeed doing this - not just quantity of lines of code.
During this stage the solution is deployed to the Test environment (QA) with a release note sent to the Test Pilot. This lets them know the Features, User Stories, Bug fixes and Improvements that are included in this release. As a team you can determine at which point you want to release to Test, but don’t leave it to the last Friday in the Sprint! For example, you may decide the pipeline should release to Test every Tuesday and Thursday (or just “on demand”).
From the deployment to Test, the Test Pilot will identify Bugs and Improvements to improve the stability and quality of the solution being delivered. We’ll talk about the “Bug Cap” later which is a way to ensure that this stage doesn’t become overloaded with an insurmountable quantity of bugs to fix.
During a project of over 3 or 4 engineering sprints, you may want a dedicated Test sprint to improve the stability of the solution. SAFeR has the concept of IP sprints (Innovation and Planning[3]) that follow a similar principle of allow the team to carry out improvements, training, and a general buffer for the project.
Following the principles of SAFeR, we make deployments to production “on demand”. We want to deploy to production little-and-often rather than “big bang” launches. This reduces the stress on the team on doing deployments because they are used to doing them frequently with each deployment being less of a code change. In addition, you can implement A-B deployments such as using deployment slots in Azure to allow for gradual rollouts of changes.
Whilst making deployments is great, think about the adoption of the value you are delivering to the business as well. Do they know what has been deployed? Using Release Notes that includes details on Features, Bug fixes and Improvements, in your release pipeline is a great way to ensure the business are aware of the great value your team are delivering. Do the business need training? Is there a communication strategy to inform the wider audience of changes? Are we learning from the deployment feeding back into our continuous improvement?