Devopsdays 2019: using design methods to establish healthy devops practices - Aras Bilgen¶

Tags: devopsdays

He works for a company that helps other companies transition to devops. Most of his clients are mostly interested in tools. “Just install jenkins and docker for us and we’re a devops company”. They’re not interested in “you need to do something about your culture”.

How to improve that? He started thinking about his design background.

Design is all about understanding user needs and creating something that solves the need. Good design also makes things work better. And makes it work nicer.

Design can also reframe problems. Good designers:

• … work directly with actual users. They don’t listen to “product owners” or so.

• … good designers welcome ambiguity.

• … give form to ideas. They don’t just talk about it, but they also try to build it. Whether a physical model (“a ford mustang 1:1 made from clay by the actual designers”) or an electronic prototype.

• … co-create in a safe setting. You start welcoming critiques when you’re in a “design studio”, for instance.

• … experiment and revise. Everything well-designed today has been improved slowly and incrementally!

He explained the “design thinking” process in one of his devops consultance projects. They talked to the actual users. They did collaborative process map workshops (think: walls full of post-its), instead of thick PDFs and big Visio diagrams.

“Challenge mapping” workshops. Looking at all the brainstormed solutions. Some are really elaborate. But sometimes there are solutions that are so simple and robust that they’re immediately implemented right after the workshop…

Diary studies: just give some employees a diary to write up all they’re doing for a few days. Instead of having the whole company fill out corporate timesheets.

Two take-aways he wants us to remember:

• Mindset matters more than background. They did this process with developers that were really not designers. But with a little bit of training they could start using design methods.

• Stop and listen. Listen. Really listen. Not because they’re your boss or customer or colleague, but because they’re a human being.