PDCA and DevOps

What do PDCA, Toyota, and DevOps have in common?

DevOps – PDCA (*) – Kaizen Computing – Rapid Iteration (aka The Scientific Method)

It seems like a hassle to have to watch a video and write down everything they say – but remember – you get this right and hand it off so someone else can repeat these steps.  Then you can go on to learn new things and solve new problems for your team.

(*) Plan, Do, Check, Act – https://en.wikipedia.org/wiki/PDCA

1- Write down what you plan to do BEFORE you do it. This includes the configuration changes as well as a test plan to verify the change. Start simple and add details as you iterate. Many times someone else has already started a document showing how they would do something similar to what you want to do. This could even be a video from a blogger or vendor. Start by doing a copy and paste if you don’t have access to edit their procedure directly.

An agile story is a simple method to capture most processes… for example:
- In order to: do the thing we want to do
- We will: take the following steps - list them out with as much detail as you wish - these will be expanded on in the future by either yourself or others.
- This is done when: describe the success criteria for the completion of the task. How do we know when we are finished?

2 – Follow the steps you’ve written. If you need more detailed instructions look up procedures and collect suggestions from colleagues. Following this method is a great way to capture and disseminate Tribal Knowledge.
3 – Things won’t always work as expected. Check the results. Experiment a little if needed. Iteration is key. https://itrevolution.com/the-three-ways-principles-underpinning-devops/
4 – Finally – take Action to adjust the initial plan. Wikis (like Confluence) and Issue trackers (like Jira) are excellent tools to help with this process.

Repeat this process over and over as you work throughout the day. Encourage your team mates to collaborate with you on the development of these procedures and cookbooks.

PDCA can be used by just one person implementing a new feature for an existing vendor project but it also useful for large team projects with many groups needing to work together. Lately many software companies are working with a Fail Fast, Fail Often philosophy where success is measured by how many updates per day are made to the code base. For IT groups the equivalent metric to watch would be wiki page updates.

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 )

Connecting to %s