Golf and the DevOps 3RA

Last week, while on vacation in San Diego, I took a golf lesson from a veteran golf pro, Bob Madsen. For the record, I am not a good golfer. While I have swung a club at a white ball for many years, I have failed to improve during this time due to lack of dedicating myself to improvement (I have only taken a few lessons, and I don’t invest time in practicing regularly). In short, I am a hacker. I know how to golf, but I suck at the execution of the golf process.

During my lesson Bob and I were talking about improvement in golf, and what he was describing to me sounded an awful lot like how I think about improvement in delivering software, which leads me to believe that how to improve in DevOps and agility is not markedly different than how to improve in any skill, like golf. It begins with recognizing the barriers that are preventing or blocking improvement.

Barriers to Improvement

During my golf lesson Bob was describing to me the typical barriers that golfers hit as they attempt to improve and reduce their score from the in 100’s all the way to the low 70’s (also known as ‘scratch’). He drew a diagram that looked something like this.

Barriers

With this diagram Bob described these barriers that a golfer faces as they attempt to lower their score from the 100’s to the 90’s to the 80’s to the 70’s. The challenges they face at each barrier are different, and get more difficult to overcome at each stage (we spent our time talking about the 100’s to 90’s barriers if that tells you anything). Each barrier requires both different skills and overall improvement of existing skills in order to overcome it. In other words, “what got you here, won’t get you there.” Interestingly, regardless of the level of skill, golfers use basically the same tools throughout, although they learn how to use them better (foreshadowing of another analogy…perhaps).

3RA – DevOps Improvement

I started aligning this with how I think about software delivery and DevOps improvement. Like golfers trying to improve their game, organizations face different barriers at each stage as they attempt to improve in delivering software. I assert that there are four stages on a continuum of improvement that organizations spend time in as they build the skills to overcome the next barrier to their improvement. With that said, I don’t think an organization is in one stage one day, and then clicks over into the next stage. I think it is a slow penetration through the barrier into the next stage. Like my golf game, I won’t suddenly have consistent scores in the next lower score bracket (or stage) from one day to the next. Instead, I will see some success and some failure, hopefully improving the frequency of success until I am consistently performing in the next better stage.

Any skills improvement (whether it is my golf game or an organization’s approach to delivering software) advances progressively through a series of stages as the person or organization overcomes the barriers blocking them from improving. I call this the 3RA stages (pronounced ‘Era’)—Reactionary, Repeatable, Reliable, and Aspirational.

Barriers2DevOps

 

Reactionary

As the name implies, this state is demonstrated by a reactionary approach to the skill. The behaviors of the individual or organization are typically ad hoc and success is achieved mostly through luck. This state is often correlated with significant inter-team conflict and finger-pointing (or in the case of golf, lots of swearing and club throwing). For the record, this is where I am at in my golf skills. Like I said, I have been playing golf for years, but time alone doesn’t yield improvement. In fact, if you believe in the adage “Practice Makes Permanent” then the time I spent doing it the wrong way only makes improvement more difficult. In my case, I have never put in the time and effort to improve my skills enough to achieve anything that would resemble success. I simply keep doing the same dumb stuff I have always done and wonder why I’m not getting better. I have never scored below 100 because I continue to make the same mistakes in how I execute everything from the golf grip and swing to how I think about (or fail to think about) course management. In my case, I have the knowledge (I can describe the grip and swing), but I haven’t learned to successfully execute what I know repeatedly. I have met many organizations that deliver software like this—they may know what successful software delivery looks like, but they don’t know how to execute it and don’t put in the work to improve.

Repeatable

By deciding to focus on improvement though training and regular and consistent practice we can increase the frequency of success slowly and achieve a state of repeatability. For most this is a culture change that requires support at all levels (I better get my wife to support me in spending more time on golf). In this state individuals or organizations start to see some success based on the application of the skills they are developing, and not just as the result of good fortune. They aren’t perfect yet, but at least they can perform the same thing over again, such as swinging the golf club correctly most of the time, releasing software repeatedly without having to invent the release process each time, or implementing a change management process so that changes are handled the same way each time they arise. While the individual or organization can repeat these behaviors based on the skills they have developed, they fail to repeat the behaviors with the necessary regularity and still have more failures and fire drills than they would like. In the golf analogy this is my next goal—bogey golf. I am not trying to become a scratch golfer next—that would be an unreasonable expectation—I just want to lower my typical score into the 90s (my goal for this summer is to get a score in the 90s). In my case, I have begun the culture change (I have stakeholder agreement, now I have to commit to investing the time), I have the tools (TaylorMade clubs and balls, Adidas shoes, Nike clothes, etc.), and I have the core knowledge (I know how to swing the club), and now I must build my skill in execution through regular and consistent practice.

Reliable

