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…
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…