This session will explore the conditions needed to facilitate developer autonomy and create an awesome DevEx. What makes a good developer experience? What are the common stumbling blocks? How to architect to manage risk, governance and autonomy? How to build modern team topologies that don’t hinder progress and ensure long term sustainability? How to build a culture that is transparent and breaks down silos?
What is DevEx?
Developer Experience is about creating an environment in which a developer can do their best work.
How do developers feel about the processes, …
The work we do should not be the cause of all these negative feelings
#aotb2022 @Agileonthebeach @hibri on #DevEx developing software environment should not evoke unpleasant emotions
– ilan kirschenbaum (@kirschi_), Jul 7, 2022
Why is DevEx important?
it has impact on the organisations performance, the bottom line!
developers are expensive, why make it hard to do their jobs? -> Profit???
What does good DevEx look like?
- Heroku - do everything via the cli and Git
- Monzo - cli tools for deploying
DevEx is contextual
developers exist in an environment that is unique to your organisation and environment -> copying what other orgs does might not work for your org
A good developer experience is emergent!
=> create boundaries for risks and responsibilities
=> good fences make good neighbours
Product Teams:
- builds, owns and runs the product
- owns the product governance
- owns the product risk
- owns the end to end delivery
- owns billing and financial risks
vs the Platform Team
#aotb2022 @Agileonthebeach @hibri product team never sees the aws bill, they just know how much the entire solution costs - freedom within boundaries
– ilan kirschenbaum (@kirschi_), Jul 7, 2022
=> create a shared responsibility model between Product Teams and Platform Teams
don’t try to make everyone do everything
=> create team interaction for fast flow -> Conway’s Law
Conway’s Law affects the developer’s experience
example: CTO responsible for engineering and QA vs COO responsible for Ops
=> adopt an internal OSS model -> platform/dev tooling code is visible to everyone
- everyone can contribute to making things better
- but must be clear who is responsible for it
an internal OSS model removes barriers to collaboration
example: Devs are not allowed to view Ops team’s code
=> create fast feedback loops
good DevEx facilitates this
How do we measure DevEx?
the SPACE framework
- S - Satisfaction and Well-being
- P - Performance
- A - Activity
- C - Communication and Collaboration
- E - Efficiency and Flow
– Forsgren et al., 2021
First time seeing the SPACE framework for #DevEx. Definitely taking this back to work so I can work with the devs to make their lives better. Cheers @hibri for the new info - and cheers @nicolefv for a new tool. #aotb2022
– Gwen Diagram (@gwendiagram), Jul 7, 2022
Dispelling developer productivity myths
- productivity is only about individual performance
- one productivity metric can tell us everything
- productivity is only about engineering systems and dev tools
- the biggest myth: productivity is about developer activity -> being busy
Key Findings:
- finding flow is key, interruption is a drag
- meetings are both awesome and terrible
- a two minute daily reflection (and not being busy all the time) can help developers improve their days
Key to developer productivity is great #DevEx and key to great DevEx is effective @TeamTopologies #aotb2022
– Agile Stationery (@agilestationery), Jul 7, 2022
Why?
A good DevEx helps devs find flow and reduces interruptions -> get into that creative zone
A good DevEx reduces the cognitive load for developers
A good DevEx creates an environment of psychological safety
Conditions for an Awesome DevEx to emerge:
- there are good boundaries for risk and responsibility
- team interactions are optimised for fast flow
- adopt an internal OSS model
- …