0

I work in a traditional software development environment. A team of developers work on a product in 2-4 week Sprints and then hand the results over to an operations team to be deployed and managed. Our operations team runs our PreProd and Prod environments under an ITIL framework.

We’ve been trying to include operation staff earlier on in the process by inviting staff to Scrum events. This works for 1-2 weeks but fades away since there is typically nothing for an operations person (with a non coding skill set) to do until launch day... and no one wants to attend daily standups or other scrum events hen they have nothing to do...

I still believe operations should be involved earlier, but I’m reluctant to “invent” product backlog items just to enforce the culture.

How do I encourage more interaction between operations and development in a Scrum environment?

LazyCoder
  • 607
  • 4
  • 11
  • 1
    Why is there nothing for them to do? Shouldn't they be setting up automated deployments, so that deployment should happen automatically at end of the sprint. – Euphoric Jun 20 '18 at 10:49
  • @Euphoric yep. Automated deployments usually take a few hours since we already have tools have frameworks in place. I was wondering if I should be creating PBIs to set up monitoring and reporting? Which seems odd since this isn’t what the product owner prioritises... it’s just what happens to fit the skill set of the tea – LazyCoder Jun 20 '18 at 10:57
  • What else are they doing during the sprint? Its not like they only work when deployment is needed. Just because it is not PO's priorities doesn't mean they just laze around? And PO should not be involved in time spent on process improvement. – Euphoric Jun 20 '18 at 11:15
  • 6
    As devil's advocate I would ask, why do you want them there if there's nothing for them to do? Doesn't that seem to disrespect the value of their time? – Eric King Jun 20 '18 at 14:38
  • Stop shipping *just* at the end of the iteration. Start shipping as soon as a thing is ready to go to prod. – RubberDuck Jun 21 '18 at 01:40

3 Answers3

8

Don’t shoot… I come in peace ;)

I can relate to the other side of the coin as I used to be one of those Operations People.

Just imagine that you(the Dev) are being pulled into Operation meeting where there is nothing for you to say or relate to and you have to sit there for a number of hours. And the only thing you can think of is you backlog of BAU tickets. I have found this incredibly boring and a total waste of time for me and my team.

Anyway at the end we (Dev + Ops) together have found a common ground.

The Ops will be included into retrospective meetings at a given stage i.e. at the beginning or the end. Where we will be discussing the part of the sprint that somehow relates to the Ops whether it will be performance, requirements or anything else. It would take as long as it had to i.e make sure that you have points ready to be raised with the Ops so the meeting is structured. Anyway once everyone is satisfied, the Ops can leave to their duties and the Dev can carry on with specking new features or whatnot.

My message would be: find a common ground and perhaps someone from the other side(Ops) who understands your concerns and is open minded when it comes to DEV i.e. someone who has "DEVOPS" mentality.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
MMT
  • 199
  • 4
1

I don't think there is an official(tm) skill set for "OPS" every company will have different responsibilities for the role.

However, I would say that normally DEVOPS is not something you do as part of a 'add a new feature to our software' style sprint.

If you do "DEVOPS" then your operations environment is in place. As is your build, test and deploy pipeline.

The OPs team would be doing their own thing making sure servers don't crash, monitoring the firewall, installing new hardware etc. The DEVOPS team might be working on a project to "migrate to the cloud" or somesuch

Ewan
  • 70,664
  • 5
  • 76
  • 161
1

The answer above about finding a common ground would be the best advice, and in keeping with the spirit of devops - but personally, the idea to bring operations and development closer together for me means to stop thinking of personnel as 'dev' or 'ops' in the first place, and to bring everyone's strengths to the fore in terms of improving the overall product. Practical suggestions which have worked for me in the past, in terms of getting everyone involved in a discussion:

  • Build pipelines - How long does it take to build, test, deploy and rollback changes to various environments? Why can't we do this automatically? What can be done to improve this?
  • Monitoring and observability. What do we know about the health of our various software systems? What business capabilities do they support? If we lose a particular service, how critical is it for the business? This is traditional Ops/ITIL fare, but focusing in on this with more traditionally dev-minded people a) reinforces the importance of safe changes, b) often brings better insights into "we can totally automate this"
  • Security, performance, and software vulnerability management. Depending on how your company structures various skillsets this may require bringing in other teams/people to help out, but establishing continuous penetration testing or performance smoke tests that run early in the piece (rather than right before you go to prod!) is critical in getting fast feedback and ensuring quality through the cycle. The same goes for keeping the team abreast of security or licensing vulnerabilities in the software that they use, and avoiding npm package dependency hell :)
  • 'The Pink Test' - An exercise to test the development/deployment cycle time. How long does it take to deploy the simplest of changes, e.g. "turn this screen pink". This needs input from everyone (traditionally) because it's not just the development effort required but then analysis of your change management process and infra/deployment processes. Once measured, decide if this is appropriate for the business' needs and see what can be done to improve that cycle time.
f1dave
  • 362
  • 2
  • 13