How to Successfully Scale Agile and DevOps.

Welcome back to the blog series on “How to Successfully Scale Agile and DevOps”. In my first blogpost, I outlined the challenges faced by organizations as they attempt to scale up digitally and how the remedy lies in enacting change across multiple dimensions. The three key dimensions that require transformation for a successful outcome are People, Process, and Technology. I also mentioned the importance of Organization Change Management (OCM) in helping organizations fully enable the holistic changes needed to truly achieve successful outcomes from their scaling initiatives.

In this second part of the series, I will be discussing the People dimension and demonstrating how organizations can reboot and upgrade the “people element” within their Agile and DevOps teams to achieve greater capabilities at scale. So, let’s get started!

Cross-functional and Self-Organized Teams

Any organization that wants to scale Agile and Digital needs to orient its workforce to be self-organized and cross-functional. Self-organized teams possess unique skills and attributes brought together by a motivated group of people who possess the ability to make decisions and adapt to changing scenarios. Self-organized teams are able to take greater accountability of a feature or capability on any project and are constantly innovating. Cross functional teams are constituted of a group of people who are able tobring in all the skills required to collectively own a business feature or capability.

The best examples for self-organized teams can be found in the operating model of virtual teams who come together to play virtual games over the web. The best teams in this context are self-organized with no single leader. Each participant adapts to a servant or leadership role based on the skills needed to achieve the objective at any given point in time during the game. The switch-over of leadership is voluntary and it happens every few minutes.

Let’s assume a typical feature is being realized in a project through a simple three-tier architecture, the bare minimum roles that would be essential to create a cross-functional team are as follows:

• Product Owner: Business representative who is the Product Manager for the feature

• Analyst: Fulcrum between a Product Owner and the larger implementation team. In matured Agile teams, this role will cease to exist as the Product Owner matures to perform the duty of Analyst.

• Scrum Master: Self-organized Agile teams do not need one. But let’s take a typical scenario in today’s world where Scrum Master are still required. A good scrum master needs to cannibalize his/her role but that’s a topic for another blog.

• Developers: At least three developers, assuming we are working on a three-tier architecture.

• Support engineer: Since we are talking about a cross-functional team, this team is expected to support the business feature as well.

Now this is only a 7-member team – small and nimble and I am even suggesting that two of the roles (Analyst and Scrum Master) must eventually vanish for an even more agile transformation.

Do your Agile teams look like this?

A common complaint by enterprises in the Agile world is the potential risk of chaos that overwhelm an organization comprised of self-organized teams that want to do things on their own. So, while it is important to be self-organized to drive agility, it is equally important to drive Aligned Autonomy to prevent chaos while driving Digital and Agile at scale.  The subject of Aligned Autonomy is a critical component of the Process dimension of scaling digital and we will discuss it at length in a later blog post in this series.

But coming back to the importance of having a truly agile team, let me share a brief story. Not too long ago, I was asked to assess and analyze the problems being faced by a team, let’s call them Team Trooper, that claimed to be working on Agile for nearly two years, but were struggling to see any results. Their cycle times had stalled at a minimum of 12 weeks with no further progress on the ground. Naturally, business leaders had started questioning the effectiveness of Agile and were considering remedial measures. So I took on the ask and went in to meet the team. Walking into the room I was stunned to see nearly 25 people. According to the program manager this constituted a “cross-functional” team since they needed many people to deliver the feature. While there were multiple problems with the team, my first step was to get each team member’s competency evaluated to be a full-stack developer or T-shaped engineer

 The Elite – Full Stack Developers

Full-stack has become the buzzword in the industry. Everyone prides in calling themselves a full-stack engineer.In a recent interviewI conducted of a “full-stack engineer”, I asked him how he would create a web service in the language of his choice. His reply was: “In the Eclipse project you are working on, you need to go to Options à Create à Web Services, give a web service name with the parameters being asked for and click OK”. I am not an Eclipse expert and I don’t know if the Menu option he cited is correct but one thing I knew for sure is that this person cannot be a full-stack engineer.

