A Basis for Automation, Part 2: Inclusive Continuous Delivery

This article was previously published on LinkedIn.

You are the Delivery Manager. There are 1,000 people in your organization. Twenty-five of them are on your project. Of the 25, six defined "done" for this deliverable. In your opinion, you delivered some of your best work. Twelve people, not on your project, come out of the woodwork telling you things are missing from the deliverable. You're surprised. The project sponsor is mad. Your big boss wants answers. And the delivery team wonders why you're letting people say harsh things about the deliverable and team without a fight. The deliverable cannot go to market until you get this figured out. What happened?

Many people suggest this is a problem with the Delivery Manager. Some suggest that stakeholder requirements were not identified and managed correctly. Others blame tools, processes, procedures; some notice internal kingdom-building, protectionism, and turf wars. A few even suggest the technologists who built the system are basement-dwelling anti-social figures of darkness who deliver what they want and don't seem to know or care about business needs. While these conversations may be entertaining, in the end, finger-pointing conversations don't solve the real problem.

• How does it even happen that we miss stakeholders and requirements?
• How do we ensure we've identified and included all pertinent stakeholders in project definition, verification, and validation?
• How are we going to deliver all these additional requirements, definitions of done, and system attributes?

The answer is simple and accessible.

How Do We Miss Stakeholders and Requirements?

The problem starts inconspicuously at the beginning of the project when people are classified as one of two groups: requesters and builders.

After that, requesters are decomposed further into three groups – now, later, never.

• We'll concentrate on these roles/users/user classes now,
• We'll consider those other roles/users/user classes later, and
• We're not going to consider these roles/users/user classes

From above, the "deliver now" requests are then prioritized even further into:

• We'll do these things first,
• We'll do those other things immediately thereafter, and
• We'll do these other things later.

It seems deductively logical and very efficient.

Grooming a backlog is a learned skill. And when done well, it enables team focus and success, manages project risk and reward, as well as provides iteration upon iteration of value to the targeted stakeholders. A single, frequently curated, and prioritized backlog is a healthy core behavior of successful projects.

Over-zealous backlog grooming may also be why you're missing expected functions, features, and attributes when projects are delivered. The project team thinks they are done, and yet things are missing.

Have you considered that teams are so efficient at curating the backlog that stakeholders and requirements are collateral damage?

How Do We Make Sure We've Included Everyone Necessary?

Create a cross-functional strike team responsible to securely operationalize the planned project deliverable – from inception to delivery. A project is not just documents and code. Projects operationalize ideas to serve clients, expand opportunities for growth, and generate revenue.

To securely operationalize requires a complete end-to-end cast of people from project sponsorship to design, develop, test, inspect, and secure to back-office operations including finance, procurement, sales management, and support services.

Then as a team, perform the following steps incrementally and iteratively through the course of the project – and support – efforts:

• Identify the problem statement and desired outcomes.
• Identify the work and definitions of done per work item. Focus upon roles, capabilities, and attributes.
• Structure the work into independently digestible chunks with clear definitions of done.

NOTE: Common today is the use of Epics, User Stories, and Acceptance Criteria.

To have the highest probability of delivering something useful to most, we need to know what they want by including more people, more roles. Conversely, to have the highest probability of dissatisfaction with the deliverable, exclude people and guess on their behalf.

You may be wondering, if there are going to be higher numbers of stakeholders and higher amounts of requirements, how are we going to get this done without lengthening the project, increasing the cost and adding to staff?

Enter the role of automation.

What Is Automated Continuous Delivery?

Developers are expected to do many things. Writing code is a means to an end, not the deliverable itself. To deliver more value, minimize context-switching, and increase flow, developers seek optimizations.

For some, optimizing means cutting things out and kicking them down the road. For many others, optimizing means automation.

What do I have to do?

What can I aggregate, separate or eliminate

What do I have to do manually?

What can I automate?

A fantastic result of developers who seek efficiencies through automation is that those same efficiencies can be used all along the delivery pipeline and out into general availability/production.

For some great examples of how developers seek to simplify through automation, look to Will Rubel, and his four-part series on test automation in delivery pipelines.

What about all of this makes automation and continuous delivery inclusive?

Remember the cross-functional strike team previously discussed? Many times, stakeholder numbers are minimized to control scope, time, cost, risk, and complexity because the developer, respectfully, is the constraint.

Automated continuous delivery pipelines change the math regarding how many stakeholders, requirements, and developers are required to deliver value.

With automation, we decouple the dependency between requirements and the capacity to meet them.

How Will We Deliver More Value with Fewer People?

There are three keys to moving into this new paradigm:

• Use your cross-functional teams to define work.
• All work must have definitions of done articulated as acceptance criteria.
• All acceptance criteria become automated tests that are applied to user stories on the continuous delivery pipeline.

Cross-functional teams contribute to the discovery, definition, and prioritization of roles, capabilities, and attributes in the backlog and participate in demos to verify value. The smaller strike team who makes the code commit, builds, verifies, and delivers the solutions also creates automated tests along the way.

Together, they rely upon definitions of done, automation, and the continuous delivery pipeline. Together they deliver a solution.

Principles for Delivering the Solution Everyone Wanted

• Let anyone at any time, for any reason, add any ideas, suggestions, or requests to the backlog.
• Curate, cultivate and prioritize the backlog perpetually, dailyUse cross-functional delivery teams for backlog prioritization, epic and user story build-out, design, development, inspection, testing, and delivery behaviors from beginning to end of the project.Tell teams to focus on flow.
• Use version-controlled, continuous delivery principles from end to end of the project, i.e., from developer out into product implementation support and evolution (General Availability (GA)).
• Automate. Automate. Automate. If you would like to further explore the reasons and value behind software automation, refer to A Basis for Automation, Part I.

We don't need to run from, defend against or hide from stakeholders and their expectations. Instead, invite them. Then continuously curate, prioritize, and automate their feedback.

How Do I Get Started?

If you're perplexed by delivery teams saying they are done, but the solution delivered seems short on features, functions, and value, the conversation more likely lays around how software is being defined and delivered instead of what.

• Ask your teams how they choose stakeholders.
• Ask your teams how they choose requirements.
• Ask your teams if, how and to what extent they use continuous delivery principles and automation. Do they pursue continuous flow?

Their answers point you to your next steps.

Interested in Examining Flow?

Trility joined Bâton Global for a podcast series on Human-Centric Transformation. In the four-part series, they discuss how leaders and technology can simplify and automate processes for team members, stakeholders, and customers. Before you listen, view our companion infographics highlighting key takeaways as these organizations discuss how to better respond to industry headwinds and pressures.