Taking a Fresh Look at Continuous Delivery - What are We Really Trying to Achieve, and How Do We Do That?

Organizations are embracing Continuous Delivery (CD) for many reasons nowadays, including:

  • better throughput and stability of systems built and managed
  • better effectiveness of the organization, resulting in better financial outcomes for the organization
  • better job satisfaction for members of the organization
  • a desire to play with shiny new things and engage in resume driven development

When we take a deeper look at what the goals are, and talk about how we accomplish those goals, many times the discussion starts to devolve into a discussion of tools and tool capability. And many times, the deciding factors of one tool versus another tool speak to the capabilities of the tools to work in the existing organizational structure.

But this approach is flawed. If we view CD as an organization change to achieve the goals stated before, then we should expect that the organizational structure, as well as the organization’s guiding principles will have to change as well.

This talk will center around the premise that the changes that are needed to accomplish CD, and subsequently achieve the benefits associated with that involve the use of new tools (potentially bright and shiny, as well as resume enhancing). But the tools are merely necessary but not sufficient in attaining the organizational’s CD goals. True teamwork both from both a technical team perspective as well as inter-team collaboration as required to truly get to full positive outcomes for DevOps based CD. We’ll speak to some tools, but mostly talk about good teams and the top quality software that they need to produce, and how they need to go about that.


Outline/Structure of the Talk

This is a small talk that will center around the flawed premise that Continuous Delivery is always the goal of a team.  I will argue that while Continuous Delivery can be quite a benefit, it is more of a tactic than a goal in and of itself.  I will claim that to achieve a true Continuous Delivery goal, one must be more advanced along the Agile Fluency model than simply trying new skills out, and that organizational change away from silo efficiency towards organizational effectiveness is needed.

Learning Outcome

  • many organizations are so caught up in the sing song of Continuous Delivery that they are looking at the practice as some sort of Silver Bullet that will, by and of itself, solve organizational health issues
  • the IT organizational model is very flawed, and fosters the belief that greater team efficiency will result in better organizational effectiveness - in fact it doesn't, and sometimes it creates more problems than it tries to solve
  • before committing to Continuous Delivery as the only way for IT to work, organizations would do well to pursue true teamwork, as well as a restructuring of the organization to avoid committing Lencioni's "Five Dysfunctions of a Team"

Target Audience

Delivery team members and delivery team stakeholders (POs, SMs, etc).

schedule Submitted 3 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Joel Tosi
    By Joel Tosi  ~  3 years ago
    reply Reply

    Hi Howard, 

       I liked the submission up to the Agile Fluency Model.  Why is that necessary for the talk?  I'm also concerned that this talk is too high for the audience, meaning you are talking about organizational constraints which may very well be outside the control of the group.  Would this fit better under mindset?



    • Howard Deiner
      By Howard Deiner  ~  3 years ago
      reply Reply

      Hi Joel!

      I appreciate your comments, and see your points exactly.  My position is that there are any number of wonderful tools and frameworks out there, that the audience is eager learn and use, which I refer to as "shiny new things to play with and resume driven development."  I'd like to put the sensitivity out there for why this is a bigger problem than can be solved by developers alone, as well as why organizational restructuring alone will not solve this.  While I'll probably be speaking to mostly "doers" rather than the C levels, I'd like to engage both in honest discussion for why this problem is still a problem, and why simply throwing money at it in the form of tools and systems doesn't fix it.  That's why I brought the Agile Fluency Model up.  I have plenty to speak about for a 20 minute session without that.  If you believe that I would be better off not going there, I can see that.

      The reason I don't want to get into a mindset group is that tools really are a big part of the solution!  I want to engage these people and remind them that it is a means to an end.  Not the goal.

      --  howard