My wife and I both come from a coding heritage, so it wasn’t uncommon for this topic to turn up in our dinner table conversations. Are we full-stack engineers or have we lost the sheen of being full-stack? Knowing the full extent of this term makes me feel thatthe software world has come full circle. When I used to code in C and later in JDK 1.2/1.3, I used to write front-end code (sometimes HTML or Javascript, and sometimes in GWT/Swing), middle layer code in Java, design the database, and write the queries or ORM mappings to interface with the data layer.

I used to be good at query optimization and could look at Oracle’s query plans and optimize my queries and table/index definitions for better performance. I used to write the build scripts, test my code, and get it deployed across all environments. Me and my friends in the team used to have our own internal competitions on whose code compiles first, number of first-time compilation errors, the code with zero defects etc. We took complete accountability for the feature we were working on.

However, over the past decade or more, the industry has begun focusing on creating specializations and made developers myopic in their focus. We now have Angular 4 developers who don’t know anything about middleware code, APIs, data handling mechanisms, simple SQL queries, build and deployment, testing and more importantly not even other UI frameworks. This has resulted in the need for more and more developers to realize a feature and has been the biggest obstacle in creating truly cross-functional Agile team.  That was one of the problem with Team Troopers. So, what is a full-stack developer or what makes a T-shaped engineer?For me, a T-Shaped engineer is one who depicts three types of skills: Technical, Engineering and Behavioral.

Technical skill: This skill is like a “T” which depicts the intersection between depth of knowledge in an area of expertise and the breadth of understanding across all adjacent technologies. This person has the ability to test their code and is also capable of being able to build and deploy their own code. For example, a full-stack UI engineer is one who brings in the depth of knowledge in JavaScript frameworks like Angular/React/Backbone etc., while also understanding and being capable of intermediate coding skills in all adjacent technologies namely Java/.NET, APIs, NoSQL databases or relational databases. They also have the ability to write not only unit tests but also functional tests in Selenium or another equivalent tool, possess the knowledge of static analyzers like JSLint/SONAR, and also have the ability to build and deploy the code leveraging GIT, CI tool and a deployment tool.

Engineering skill: This skill is often overlooked these days and is one of the major reasons for Agile teams not being able to drive velocity and faster release cycle times. It is the ability of a developer to bring in appropriate engineering practices during the implementation lifecycle. Working through a distributed version control system by following the Boy Scout’s rule, Pull Request rules, branching rules and discipline, daily code merges, daily builds, continuous deployment, following SOLID principles, writing code that passes the minimum checks in static analysis in the first run, following Clean Code principles, appropriate comments in GIT, regular updates in the asynchronous collaboration tools like Slack/MatterMost, and also making good use of Confluence/Wiki for project documentation etc. All these skills are critical to achieve velocity. In the book “Drive”, David Pink calls this attribute as Mastery and I have seen many organizations call this Craftsmanship. This skill cannot be learnt, it has to be practiced and practice makes a developer perfect to master the craft of engineering.

Behavioral skills: Cross-functional and self-organized teams are realized only if every person in an Agile team exhibits the appropriate behavioral skills. It is tough to define these traits as it depends on the culture within each team. Empathy towards others, servant-leadership, collaboration, trust and transparency are the basic necessary attributes. Many in the industry misconstrue this to be a bunch of outspoken developers. If you have listened to Susan Cain’s Power of Introverts TED talk, it becomes evident that 2/3^rd of the population is comprised of introverts. Thus, by having an incorrect expectation on the behavioral trait, enterprises end up losing the good full-stack engineers. Get the teams to decide if an individual is depicting the appropriate behavioral traits rather than an interview with a manager or an architect to make that decision. But to get an in-depth definition of behavioral skills, I have found the definition of skill competency levels in the DreyfusSkill Acquisition model to be useful and appropriate.

Framework for Scaling People: Dreyfus in a Diamond model and Team Configurations

