Teams are not constrained by how much they can learn. They are constrained by how much they are allowed to try, as well as by how much they don’t know what they don’t know.
When Agile adoption struggles in a large organization, it is almost always because managers are in the way—that is, teams are blocked by rules or upper level decisions—as well as because teams don’t know that there are better ways than what they are accustomed to doing. Those are the two predominant kinds of constraint on performance that one tends to see.
Rules exist for a reason: to manage risk. It is therefore unreasonable to expect that managers will just say “Do whatever you think is best”. To say that would be to abdicate their responsibility to manage risk for the organization. Doing that would also lead to chaos: each team would invent its own methods, and so the organization would cease to be one: it would devolve into a collection of tiny tribes.
If management were to ask teams, “What should we do?”—that would not solve the problem either. This is because teams often—more often than not, in my experience—do not know what a high performance situation could look like. Some might, if they have worked elsewhere, but even those individuals might have experienced some practices that work well in some places, but that might not make a-lot of difference in their current setting.
That is why one often needs someone who has seen DevOps and Agile in many different organizations, and who has been in a position to see the entire ecosystem and workstream. A good DevOps coach will have that experience.
DevOps looks very different from one organization to another. It looks one way at Amazon, a very different way at Netflix, and a very different way from either at Google. Core ideas are similar, but the way they are implemented depends on the setting. Thus, you cannot import practices directly from one place to another and expect them to solve the existing problems, and your goal should be to solve problems—not to mimic what others are doing: that is, not to “do DevOps”.
Envision the Leap
To get somewhere fast, you need to have a vision for where you are heading. The vision can change, but you need one to start, so that you can plan a path forward. So start with that: get together enough people who have shown interest, and who have authority or the ear of those with authority, and define a working vision. Then plan how to get there.
And don’t think in terms of “baby steps”.
Think in terms of the target—the vision—and write it down as a set of target practices. For each one, also write down why you want to do it; that is, what problem does it solve?
Experiments are okay—essential, actually. But “baby steps” implies that you are not fully committed. Transformation is hard, and to do it, you need a high level of commitment.
Baby steps also imply that you can only handle so much change at one time. It is true that one should not change too many things in an organization at once. But at a team level, I have never seen change constrained by how much teams can learn. I have helped teams to leapfrog from a DevOps “maturity” of beginner to all the way to the right of the maturity chart in one step change—taking usually a couple of months to institute the changes and attain a “stride”. All it took was some hands-on tool training, lots of discussions, getting rules overturned for them, and then mentoring.
When I have done this, what was required was support from senior management, so that I was able to get rules overturned, to—for example—allow teams to define their own feature branches, and allow them to define their own Jenkins jobs, and to allow them to use an experimental container cluster, and to get permission for them to make changes to their cluster deployment template, and to allow them to run VMs on their laptops, among many other things—all things that deviated from organization norms.
Connecting the dots
In the discussions about overturning the rules, I had to explain how risk would be managed. That is, I had to “connect the dots” for how DevOps practices work—that risk is managed through continual testing and feedback loops, and by defining a comprehensive testing strategy and managing test coverage for every class of tests.
The conversations also included putting an entirely new Behavior-Driven Development (BDD) oriented testing process in place, whereby testers were replaced with test programmers who were embedded in the team, and that people were allowed to swap roles—another change. These changes required conversations with senior management of QA and many others. Also, analysts—crucial for a BDD process—were given the same test tooling training, and one even surprised everyone by writing some test programs.
At no time did the team complain that too much had changed, or that they could not learn all these new things.
In fact, they demonstrated that we were not even close to the point at which they could not accept more change: after many sprints of development, we were told to change from one noSQL database to another—one that the team had no experience with. The change was made in one hour, by rewriting the Spring DAOs. Not one complaint was heard.
DevOps Is not “Advanced Agile”
Organizations sometimes make the mistake of thinking that they need to start with “basic Agile” and then move toward DevOps. Actually, I recommend starting with DevOps concepts, which are more foundational: (1) the idea of trying new approaches as “experiments”, (2) seeing the entire envision/dev/test/release process as a system, and (3) using feedback to manage risk—those are all cornerstones that Agile ideas can be layered onto.
There are also DevOps practices that make Agile work better. For example, BDD makes the Agile story implementation and test process work really well. It is not well accommodated by Scrum, however, so do not insist on Scrum: define the envision/dev/test/release process that you want, and define practices that enable that. Scrum might or might not fit.
Thus, instead of mindlessly adopting Scrum, consider each of the Scrum practices individually, and determine if each is a good fit. Also consider eXtreme Programming practices, and Lean practices, and DevOps practices. Use all of these ideas to assemble your vision and to decide what to try first. You might choose to start out with a pretty advanced set of practices—and that is okay!
One practice I highly recommend in all cases is to perform retrospectives; but I recommend that at least half of the retrospective discussion be about technical practices. Too often, retrospectives are led by non-technical Scrum Masters who tend to steer the conversation to the backlog management and “human” aspects, which are good things to talk about, but only if the technical practices are not treated as less important. Teams need to establish a habit of continually refining their technical practices, from the beginning.
Do Experiments, But Not as Baby Steps
At an organization level, baby steps make sense: one is talking about defining new standards. But I would prefer to frame those as experiments rather than baby steps. Thoughtful experiments: pilots, followed by broader advocacy and perhaps standardization.
I also would always think in terms of the vision, rather than in terms of some intermediate point. Intermediate points are sometimes a waste of time: one can go right to the final desired practice. Just do it as an experiment or pilot, involving a small number of teams; and don’t underestimate what a team can learn in a short time.