Flirting with Processes over Tooling

A 5 minute lightning talk of what happened when we implemented a process around a tool, and a tool around a process.

Transcript

1. Flirting with Processes over Tooling James Bach @mechaspam @jalev
2. DevOps developed a tool and wrapped it in a process for Developers Example 1
3. Results • Process turned out to be insufficient for dev needs • Process was limited by flexibility of the tool • To fix the process, we had to rewrite the tool • By the time that happened, the process needed changing again, and so did the tool • At this point, Developers are confused about what the process is and what the tool is supposed to do
4. Developers lost confidence in the tool and the process, and just stopped using it
6. (me, during this entire rollercoaster)
7. DevOps presented a proposal for a process and some possible tooling to the Developers Example 2
8. Results • Devs draw their process requirements on whiteboard. The process is clear to everyone in the room. • Tooling used to implement is weakly defined: “Tool doesn’t do what we want? We’ll just find a new one” • Devs actively want to be involved in the implementation.
9. Devs are upholding the process. They created it. It’s solving their problem.
10. Devs are upholding the process. They created it. It’s solving their problem. (Also, the DevOps team aren’t pulling their hair out over the implementation)
12. Takeaways • Enable developers to develop their own processes. They’re more likely to stick than if you try forcing your own on them. • We live in a tool jungle. There are many tools available to solve your problem. Pick a new tool or chain others together to meet your needs. Develop only as a last resort. • Empathise with your developers. Understand their needs. • Define the limits of what your process should do. Don’t get carried away.
13. Thank you :} James Bach @mechaspam @jalev