This document discusses the importance of involving operations teams as key stakeholders in agile development processes. It argues that operations teams should be treated as users, not just during prioritization but throughout the entire development cycle including story writing, testing, and acceptance. The document provides an example of how collaborating with operations on logging requirements led to building a completely different logging solution that better met operational needs. It concludes by emphasizing the importance of collaboration over negotiation between developers and operations.

1. TheMostImportantUsers
Agile Development with Operations in Mind

2. AboutMe
Sean Reilly
@seanjreilly

3. FullDisclosure
I’m not in ops. I’m a dev.

4. TheTraditionalWay
• Backlog of features
• Develop them
• Test them
• “Throw it over the wall”
• Release

5. Howwilltheymanagethis?
• Developers will naturally:
• Go with what’s already available
• Build what they’d like to have
• Or guess!

6. Howwillwemanagethis?
• Operations tries to:
• Sift through what’s there
• Do detective work to figure out what’s there
• Add some scripts
• Or re-engineer something

7. “ThrowitovertheWall”
• This pattern is toxic
• Operations puts up “release gates”
• Devs resent operations
• Spiral of mistrust, or worse

8. WhatWorksBetter?
• Collaboration, not negotiation
• Developers want this too
• Some just don’t know it yet

9. ButHow?

10. TreatOperationsasUsers
• And not just any users, either
• Possibly the most important users
• The operations team are the users that
turnyourapplicationon

11. MorethanJustPrioritisation
• This should be about story acceptance
• Writing the stories in the first place
• Testing the stories
• Demoing the stories
• Deciding the stories are done

12. CaseStudy:Logging

13. TheUsualRequirements
• Dynamically change logging levels
• Dynamically change formats
• Log to multiple places at once
• Highly configurable

14. RequirementsfromOperations
• A list of all messages that can be logged, and when
• Know what action to take for every message
• Easy to parse
• No mangled stacktraces
• Work with logrotate, ELK stack

15. TheBiggestDifference?
Onestorybecomesmanystories

16. Before
• “Add logging”

17. After
• “Log on application startup”
• “Log on an uncaught exception”
• “Log when an import job completes”

18. Very,Very,Different
By the time we were done, we wanted
an entirely different logging tool

19. WhatWeBuilt:The
Opsloggerlibrary
https://www.github.com/equalexperts/opslogger/

20. PartingThoughts
• There are no non-functional requirements
• Operators are users
• Be involved in the acceptance process
• Foster collaboration, not negotiation
• A lot has changed in 15 years
• Don’t let developers think Ops is exactly like Dev

21. Thanks!