Note: This is the culmination of years of work managing and optimizing the practice of technical operations groups/DevOps at scale. These are proven tactics and techniques that can be applied across any technical value delivery organization of any size to increase efficiency, satisfaction, and enterprise agility. While I had hoped to write a book on this eventually (see the outline for what that would have looked like), I do not have the time to do so, and yet these topics are extremely relevant especially as the cloud native revolution takes hold. This is not a replacement of DevOps, but instead the overarching framework that DevOps is a part of.

Agile Operations Implementation Overview:

HIGH LEVEL:

1. Start with We're all engineers -- begin culture shift toward a united engineering front, focus on infrastructure engineering, big teams are ok!
2. Buffer interrupts! Establish Persons of the Week, on-call rotation, direct monitoring and emails only to those who should do something about it, protect the team
3. Create a sustainable model for planned work (IDD - Infrastructure Driven Development), begin establishing engineering credibility with the business and customers
4. Build backlogs of planned work - business owners/dev customers/internal
5. Get a handle on the infrastructure from the Plan/Build/Run perspective
6. Manage, staff and grow as required

SPECIFICS:

1. align dev and ops resources either as a team or teams that participate on IDD projects, no organizational silos, establish engineering as the primary competency -- differentiate as an organization operations as an umbrella, but positions within it being engineering, support, administration, testing, etc.
2. create appropriate backlogs for: business projects (business planned work), interrupt tasks (PoTW), automation and self-service (for dev team customers)
3. make sure the PoTW triages absolutely everything (or perhaps the people manager or someone else as a buffer while getting this rolling) -- this will require a cultural change since everyone wants to jump in during a crisis. Also, if there is not a solid, lightweight incident management plan in place, this is the time to do it, and set expectations so it doesn't derail the whole team.
4. begin creating customer relationships with dev teams, discuss level of ownership and autonomy the group needs, SLA, escalation, and a plan to create sustainable patterns around the tech (ops can't do it all, so how is it going to get done? is the team on call? are common tasks automated or scripted? etc.)
5. Get an ops-oriented PO who is managing the various backlogs and acting as a liaison to the business and other POs
6. Get good at organization and make planning meetings very focused, standups based around the kanban boards for the initiatives
7. make sure self service and automation (SS&A) work is prioritized because it is a huge part of building trust and morale in ops, always allocate at least a pair to this at all times
8. build out the backlogs further and start seeing what velocity and % of interrupts are happening, and adjust staff as needed
9. begin integrating external devs into feature development, and begin the process of distributing information
10. maturity assessment of all technologies
11. Work toward 100% config management as part of SS&A, never build systems manually unless you absolutely have to
12. Work on increasing maturity of all core technologies -- many of these will be things that no one except ops "owns" so it is critical to distribute the support model along plan/build/run lines: architecture owns the upgrades & roadmap/replacement, engineering owns how to interface with it properly, operations owns how to maintain it/recover/replace/build it
13. From the people perspective, begin looking at career paths from front line support all the way to Infrastructure Manager/Architect, begin pushing tools, capabilities and knowledge lower and lower in the organization, many time support/IT are a huge untapped pool of talent just looking for a way to get more experience, make this happen!
14. If architecture is present in the org, infrastructure architect needs to be in the mix
15. Bring operations practices and expertise into engineering (and arch), and bring engineering best practices into ops.
16. Encourage everyone in ops to learn an object-oriented language such as Ruby, Go, Python, PHP or Java.
17. Ensure that a culture of mastery develops and that even juniors can be feature leads

IDD/FDD HIGH LEVEL:

Link to presentation on IDD

1. Just Enough Design Initially (JEDI) -- architectural planning and spikes necessary to complete the iteration (not feature) with minimal rework

2. Tackle the easy problems first

3. Assign a feature lead who will assemble the pairs necessary per iteration to estimate and complete the stories (may include customer developers!)

4. Runs like Scrum-Ban for the 2 week iterations

5. Prizes Agile principles like small batches, frequent delivery and active participation of customers in the process, PO manages this relationship

6. Teams are cross-functional and purpose-driven

7. Teams can become customers as well, meaning a IDD/FDD team may need an infrastructure feature in order to deliver, and this may constitute another team. We don't care who the customer is, necessarily, only that we treat them all the same and with the same level of care

INFRASTRUCTURE MATURITY:

Vector analysis:

Aggregate analysis:

AGILE ARCHITECTURE:

1. Focused on establishing patterns that increase engineering and operational agility
2. Provides a lowest-cost way of exploring new technologies through prototyping and research
3. Decentralized in practice
4. Center of mastery and mentoring for the organization
5. Ties organizational strategy to feasible solutions that meet business needs
6. Guild-building so architecture is egalitarian
7. Standards are only set where absolutely necessary -- patterns over proscription