Presented at ThoughtWorks Australia 2010 'Team Hug' (Away day). Ten tips for developers who want to make closer friendships with the IT operations team.
19. 1. Understand incentives
2. Engage ops early and often
3. One team
4. Favour face to face communication
5. Ops is an end user
6. Share responsibility
7. Don’t place orders
8. Meet commitments
9. Don’t abuse your friendship
10. Educate yourself
i’m going to be talking about a battle that’s been raging for a long time. Which one is ops and which one is dev?
That’s the enterprise architect in the background - he’s arguing for fully redundant light sabers.
In a lot of organisations, it feels like ops and dev are separated by walls - discouraged from collaboration.
Frustrating - Developers have very little visibility into production systems, cannot read logs, database tables, or production monitoring tools. How to troubleshoot?
It feels like dev and ops are in siloes.
This is accentuated by physical separation, reliance on ticketing systems and approval bureacracy
It’s very confusing and frustrating - how do we proceed?
Sometimes no matter what we do, it seems to be wrong. We get told what we *should* have done, and always when it’s too late.
It doesn’t work. There must be a better way. What can developers do?
Spend time thinking about incentives from the ops perspective.
traditional thinking: ops task is to keep systems stable and fast. dev’s task is to deliver features quickly. This pushes down from CIOs to operations managers and app development managers, down into KRAs.
According to the itSMF (IT Service Management Forum), 80% of incidents are caused by changes made to the IT environment.
Ops are almost always understaffed, and under constant interuption - everybody’s problem is the biggest problem in the world. Defensive measures are put in place to help the ops team deal with this problem.
Important to understand - until you can understand from their perspective, you can’t influence.
may not be able to change (yet) but don’t presume people are ignorant or evil.
Project inceptions. Regular updates. Design sessions. Invite the product owner to explain business direction, if ops don’t turn up to inceptions.
retros, problem analysis (5 whys)
be relentless in this message
Use ‘we’. Invite ops to standups and retros - every time. Invite ops to lunch, functions etc.
take the time to follow up with ops to explain the outcomes of things
forgive eccentricity
pairing? work on things together. That means you helping, too!
promote your ops team members within their own organisation
don’t accept manual work - help automate if you can
Don’t be suckered into email wars.
However - follow up with tickets if required.
Imagine that the operator who gets up at 2am is a homocidal maniac who knows where you live.
Make sure Ops is represented with ‘stories’ “As a sysadmin”. Logging is a user interface. Make sure the right things are monitored - and monitorable! Stop building systems that are black box and require magic incantations and sacrifices.
feel the pain. fix the pain. google three month developer support.
shared metrics and monitoring. can you mine the service desk’s ticketing reports?
go to ops with problems, not solutions.
- you are not the first devs here - folk have been failing to meet commitments for years before you.
- no hollow promises
- covey's emotional bank account - invest!
- fix things! follow through with root cause analysis
e.g. production logins
learn some unix
don’t be afraid to ask for help, or to ‘pair’ on a problem.
