A Checklist for Leaner Devops and CI/CD Pipeline.

By James K Smith, linkedin.com/in/jamesksmith, [email protected]

In this article, James explores some points to examine to make your Devops Pipeline more efficient.

Lets review what DevOps is. It's not some mysterious concept. DevOps simply addresses the need to lean out and make more efficient communication and collaboration between two business units – specifically Development and Operations. CI/CD is shorthand for Continuous Integration and Continuous Delivery. Cover the following bullets, and you are well on your way to an efficient DevOps pipeline.

1) As part of Definition of Ready, a story should have at least one acceptance test for each acceptance criterion attached to that story.

In other words, each business value story should have 100% acceptance test coverage. Your PO and team will work together to determine each acceptance test using the standard “GIVEN, WHEN, THEN” pattern. So now you at least have a manual acceptance test script that can be executed as part of the Definition of Done for that story.

2) Once this becomes standard practice for your PO's and teams, it's time to ask the obvious question. Why do we have that UAT column on our scrum board?

Remember what UAT stands for – User Acceptance Testing. And when should UAT occur for a high-performing scrum team? When your team is doing Sprint Review and demoing the stories they have completed. Maintaining UAT or Test columns on your scrum board is asking for a dependency to happen, and affects the team's ability to commit to completing stories with confidence. UAT and Testing are meant to be tasks in the implementation plan of your stories – and remember, a story doesn't meet the Definition of Done until all tasks are completed. Otherwise these stories are still In Progress.

If there is absolutely some justifiable reason (and there can be) that Test/UAT columns have to remain on your board, then use a Kanban process instead. Nothing wrong with that.

3) After reaching a level of maturity for writing and executing manual acceptance tests, it's time to automate the execution of those tests.

Since you've already constructed your tests in the proper “GIVEN, WHEN, THEN” pattern, you're well on your way to deploying test automation tools such as Cucumber to run these tests for you. This is a crititcal enhancement to your DevOps pipeline, since once your product becomes so rich it can no longer be manually regression (end-to-end) tested in a reasonable amount of time, automation is the only way to address this time dependency. Seek out every opportunity to automate your pipeline.

4) Strive for 100% acceptance test coverage as pointed out, but also 80% unit test code coverage.

Sure, that kind of unit test code coverage can be a challenge, especially with a legacy codebase. But an effort towards always striving for quality will serve to lower the cost of the products your teams are working on.

And guess what? You've got another chance at pipeline automation by making judicious use of Restricted Checkins – unit tests are run automatically as part of your repo code checkin process. If the code doesn't pass the automated unit tests, it can't be checked in. Tip to help you realize the full potential of unit testing: Have team agree to writing unit tests first as part of your team's Agreements in Sprint Planning. It's been shown over and over again that if you code toward unit tests instead of writing unit tests after code is completed, you'll end up writing less code. Always keep an eye toward leanness.

5) Always strive for ZERO defects escaping from the sprint.

Impossible you say? Well just keep in mind that escaped defects are like credit card debt. They get a lot more expensive to fix down the road and will negatively affect your teams' sustaining velocity, as well as the efficiency of your pipeline. Not to mention skewing your release plan.

Why? Pulling a bug fix into a sprint is fine, but you can't relative size estimate the fix because you've already taken velocity credit for the story that bug originated from. You don't get double credit, and your team's capacity is reduced with nothing to show for it in their resulting velocity.

So what is a contributor to defects escaping a sprint anyway? Oftentimes your teams are trying to pull too much velocity into their sprint backlogs. As my mentor says, “Slow down to speed up.” Take some pressure off your velocity, “right the ship,” and your teams will have opportunities to accelerate in the future, especially if you teach Scrum the way I do.

Remember there's no blame for this kind of stuff. It's part of the process, inspecting and adapting, and continually improving. Trust your teams. Give them a chance to be transparent but still autonomous. If they're doing Scrum right, they'll fix this problem on their own, and you'll end up having even more confidence in them.

6) Provide your teams the tools they need for CI/CD without a release team getting involved.

This effort eliminates another possibility for an external dependency in the spirit of pipeline efficiency. To support this effort, advance toward a Release Train Model based on dates, not scope. You teams just need the tools required to catch the Train as it comes through. Your Release Team moves from a legacy control model to training teams on CI/CD tools and running the Train.

7) Implement the “Toggle” design pattern.

This is a Spotify trick that can be used to great effect. Include a “Toggle” in your feature code to switch off access if the feature is capable of being committed to the repo, but just not ready to be made available to the end-user. The point of this is that doing code merges can become a pain across multiple teams if you wait too long to do the merge.

8) Be nice to Operations and provide them with a “Theory of Operations.”

We Agilists are not much on documentation are we? Well let's be specific here with the fake Christmas tree assembly example. The people who designed the tree couldn't have documentation up front – they probably just experimented until they got it right. But then they documented how they did it. That's when documentation becomes valuable – when it becomes proven INSTRUCTIONS after the fact. So pour out the contents of the box the tree came in and hunt for the instructions. Then hand the instructions to your kids or partner and get them to do the assembly.

Additionally, while we no longer make use of the classic role of QA in Scrum, let me suggest that your QA arm is now free to take on an even more strategic role than before. Let them group acceptance tests into overall test scenarios, versioned by release of course. Just like acceptance criteria do, these scenarios identify data attributes, data sources, what business logic might be involved, what areas of the UI are involved, etc.

So consider a day in the life of your Operations group. A ticket comes in and after some preliminary testing, the ticket is associated with failing a particular test scenario as created and maintained by your strategic QA arm. Ops goes into action clearing the ticket by referencing the very data attributes, data sources, business logic, etc. included as part of the documentation for that test scenario. Thanks to the provided information, the ticket is cleared that much faster, service level agreements can be optimized, product costs go down, and a few hugs and high-fives might even occur.

9) Finally, I'm just going to leave a teaser for this one because I'll address it in my third installment on “The Cone of Uncertainty.”

I'm going to suggest that the definitions of Continuous Integration and Continuous Delivery should be expanded to mean more than just management of code and releases. CI/CD are really by-products of a properly shaped Cone. And I'll attempt to illustrate, using the Cone, why CI/CD is no longer just a Team objective, but can be moved all the way back to the Solution objective level to create a full ideation to release pipeline process that continually produces outcomes, always with an eye toward leanness.

Until next time,

James

James Smith has a 25 year career building high-performing technology teams and organizations for a multitude of industries. He enjoys working with startups to some of the largest corporations in the world, has held several highland games world records, and has pitched to VC using nothing more than napkin drawings and a bowl of M and M's. He claims there's only one truely always-optimizable XOR result in the universe, that either 2+2=4 or it doesn't, but not both. Otherwise, some of the best answers can be found in the grey areas.

#kanban #agile #scrum #safe #less #velocity #flowefficiency #cycletime #agiletransformation #agilecoaching #lean #pmofficers