A Practical Example of the Application of the DASA Team Competence Model
As anyone acquainted with DASA knows, the Team Competence Model defines the essential skills and capabilities needed in a DevOps team. In this article, I’d like to show the process I followed to apply it.
Before you start looking at the Team Competence Model, it’s important to familiarize & understand some of the most related DASA DevOps Principles. The first one os as Working in self-organized cross-functional teams (Principle #4) and the second one is Customer Centricity always focuses on delivering value to the customer (Principle #1).
To get to Self-Organized Cross-Functional Teams we first need to assess and analyze the current state of the Team. Only when this is done, we can try to improve the skills needed in the team (Principle #5) Not all teams need training on the same tools, frameworks, practices, or techniques. The DASA Team Competence Model provides guidance to individuals and teams on what needs to be addressed. By identifying the knowledge and skill gaps, the team can take the next steps towards high performance. DASA believes in the power of T-shaped team members. Not every team member needs to be an expert in a specific area, as long as you cover enough knowledge and practical experience in the team to manage the product life cycle.
The DASA Team Competence Model is organized around 4 skill areas and 8 knowledge areas:
- Skill Areas
- DevOps Leadership
- Continuous Improvement
- Knowledge Areas
- Architecture & Design
- Business Value Optimization
- Business Analysis
- Test Specification
- Continuous Delivery
- Security, Risk, Compliance
- Infrastructure Engineering
With these capabilities in mind, we can identify the improvement areas on the team level This is done according to the level achieved by each participant in each area (1. Novice, 2. Competent, 3. Proficient, 4. Expert, and 5. Master).
The following image shows how the multiple DASA certifications address different skill and knowledge area gaps.
How do you know what you don’t know?
DASA offers a free tool named the DevOps Competence Quickscan which allows professionals to visually assess their current DevOps “fingerprint”. All it takes is for users to answer 24 questions to immediately receive results.
The goal of this tool is to identify how professionals and teams can improve across the 12 knowledge and skill domains. The idea behind is to enable the teams to offer more valuable products, work better, share knowledge inside their team, and improve certain skills and/or knowledge.
This is exactly what I did in order to see whether my self-perception matched the results of the Quickscan. Although the results corresponded, to a large extent, with my expectations, I also found gaps that I had not suspected I had.
Because I didn’t take print screens back when I took the Quickscan, I’d like to provide you a hypothetical case. Say hi to Emma, an Infra Engineer starting her DevOps journey.
By the time Emma does the Quickscan, she is a master in three knowledge areas (Business Value Optimization, Continuous Improvement & Continuous Delivery). In addition to this, we can see she is a novice at ‘Architecture and Design’ and “only” competent at ‘Teambuilding’, ‘Business Analysis’, or ‘Test Specification’. These are areas for improvement.
You may be wondering at this point what this actually means in practice. Well, it’s now time to identify the next steps based on three levels: Individual, Team, and Company level.
At an individual level, Emma should improve fingerprint and get to level 2 on each domain. For instance, following a DASA DevOps Fundamentals program will bring her to that level. Being on Level 2 across the 12 domains builds the horizontal bar of the “T” – in T-shaped profile. At the team level, her results need to be compared with the remaining members of the team to identify the key improvement areas in need of improvement. DASA provides the following guidance to teams; as a team, you need to be a minimum Level 4 on all domains.
At the company level, a broader understanding of how skills and competencies are being met throughout the company. This is done by comparing the findings of its multiple teams.
How to Take it Further
I have used the DASA Team Competence Model in training as well as in projects with the purpose of assessing the status quo and initiating improvement processes. In most cases, I’ve found that people only have information at an individual level. This in itself, while useful, is quite limiting. DevOps should be above all, new ways of working at a collective level. Having no knowledge of the level of skills and knowledge of one’s team, department, or company-wide colleagues is far from desirable.
When everyone in a team carries out the Quickscan, we get something like the image above. This activity helps to create well-balanced teams as it is conducive to having people with different expertise sharing data, information, and knowledge during the product lifecycle.
Another situation where it is very useful to keep the DASA Team Competence Model at hand is when identifying the training needs of the individual, team, or company. Matching the areas with a learning path has helped me assist people in seeking training programs and further resources.
Imagine you have the following results:
If you share these results with your company, the most natural question to arise is something around the lines of: “Have we got any future products, projects, or initiatives that demand additional training?” If the response is positive, then they might very well start to consider a learning path consisting of a Foundational and Professional-level certification.
The impact of the DASA Team Competence Model as the go-to knowledge and skills framework for DevOps can not be overstated. It is no exaggeration when I say it became difficult for me to introduce DevOps to a stranger without mentioning DASA.
Regardless of how far down the DevOps journey road you are, it is always recommended to never lose sight of the DevOps Principles that sustain it. Doing the DASA Competence Quickscan and tracking my development throughout the years has been the best way for me to do this.