Skip to main content

Skilling The Squad

Originally Published on the DevOps Institute Site

One of the most interesting trends in DevOps adoption is the evolution of the IT silo into the cross-skilled squad.

This is not just a semantical name change. Most IT teams today are comprised of like-skilled individuals such as a Scrum team of developers. The modern squad takes a slightly different approach, is more static than dynamic and is more product-focused than project based. Squads are built around T-shaped professionals –where each member has a specialty competency, but all members have a broad scope of skills across multiple disciplines.
A high performing squad essentially has all of the skills needed for the product or feature to which it is assigned and is not generally constrained by the availability of an individual resource. There is enough breadth of knowledge inside and outside the squad to shift more activities to the left so as to allow them to move more quickly and with more agility. While the squad model originated with Spotify, more and more enterprise organizations are starting to reorganize in favor of cross-functional squads.

The squad model is not only challenging the way that IT is organized, but it is also challenging the way we skill and certify IT professionals.

Historically most training and certification schemes were built as a hierarchy – starting with a basic “foundation” certification and eventually stepping up to a capstone designation such as an Expert or Master. Unfortunately, for most the journey starts and ends at the Foundation level. Statistically, only 10 to 20 percent of learners will actually be funded for or have the personnel need to achieve the capstone certification.
The other problem with generic certifications is that they do not clearly define what the recipient can actually do. While some certifications reflect documented roles such as Product Owners, Scrum Masters or Site Reliability Engineers, other designations are so ambiguous that a hiring manager or squad leader may not know exactly what skills they are hiring or how to use that resource. Would a sports organization build their squads around a group of people known as “Football Experts.” “Soccer Practitioners,” “Basketball Masters,” or “Baseball Professionals?” Of course not. Each member of a squad should be recruited based on the depth and breadth of their skillset and the competencies that that squad is lacking.
The DevOps Institute has responded to this challenge by creating a certification model that essentially “skills the squad.” The model is not hierarchical, it has inherent agility and is based on extensive research on the most critical and hireable skills needed for the modern T-shaped squad. At present, these include the best practices and principles around
As new skills emerge, we can adapt the model accordingly and help our Registered Education Partners deliver up-to-date content and certifications for a transforming market.
The hub of the DevOps Institute certification model is DevOps Foundation® – for which ITSM Academy is a proud lead author. This course offers the broadest and most comprehensive collection of current DevOps practices, principles and trends – many of which are not documented in a book and were born out of real-life enterprise innovation.
While skilling the squad with T-shaped competencies is an essential need for hiring and grooming the best talent, DevOps Institute also recognizes that organizational capabilities must evolve as well.  That is why we also offer a series of non-certification “DrillDown Courses” focusing on trending practices that have proven to be enablers of change and transformation. At present, these include
All of DevOps Institute’s content and certifications have been authored by some of the best and brightest thought leaders in their specific area.
Whether you call it a team or a squad, for now, one thing is clear – people are at the heart of every transformation. And upskilled, cross-skilled, talented people are the only way an organization is going to cross the digital divide. Skill the squad.
To learn more about ITSM Academy's DevOps and Agile Service Management classes: www.devopscampus.com.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…