As organizations increasingly rely on software to deliver business services, they are realizing that they need to excel at developing, deploying and operating software based products and services. But that isn’t easy – building and operating software systems has been and will continue to be one of the most complex human endeavours.
Agile and DevOps emerged as a set of management and technical practices to help teams and organizations manage the inherent complexity of software development. However, because Agile and DevOps emerged at different points in time, and in response to different challenges and because they have different manifestations, there is a natural tendency to treat them as mutually exclusive.
Agile’s genesis was the publication of agile manifesto twenty years ago, while DevOps movement began in 2009, triggered by the talk “10+ Deploys per day : Dev and Ops cooperation at Flickr” and the subsequent launch of DevOps days.
Agile emerged in response to the challenges of waterfall software development, while DevOps gathered steam with realization that technological innovation and the changing customer expectations – always on, always available software services – meant that it was both possible and increasingly necessary to get new features into the hands of users while maintaining operational stability.
Agile’s typical manifestations are product development and work management practices such as Scrum and Kanban, whereas DevOps is usually associated with tooling, automation and continuous delivery.
Given, these differences in timeline, the circumstances that lead to their emergence and their manifestations, it is natural to think Agile and DevOps are mutually exclusive practices that can be adopted and practised in isolation. The extreme yet surprisingly common manifestation of this thinking is the emergence of the antipattern of agile being considered as something that the development team does, and DevOps is something that release and operations teams do.
Needless to say this antipattern is counterproductive to the urgent business imperative of becoming better in the development, deployment and operations of software based product and services. So, instead of considering agile and DevOps as separate practices – they aren’t, they are two sides of the same coin – think of DevOps as agile for the digital age: where the definition of done for a product has shifted from being ready for release to the product being live in production, with the product team actively learning from its usage to further develop the product.
In the larger scheme of things, what you call the practices you adopt to become better at developing, deploying and operating software based products – agile, scrum, scaled agile, DevOps or something else – doesn’t matter. Labels matter less, what matters more is the ability of the product team to have the capabilities that allow it to develop, deliver and operate software based products and services that meet business demands and consumer expectations in the digital age.
Avoiding the semantics debate, we simply refer to digital age product teams as high performing product teams, and offer a learning and development path for product teams to become high performing product teams using DASA’s (DevOps Agile Skills Association) reference model. and its associated competence model.
DASA (DevOps Agile Skills Association) has comprehensively codified in the DASA DevOps competence model the four skills and eight knowledge areas that teams need to develop to become high performing product teams.
Enhancing the actionable guidance further, DASA has defined three work areas within a product team, and they are identified as work profiles. The work profiles are Specify and Verify, Enable and Scale and Create and Deliver. A high performing product team will collectively have a level of expertise (novice to expert) in the four skill and eight knowledge areas and through a process of continual learning aim to achieve mastery at a team level in all the areas.
We understand that becoming a high performing product team is a journey, so we have a development path uniquely tailored to a team’s requirement. It starts with DevOps fundamentals workshop (a two-day work shop delivered virtually). The two-day workshop provides a big picture view of the different skills and knowledge areas and how to tie them together to become a high performing product team. At the end of the workshop, each team member does a DASA DevOps Quick Scan, and gets a report on their maturity level in each of the knowledge and skill areas. Based on their work profiles team members upskill in the areas identified in the scan. When the individuals results are collated, the team has an understanding of its current state in each of these areas – Novice, Competent, Proficient, Expert, Master – and can then use the reference model to chart the learning and continuous improvement path to become a high performing product team.
In addition, the three roles of leader, coach and product owner provide the strategic guidance and leadership support to help product teams develop from their current level of competence to the desired level of competence as well as align product teams to achieve business outcomes. So, with the DASA competence model, the DASA reference model and the supporting training and certification program, we can help individuals and teams acquire the right mix of skills and knowledge, to become high performing product teams that excel in developing, deploying and operating software based products and services – an increasingly important business imperative.
PS: It doesn’t matter if you are a scrum or kanban shop, or have adopted an agile scaling framework such as Scaled Agile Framework (SAFE), Disciplined Agile (DA) or Large Scale Scrum (LeSS) or you have your own homegrown framework for scaling your teams, the DASA competence and reference model works in any of these situations. With its four skills areas, eight knowledge areas, three work profiles, three roles and the competence scan, you can understand your teams current competence and chart out a path to achieve the skills and knowledge your product teams will have to acquire to become high performing product teams.