E-Shaped Model for Organisation Agility

Organisations starting or in the middle of DevOps journey are familiar to T-Shaped model, the model which was popularized by IDEO chief executive Tim Brown.

T-shaped individuals have deep knowledge (the deep stem of the T) in at least one discipline or system, but also have a wide range of general knowledge of many disciplines and systems and a variety of boundary crossing competencies (the general top of the T).

This year our DevOps human has evolved to be E shaped. The trends clearly favor those with “breadth” and “depth”, as well as the tangible (execution) and intangible (exploration), implying having both a big-picture outlook and an attention to detail from being a practitioner. E-Shaped People have a combination of “4-E’s”: experience and expertise, exploration and execution. The last two traits, exploration and execution, are necessary in the current and future economy.

  1. There are three horizontal skill categories which comprise a specific set of capabilities: Automation skills, Functional knowledge and skills and Technical skills. These can vary depending on what the person is interested in, the individuals experience and abilities and are somewhat easy to train, develop and measure.
  2. A second grouping of skills, the categories of process and framework skills, is more of a vertical skill which focuses on flow and understanding the ins and outs of how things work leveraging a variety of best practices and methodologies like Scrum, Agile and Value Stream Mapping. These will need to be applied atop of the automation, functional and technical skills. Technology varies in its adoption and so do the technology skills as it depends on the technologies used and the plan for the organization, its current processes and methods used. This skill category requires some cognitive abilities, analytical thinking and innovation thinking to find and develop creative solutions for the complex world of DevOps.
  3. Another vertical skill category is the human skills which includes skills such as collaboration, interpersonal skills and more which are all necessary across all other skill categories. Unfortunately, human skills are not easy to train, upskill and measure. The experience and expertise come with time and upskilling; exploration is a fundamental of DevOps and execution is the simple proof of what a person has done applying his of her skills in terms of results.

Download the DevOps Institute Upskilling Report 2020 to get the comprehensive information on how Human DevOps Skills are evolving and the implementation in the organisations.

DevOpsDays and the History of DevOps

DevOpsDays is a worldwide series of technical conferences covering topics of software development, IT infrastructure operations, and the intersection between them. Each event is run by volunteers from the local area.

Most DevOpsDays events feature a combination of curated talks and self organised open space content. Topics often include automation, testing, security, and organizational culture.

History

The idea began in 2008 with a discussion between Patrick Debois and Andrew Clay Shafer concerning the concept of agile infrastructure. However, the idea only started to spread in 2009 with the advent of the first DevOpsDays event held in Belgium.

Want to know more? Watch the video below to know more on the History of DevOps and also DevOpsDays!

The Timeline

2007-2008: A Frustrated Belgian

Belgian consultant, project manager and agile practitioner Patrick Debois took on an assignment with a Belgian government ministry to help with data center migrations. In particular, his role was in certification/readiness testing. His duties required him to straddle activities and relationships between the application development teams and the operations teams (server, database network). His experiences—and frustrations over the walls of separation and lack of cohesion between application methods and infrastructure methods—planted seeds of discontent for Debois. His desire for a better way would soon lead him to action.

In 2008, at the Agile Conference in Toronto, Andrew Schafer posted an offer to moderate an ad hoc “Birds of a Feather” meeting to discuss the topic of “Agile Infrastructure.” Only one person showed up to discuss the topic: Patrick Debois. Their discussions and sharing of ideas with others advanced the concept of “agile systems administration.” In that same year, Debois and Shafer formed an Agile Systems Administrator group on Google, with limited success.

2009: The Case for Dev and Ops Cooperation

At the O’Reilly Velocity Conference, two Flickr employees—John Allspaw, senior vice president of technical operations, and Paul Hammond, director of engineering—gave a now-famous presentation titled, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The presentation had a dramatic flair to it, as Allspaw and Hammond would role-play the contentious interplay between representatives of  Development and Operations during a typical software deployment, along with all the finger-pointing/blame that goes on, such as, “It’s not my code, it’s your machines!” Their presentation made the case that the only rational way forward is for application development and operations activities to be seamless, transparent and fully integrated. Over time, this presentation has reached legendary status, and is historically viewed as the seminal moment in time for that called out to the IT industry for methods that we now know as DevOps.

Unable to attend in person, Debois watched the Allspaw/Hammond presentation by video stream. He was inspired, and—at the prompting of others through social media—formed his own conference called Devopsdays in Ghent, Belgium. By this point in time, the term “DevOps” had officially landed in the history books.

2010: DevOps in the United States

With a growing constituency, a Devopsdays conference is held for the first time in the United States in Mountain View, California, on the heels of the Velocity annual conference. Fast forward to 2018: There are more than 30 Devopsdays conferences already scheduled for 2018, including dozens across the United States.

2013: ‘The Phoenix Project’

For many of us, another noteworthy moment in the history of DevOps was the publishing of the book, “The Phoenix Project,” written by Gene Kim, Kevin Behr and George Spafford. This fictional novel tells the story of an IT manager thrust into a seemingly hopeless situation, as he’s charged with salvaging a mission-critical ecommerce development project that’s gone off the rails. His mysterious mentor, a board member steeped in the disciplines of lean manufacturing, guides the main character into new ways of thinking about IT and application development, introducing the concept of DevOps along the way.

Squad Health Check Model

This article is adopted from Squad Health Check Model in Spotify coined by Henrik Kniberg.

A lot of companies experiment with ways of measuring and visualizing how their teams are doing. They’re usually called “maturity models”, and involve some sort of progression through different levels, but in spotify they are using squad health check model. This article is based on this model.