Scaling Digital and Agile requires common team structures and configuration to achieve Aligned Autonomy and common cadence. Common structures need a common skill competency model on which people can be evaluated and mapped. If we do not manage to do this, we will end up having teams looking different and producing different velocities which does not augur well for an enterprise that endeavors to drive agility at scale.

It’s been a struggle in the industry to objectively define and adopta skill competency model for the software world. The technical skills are easy to categorize. It’s always the mapping of behavioral competencies that have been a problem and that’s where we have found Dreyfus model to be useful. You may read about this model in Wikipedia where it is well-explained. Some organizations have chosen to adopt the SFIA model which is also good.

We at HCL utilize the Dreyfus model as the lens through which we can objectively define people’s competencies across the three skills of technical, engineering and behavioral. And in line with the Dreyfus model, we map people to five levels of competency – Novice, Advanced Beginner, Competent, Proficient and Expert.

We are also moving away from the traditional pyramid model of structures of team competency mix to a more Diamond shaped model. There is enough research in the industry that states that Diamond models are productive and cost effective when we measure cost per unit of work (story points or functional points or complexity points).Does the Diamond model look alike across the organization? No. Based on our experience, we have realized that every application/product/platform goes through a 4-step evolution process namely: Ideation & Prototyping, Minimum Viable Product, Built at Scale, and Retire. The configuration of the diamond, we believe changes through this lifecycle as depicted in the diagram shared here.

Realizing thePeople Dimension for Driving Digital @ Scale

At HCL, we make use of a number of techniques to evaluate, on-board and upskill our engineers by evaluating them on the three skills of Technology, Engineering and Behavioral. Technology skill evaluation is mostly automated through the use of industry tools with some amount of pair programming thrown in for Competent or Proficient or Expert engineers. Engineering skill evaluation is also automated through our own proprietary home-grown tool. And behavioral skills are evaluated by getting engineers to participate in hackathons and through the constant evaluation of their ability to work in a team effectively.

One of the key benefits of having an institutionalized common competency model across the enterprise alongside an evaluation mechanism is that it can naturally become a career progression roadmap for people, helping them to take ownership of their own competency development. In this scenario, people are encouraged to upskill themselves by going through the evaluation cycle and proving themselves to have achieved the next competency level.

With the overall view of the above topics, any organization that wants to transform its people to drive digital at scale needs to take the following steps:

1. You need to define your own Dreyfus model framework, across technical skill, engineering skill, and behavioral traits that is contextual to your business.

2. You need to redefine your entire HR systems and their skill models to adapt to the Dreyfus model.

3. You need to adopt an objective evaluation methodology that is congruent to your model/framework.

4. You need to subject the entire enterprise to this evaluation process so as to reconfigure it to the standards of the new model you’ve defined.

5. Reconfigure people into skill levels.

6. Reconfigure teams into a specific diamond model based on the lifecycle of the feature

The process for transforming the People dimension within the organization can be a daunting exercise. But it is fast becoming an essential one that cannot be ignored.As every aspect of the enterprise becomes more digital, the challenges that come with it require the lifeblood of the organization i.e. its people to be prepared for the next generation of challenges and opportunities.

Organizations need to consider the above said models and define their framework based on their specific needs.They need to create the tools and mechanisms necessary to drive the evaluation of these models and examine their own enterprises against their chosen model. And finally, organizations need to take on the process of reconfiguring their structures and teams to follow the Diamond model of configuration for optimized velocity, growth and innovation.

By taking these steps, companies are guaranteed to benefit as they experience a more consistent structure across the organization and create a more consistent culture, where people exhibit the same behaviors and share the same engineering ethics and technology traits.This enables the organization to drive Autonomy, Craftsmanship, and Purpose among their cross-functional and self-organized teams.

So, all the very best in your endeavor to reconfigure the People dimension of Digital at Scale.In the next edition of this series, I will be discussing the Technology/Process dimension of scaling digital successfully.See you then!