Continuous Delivery, is an evolution..

Agile practices continue to influence the market, both business and product development likes the agility and benefits. With increased Agile adoption, many organizations have matured from shipping working software once in 6+ months to once in ~2 weeks.

Almost everyone I talk to talks about Scrum practices, user stories, few hours of planning for next incremental change, sprint cycles, continuous/daily visualization of work against sprint goals, highly collaborative open space working environments and culture, shipping to prod at the end of the sprint, retrospection and continuous improvements.

As they continue to mature next wave seems to be towards Continuous Delivery. Already some parts of the organizations in Etsy, Netflix, Facebook are way ahead of the crowd in delivering working software multiple times a day. However, rest of the world is still catching up. I/We still talk (talk, talk) about some of the practices that facebook accomplished in 2010 (ie.feature flagging).

From my exposure and experience, feels like its relatively easy to accomplish continuous delivery in greenfield products/projects vs legacy work, relatively easy in small crowd vs large teams,etc..

Equally, there seems to be an illusion that everyone who practice Agile/Scrum assumes they are in continuous delivery mode. IMO, below is a sample of ideal continuous delivery outcome ..

CD Flow
CD Flow

–> Every check-in potentially triggers a build.

–> Every build potentially triggers a deployment.

–> Every deployment potentially triggers a verification process.

–> Every verification potentially increases the confidence and build gets promoted to the next stage.

“This cycle continues until code reaches production or pipeline stops where failure happens”

This flow is not something new that we invented today, this is the same delivery pipeline that is in practice since software development started. However, there are some key practices makes it more interesting and bubbles up the need for long term commitment

  • Faster feedback – Goal is to gain fastest possible feedback on every commit. If a code change committed today and not fully verified against the acceptance criteria, work is not fully done. If we want to be efficient at this then we need to automate all the stages in the pipeline.
  • Automated pipeline  – this is one of the key differentiators towards true continuous delivery. Every stage in pipeline needs to be automated in order to gain faster feedback on a given change. Any manual intervention will defeat the purpose of gaining fast feedback and slows down the pipeline. Identify the bottleneck and keep automating from left to right. It might be fairly easy to achieve this with Sprint Zero on greenfield projects.
  • DoD, Acceptance criteria, Agile coach – one of the core principles in Continuous Delivery is “Done === In Production”. Nothing less, nothing more !! In order to be successful in this journey, role of Agile coach is super critical to craft their Definition of Done, working with PO/team to derive quantified, testable user story/acceptance criteria and help the team to navigate towards that goal on every single story. Inadequate attention to these will easily derail everything, succumb to delivery pressure, end up delivering many half baked solutions and accumulating tech debts sooner than anticipated.
  • Rationalized Test Automation – once the DoD has been set towards true Continuous Delivery, Automated verification process is essential. As code progresses each stage, verification process should offer more confidence or stop the line. Traditional practices kept test automation efforts outside of development team, that lead to natural disconnect between developers and testers, testers ended up automating mostly @ the surface level (GUI) and non-deterministic nature of GUI tests lead to lack of confidence on automation. Redefine quality strategy to be agile, treat test automation to be a part of the story, stick to test automation pyramid, maximize the automation and regain the confidence.
  • DevOps culture – if we want to automate everything, we need those capabilities part of our team including infrastructure automation, monitoring and all operational aspects. If we don’t have those skills within the team, lets build them.
  • Proper tooling – self organized teams is one of the core tenets for successful Agile organization. Product teams primarily exist to solve business and customer problems in the most efficient manner. Now that every story needs to be fully done, fully integrated all the way up to production, tooling plays super critical role. A tool that can orchestrate the entire pipeline, coordinate and move the pipeline forward, ability to stop the pipeline upon failure, offer visibility from check-in thru release and a transparent single pane of glass for developers to track the check-in. Without proper tooling, teams will end up developing internal tooling that will lead to lifetime commitment to support, maintenance of internal tool instead of solving customer problems.

IMO, Continuous Delivery as a goal is a great first step, however, it needs long term commitment to nurture and mature.

Advertisements

2 thoughts on “Continuous Delivery, is an evolution..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s