As individuals or organizations continue to improve they next achieve a state of consistency where they are beginning to master the repeatable behaviors they have learned and they are executing them with the needed regularity. In other words, they are becoming reliable in their execution of their skills. When and if I ever achieve this state in golf will depend on the level of dedication I exert in building my skill. In this state I would swing the club and hit the ball reliably, making few mistakes in the execution (although occasional mistakes should still be tolerated), and would focus more and more on course management and good decision making to minimize risk. I would expect to par at least ten out of 18 holes, and bogey the rest. In other words, I would expect success most of the time, and minor issues some of the time. For organizations that achieve this state, the frequency of issues has decreased and the velocity at which they are able to deliver software is increasing. They are getting better at using data in their decision making and are therefore delivering products that their users have a higher level of satisfaction with. While they are consistent, there is still room to improve and deliver software faster and at a higher frequency to improve their business results.

Aspirational

The Aspirational state represents the ideal—a scratch golfer, maybe even a touring professional. This is a state that most of us mere mortals will likely never achieve, but some do and they can show us how it is done. For those few who get to this state, they make it look easy because they have invested the time and effort to build their skills to such a level of reliability success is nearly a given (although their definition of success has likely evolved to something that is difficult for us normal folk to understand). Regardless of whether we are talking about golf or delivering software, the Aspirational state is one that we may continue to strive for knowing we may never fully achieve it (I doubt I will ever be a touring pro golfer, but I am sure that I will always want to improve). For organizations, the Aspirational state is one where true transparency and collaboration enable them to deliver software to production as often as they want, including multiple times per day if they choose. The Aspirational state is one that only a few organizations will fully achieve (some may not even desire to achieve this state), but this will remain the ideal that is referenced when discussing the value of DevOps.

Great, So What’s Next?

I am only scratching the surface here. In any effort to improve skills, whether in golf or in software delivery, it is important to gauge where you are so you can identify what is next. Just like I shouldn’t focus on trying to get par on every (or any) hole, you shouldn’t try to deliver software faster than is reasonable without building up to it. Knowing where you are starting from is important.

There is  a lot under the surface of the 3RA Framework that I will share with you in some upcoming posts. For now take the time to internalize the four stages—Reactionary, Repeatable, Reliable and Aspirational. Understanding the differences I have described is important in learning how to assess where you are and what you should focus on next.

Scaling Agile Across the Enterprise

Earlier this week we, the Developer Division at Microsoft,release a series of short videos telling the story of how we made the transformation from our old waterfallian ways to a scaled agile way of working.

Here is where you can find all of the videos.

This is the story of a division of 3,000+ engineers who had been following a well defined waterfall approach for years, even as we were advocating Agile and all of its virtues. In truth, we weren’t the hypocrites that statement indicts us as. In fact, we had small agile teams popping up all throughout the division for years. In true agile fashion, the momentum grew as more and more small teams saw the value in Agile. We had many small agile teams working within a waterfall framework. As the momentum grew we decided to make a change.

I love the was Soma (S. Somasegar, our Corporate VP) puts it when he talks about how he made a decision about Agile. He says the decision he made was not to implement Agile, it was top not stop teams from trying Agile.

Soma

As our business needs changed and the need for our release velocity to increase, Agile gained more momentum, until a few years ago when the momentum had grown enough that we decided to formalize Agile across the division. That meant getting the entire division onto the same sprint schedule (we have 3-weeks sprints, and all teams start and stop sprints on the same day). Over time we moved into a new building that was designed with Agile teams in mind (team rooms, focus rooms, etc.).

3weeks

Today we are on sprint #66 and we have had countless releases since we began this transformation, including releases of Visual Studio Online every three-weeks, and internal releases of the Visual Studio clients, to several public releases of Visual Studio (2012, 2013) and related updates.

cadence

I encourage you to check out the video series (rather than have me retell it here). There is some great insight shared by my peers and me, and lots of footage of how we work, where we work, and what we do.

Here are links to the individual videos in the series.

History

Everything we do around development — collaboration, testing, and customer feedback — has changed.

Brian

Waterfall vs. Agile

Today, we think about how fast we can translate an idea into reality, and get it into customers’ hands.

Gregg

Visual Studio Transition

We needed to work more incrementally, deliver to customers faster, and let feedback make the product better.

Julia

The Agile Shift

We didn’t decide we were going to be agile starting tomorrow. There was gradual buy-in with teams and leadership.

d7

Physical Transformation

We moved out of our individual offices, and put teams together into the same room.

TeamRooms

The New Normal

We need to make sure we’re hearing our customers, and learning from them as we’re building the software.

debt

Employee Response

We’ll talk about what’s working and what’s not working… the idea is continuous improvement.

Peter

Measuring Success

We need to know that what we’re building scales for software teams around the world.

Aaron

Takeaways

Your software development efforts have to aid your business. That’s why they are there.

PeterAaron