7

Adding DevOps practices to a single development team is a relatively simple proposition as it usually comes down to introducing either people to the team to build up a DevOps, Release Engineering or Platform Engineering capability within an organisation.

Organization Structure

Some of the pitfalls organisations are trying to avoid are:

  • Inability to report progress consistently across multiple development teams, for example, if one team reports their progress in terms of the number of equally sized stories completed in 2 weeks; whereas another team reports in storypoints completed in a three-week sprint.
  • Inconsistent application of a practice means team members can not easily move between teams within the same organisation without learning new ways of working.
  • Mismatches in development cadence across multiple teams makes coordinating dependent releases difficult.

What can be employed to achieve this in a consistent manner in an organisation that has a large number of development teams, potentially in multiple separate business units?

Improve this question
5
  • Of course! Fire away.
    – Richard Slater
    Commented Mar 25, 2017 at 16:45
  • @Pierre.Vriens thanks for the feedback, any better? I would encourage you to post an answer to the question if you believe that what you have experienced or propose supports a DevOps Culture.
    – Richard Slater
    Commented Mar 25, 2017 at 17:47
  • SAFe and DAD are quite explicit about what and how you implemented it, LeSS is not as explicit in nature as it is essentially just a way to scale Scrum. I can probably tune the question though to be more "What" than "How".
    – Richard Slater
    Commented Mar 25, 2017 at 18:15
  • Up to you (what fits best for you). I'll hold off a bit before eventually posting my answer I have in mind. That should leave you some room/flexibility for your Q and A. Because once another answer comes in, you cannot change your question anymore in ways that would invalidate any of the existing answers (according to the rules of SE sites, which "I" did not invent ...). PS: sorry for being such tough QA-reader (constructive intended critique, remember?).
    – Pierre.Vriens ♦
    Commented Mar 25, 2017 at 18:21
  • So sad I can't share my department organization change presentation :/ I May try to summarize it, but I'm unsure what I can or can not tell yet.
    – Tensibai
    Commented Mar 27, 2017 at 8:01

3 Answers 3

Reset to default
6

Large enterprises will commonly adopt a delivery framework, or operating model, that has been built to support large enterprises. From an Agile/DevOps perspective, which is my area of expertise there are three frameworks of interest:

  • Scaled Agile Framework (SAFe®) defines DevOps as delivering business value through the successful operation of software in an environment. This is achieved by giving early attention to the act of "moving into production" and accomplished, in part, by integrating personnel from the operations function within the Agile Teams.

  • Disciplined Agile 2.X, also known as DAD, defines DevOps as "DevOps is the streamlining of the activities surrounding IT solution development and IT operations." this is achieved by building feedback loops between the development and operations functions within the business. DAD goes on to describe Disciplined DevOps as the intersection between the following roles: Enterprise Architecture, IT Operations, Business Operations, Release Management, Data Management and Development.

  • Large Scaled Scrum does not specifically call out DevOps, Release Engineering or Platform Engineering; however, it does describe a methodology for scaling out Scrum in an organisation that is growing fast, integrating a DevOps specialism within these teams is both logical and well understood.

As far as I am aware there are no statistical data about the enterprise adoption of each of these frameworks and whether they have adopted DevOps practices in addition to Agile practices, however from experience many organisations appear to gravitate towards Scaled Agile Framework.

Kristof Horvath discusses the application of DevOps in these enterprise-grade agile frameworks in his article: Scaling Agile in Large Enterprises: LeSS, DAD or SAFe®?.

It is worth noting that adopting an "enterprise-grade" framework is not a requirement in an enterprise, at the end of the day Agile, DevOps and Lean are about adopting the right practices for your organisation, not the most popular ones.

Improve this answer
2

None of the issues you present appear to be DevOps-specific to me.

Some of the pitfalls organisations are trying to avoid are:

  • Inability to report progress consistently across multiple development teams, for example, if one team reports their progress in terms of the number of equally sized stories completed in 2 weeks; whereas another team reports in storypoints completed in a three-week sprint.

This is a problem any company with multiple development teams, or multiple teams of any sort that share a common functionality, will face. The simplest answer is to move them all onto a shared cycle.

  • Inconsistent application of a practice means team members can not easily move between teams within the same organisation without learning new ways of working.

Again, not a problem specific to DevOps. As with developer teams, you need to increase visibility into other teams and introduce standards to keep people in sync.

  • Mismatches in development cadence across multiple teams makes coordinating dependent releases difficult.

Once again, not DevOps-specific, but a classic problem of business that comes from far before electronic computers. Reduce dependencies and make it clear when they happen that they are happening, and the effects of slippage, and keep all affected parties informed of schedule changes.

Improve this answer
2

Inability to report progress consistently across multiple development teams, for example, if one team reports their progress in terms of the number of equally sized stories completed in 2 weeks; whereas another team reports in storypoints completed in a three-week sprint.

Inconsistent application of a practice means team members can not easily move between teams within the same organisation without learning new ways of working.

I view this as both a failure to standardize process across teams and a management problem if people aren't sticking to process. Individual teams should be flexible in terms of how they manage their people, but processes should be transparent and followed.

Imagine a fast-food chain restaurant. Each restaurant may re-organize things a bit according to the architecture of their specific location, to best suit their needs. However, the general components and the ingredients and the intended SLAs for delivery will be the same. An employee should be easily able to transfer between any location with some minor re-orientation.

Challenges faced by each 'location' means you may need to regularly re-visit the overall strategy, and you should be 'trying things out' in various teams and regularly rolling those changes back into the overall process. Process is just like software delivery, too.

Mismatches in development cadence across multiple teams makes coordinating dependent releases difficult.

Again, need authoritative control and agreement between teams... a corporate brand with many locations, not a food court of different franchises.

Etsy has their famous example of 'schema change thursday', where they allow non-contract-breaking-changes to be deployed as often as needed, but anything that will require coordinated change between systems happens on a specific day every week.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.