The intent of these types of models is usually help teams become more self-aware so they can focus their improvement efforts.

How this squad health check model works

When checking the health of a squad, there’s really two stakeholders:

  1. The squad itself. While discussing the different health indicators, the squad builds up self-awareness about what’s working and what’s not. The broad selection of questions helps expand their perspective. Perhaps they were well aware of the code quality issues, but hadn’t really thought about the customer value perspective, or how fast they learn. It also provides a balanced perspective, showing the good stuff as well as the pain points.
  2. People supporting the squad. Managers and coaches that work outside (or partly outside) the squad get a high level summary of what’s working and what’s not. They can also see patterns across multiple squads.  If you have dozens of teams and can’t talk to everyone about everything, a visual summary like this helps you figure out how to spend your time, and who to talk to about what.

The first step in solving a problem is to be aware of it. And this type of visualization makes it harder for everyone to ignore the problem.

What we should do

  1. Run workshops where members of a squad discuss and assess their current situation based on a number of different perspectives (quality, fun, value, etc).
  2. Create a graphical summary of the result
  3. Use the data to help the squads improve

Here’s a real-life example of health check output for one tribe:

Squad health check model - example

It shows how 7 different squads in a tribe see their own situation. Color is current state (green = good, yellow = some problems, red = really bad). Arrow is the trend (is this generally improving or getting worse?).

Stare at it for a minute, and you start seeing some interesting things:

  • Scan each column, and you see some major differences between squads. Squad 4 is happy with just about everything. Squad 2 is having lots of trouble, but most things are improving.
  • Scan each row, and you see systemic patterns. Every squad is having fun (and it’s even improving)! Motivation is apparently not a problem at all. But the release process is problematic, and the codebase is overall in bad shape. Over time, that will probably reduce the Fun as well.
  • Scan the overall picture, and you see that just about every arrow is up, only two down arrow in the whole picture. That means the improvement process (the most important process of all) seems to be working.

This is, of course, just an approximation of reality (“all models are wrong, but some are useful” – George Box). So it’s worth double checking things before taking action.

Is Squad 4 really in such great shape, or are they just optimistic and not seeing their own problems? Most squads think they are delivering good value to their customers – but how do they know? Is that based on wishful thinking or real customer feedback?

In this particular case, squad 4 was actually formed just a week before the health check and they were definitely in the forming phase, or “on honeymoon”. So both squad 2 and squad 4 needed a lot of support.

“Easy to release” was clearly a major issue, so this led to a bigger focus on things like  continuous delivery, and we’ve seen some good progress there.

Note that this is a self-assessment model, all based on the honesty and subjective opinions of the people in the squads. So it only works in a high-trust environment, where people trust their managers and colleagues to act in their best interest. The data is easy to game, so the key is to make sure there is no incentive to do so.

To gather the data, we can use a physical deck of “Awesome Cards”, each card is one health indicator with an “Example of Awesome” and “Example of Crappy”.

Squad Health Check - Awesome Cards

(Download the cards as PDF or PPTX – thx Martin Österberg for designing the card layout)

The deck typically has around 10 cards, here is an example of a complete deck:

AreaExample of AwesomeExample of Crappy
Easy to releaseReleasing is simple, safe, painless & mostly automated.Releasing is risky, painful, lots of manual work, and takes forever.
Suitable processOur way of working fits us perfectlyOur way of working sucks
Tech quality (code base health)We’re proud of the quality of our code! It is clean, easy to read, and has great test coverage.Our code is a pile of dung, and technical debt is raging out of control
ValueWe deliver great stuff! We’re proud of it and our stakeholders are really happy.We deliver crap. We feel ashamed to deliver it. Our stakeholders hate us.
SpeedWe get stuff done really quickly.No waiting, no delays.We never seem to get done with anything.We keep getting stuck or interrupted. Stories keep getting stuck on dependencies
MissionWe know exactly why we are here, and we are really excited about itWe have no idea why we are here, there is no high level picture or focus. Our so-called mission is completely unclear and uninspiring.
FunWe love going to work, and have great fun working togetherBoooooooring.
LearningWe’re learning lots of interesting stuff all the time!We never have time to learn anything
SupportWe always get great support & help when we ask for it!We keep getting stuck because we can’t get the support & help that we ask for.
Pawns or playersWe are in control of our destiny! We decide what to build and how to build it.We are just pawns in a game of chess, with no influence over what we build or how we build it

For each question, the squad is asked to discuss if they are closer to “awesome” or closer to “crappy”, and we use basic workshop techniques (dot voting, etc) to help them reach consensus about which color to choose for that indicator, and what the trend is (stable, improving, or getting worse).

Squad Health Check workshop

We like keeping it at three levels (green/yellow/red) to keep it simple. The exact definition of the colors will vary, but something like this:

  • Green doesn’t necessarily mean things are perfect. It just means the squad is happy with this, and see no major need for improvement right now.
  • Yellow means there are some important problems that need addressing, but it’s not a disaster.
  • Red means this really sucks and needs to be improved.

Yes, this is subjective data. In theory the squad may choose to involve hard data (cycle time, defect count, velocity, etc), but few do so. Because, even with hard data, the squad needs to interpret the data and decide if it means we have a problem or not. So at the end of the day, everything is subjective anyway. If something feels like a problem, that in itself is a problem.

Sometimes we combine this with retrospectives, for example vote on one card and decide on actions to improve that area.

Try this squad health check model, and based on this, you can improve the model based on your preference. The most important thing is to ensure continuous improvement is facilitated and happened in the team.