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.
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. o 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. oAn 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 …
There is often confusion between the goals, authorities and roles of Change and Release Management. In fact, the objectives of each of process are very, very different. Change rules! Change Management is an authoritative process that governs anything that potentially impacts a new or existing service. It is both the enabler of innovation and protector of stability. It is first and foremost a risk management process. It is also a planning process. If Change Management is a governance process, Release Management is an action process. Under the authority of Change, Release builds, tests and releases new or updated services into the production environment. Every release is comprised of a single change or package of changes. Release Management is more technical than Change. If done well, both processes will avoid unnecessary levels of bureaucracy and will build a collection of change and release models that pre-define and pre-approve the rigor required based on levels of risk. The…
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
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
ITIL - is a best practice for IT service management
(ITSM) that focuses on aligning IT services with the needs …