Prague University of Economics and Business Faculty of Informatics and Statistics
TRANSFORMATION OF IT SERVICES IN ŠKODA AUTO DIGILAB AND DHL INFORMATION SERVICES EUROPE THROUGH APPLICATION OF SCALED
AGILE FRAMEWORKS MASTER THESIS
Study programme: Applied Informatics
Field of study: Information Systems Management (ISM)
Author: Olesia Lacko
Supervisor: Professor Ing. Alena Buchalcevova, Ph.D.
Prague, May 2021
Declaration
I hereby declare that I am the sole author of the thesis entitled “Transformation of IT Services in Škoda Auto Digilab and DHL Information Services Europe Through Application of Scaled Agile Frameworks “. I duly identified all citations. The used literature and sources are stated in the attached list of references.
Prague 26 April 2021 Signature: Olesia Lacko
Acknowledgement
I wish to express my sincere gratitude to my thesis supervisor Professor Ing. Alena Buchalcevova for providing me with all the necessary facilities, comments, and engagement for this thesis.
I place on record my sincere thanks to all interviewees from Škoda Auto Digilab and DHL Information Services Europe, for their cooperation and for providing all necessary information during out interviews, and for the time that they dedicated to me during this hard COVID-19 situation.
I am also grateful to my loved ones, who supported me through the whole process of writing this thesis. I wish to thank my parents for their support during this journey that reflected my knowledge, skill set and experience.
Last, but not least, I express my gratitude to all faculty members of Applied Informatics, ISM in VSE for providing help, advice and facilities to accomplish my degree.
This master thesis is dedicated to the memory of my grandfather who passed away and who insisted on taking the next step in my degree and career.
Abstract
The growing popularity of scaled agile frameworks across all sizes of organisations is the trend that businesses are attempting to emulate today. Agility was used around the globe across all markets and businesses to speed up the pace of deploying solutions and products and improve team accountability. Being agile became a standard in the IT world, and scaled agile frameworks totally changed our perspective in terms of delivering human-centric solutions rather than just finished products. However, when it comes to the adoption of scaled agile frameworks in larger organizations, the transition has yet to occur. It is much easier when you have up to a hundred rather than up to hundreds of thousands of employees. Anything boils down to paperwork, legacy, processes, and the organizational climate itself-all of which are major constraints to corporate agility.
On the market, there are a plethora of scaled agile practices and methodologies. Both small and large companies are attempting to migrate their IT services and processes fully or partly. There are two major sections of the thesis. The first section of the thesis is linked to chapter one, which is devoted to the theoretical part and concentrated on revealing the core concepts underlying some of the most popular in terms of adaptation among large organisations frameworks, such as SAFe, LeSS, DAD, and Nexus. After reading this section, you would have enough academic background to be able to critically assess and evaluate interviews and opinions from leading large firms about scaled agile systems. Each of the scaled agile frameworks that have been chosen and listed above will be evaluated in terms of historical context, production process, project management, and development cycles.
Each subchapter dedicated to one of the chosen frameworks will also discuss its advantages and disadvantages. The second section of the master thesis focuses on the introduction of the two companies selected for this thesis: Skoda Auto DigiLab and DHL IT Services. In Chapters two, three, and four, the chosen organizations will be analysed in terms of organizational and operational structure, as well as the interview process and comparison.
These chapters include a thorough examination of the qualitative interviews conducted to discover the feasibility of implementing scaled agile frameworks in such large and global companies as Skoda Auto DigiLab and DHL IT Services. The final chapter concludes the current thesis by recapping the findings of the completed interviews and by addressing the main thesis question - “Is it possible to apply agile methodologies and practices in large- scale projects and organizations; and if so, then what is the required process of transformation of IT services?".
Keywords
Agile, Agile application, DAD, IT, LeSS, Nexus, SAFe, Scaled agile frameworks, Scaling Agile, Transformation of IT Services, Waterfall
Content
Introduction ... 9
Objectives and methodology ... 10
Expected Contribution ... 11
Literature Review ... 11
Internet Sources ... 12
Professional Publications ... 12
Books ... 13
1. Scaled Agile Frameworks ... 14
1.1 Scaled agile frameworks definition and history ... 14
1.2 SAFe – core values and principles ... 15
1.2.1 SAFe – outlined benefits and drawbacks ... 25
1.3 LeSS – core values and principles ... 26
1.3.1 LeSS – outlined benefits and drawbacks ... 32
1.4 Disciplined Agile Delivery (DAD) – core values and principles ... 33
1.4.1 DAD – benefits and drawbacks ... 40
1.5 Nexus – core values and principles ... 40
1.5.1 Nexus – benefits and drawbacks ... 42
2 Interview Design and Conduction ... 44
2.1 Interviews Design ... 44
2.2 Conducting Interviews ... 46
3 Impacts of scaled agile frameworks adoption in ŠKODA AUTO DigiLab ... 48
3.1 Company Context ... 48
3.2 Organisational structure ... 48
3.3 Interviews Conduction and Analysis ... 50
3.4 Improvement Analysis and Conclusion ... 56
4 Impacts of scaled agile frameworks adoption in DHL IT Services ... 59
4.1 Company Context ... 59
4.2 Organisational structure ... 59
4.3 Interviews Conduction and Analysis ... 61
4.4 Improvement Analysis and Conclusion ... 68
5 Conclusions ... 72
List of references ... 76
Annexes ... I
Annex A: Interview 1 [DHL IT Services, Project Manager] ... I
Annex B: Interview 2 [DHL IT Services, Application Specialist] ... III
Annex C: Interview 3 [DHL, Senior Project Manager] ... VI
Annex D: Interview 4 [ŠKODA AUTO DigiLab, Android Platform Lead] ... VIII
Annex E: Interview 5 [ŠKODA AUTO DigiLab, Project Manager] ... X
List of abbreviations
AD Agile Data
AM Agile Modelling
APMO Agile Program Management Office ART Agile Release Train
CoPs Communities of Practice CI Continuous Integration COVID-19 Coronavirus Disease DAD Disciplined Agile Delivery DEV Development
FIS Faculty of Informatics and Statistics HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure LACE Lean Agile Centre of Excellence LeSS Large-Scale Scrum Framework PBF Product Backlog Refinement RTEs Release Train Engineers SAFe Scaled Agile Frameworks TDD Test-Driven Development UAT User Acceptance Testing UP United Process
XP Extreme Programming
Introduction
My choice to write the Thesis about the transformation of IT services through the application of Scaled Agile Frameworks was supported by my professional experience in operational and project management in the IT industry. After spending my last four years working as an IT Project Coordinator for financial and pharmaceutical clients, where I had to follow the agile framework, organize sprint calls and drive team spirit with short sprints, I understood that there is a big difference of applying scaled agile frameworks in small- and large-scale organisations. I am a part of medium size company, however, I started to wonder how agile methodologies and frameworks could be potentially applied in a corporate environment that is by its definition stand against almost everything agile is about. It requires an enormous shift in terms of the company’s culture, resource allocation, “team- thinking”, and much more.
Today we keep hearing “go agile”, “do you have any experience leading agile teams”,
“contract negotiation or continuous collaboration with customer”, etc. Scaled Agile Frameworks are well-known methodologies in the IT world when it comes to the choice of approach companies are going to follow in a team’s development and leadership. These frameworks shifted our perspective of thinking about the project – around 20-30 years ago it was completely normal to have projects that last years; on the other hand, now, we take it as a sign of failure or inadequate management. We came to scaled agile frameworks because the nature of old waterfall models outlives its’ usefulness. Imagine, you are working on the development of the application for a pharmaceutical client, and each stage of UAT and DEV is taking months to be completed. You have to stick to initial requirements, and you cannot go to market with an unfinished product. But the world around you is changing, it’s not waiting for you to go live with the product. Thus, some features your client approved already need another support (like moving from HTTP to HTTPS). And this is what will cause in past another wave of submitting and signing the contract, bringing alongside another year of development.
Meanwhile, in scaled agile framework this situation should never take a place, since over processes, tools, comprehensive documentation and plans, agile values fast delivery, respond to change and collaboration/iteration with a customer. Application of scaled agile frameworks is allowing a business to bring more transparency over the process; continuous team engagement and enhancement of customer experience; that also brings alongside the quality & quantity boost. It is no doubt that companies nowadays want to follow agile
frameworks since it helps them to keep track of the fast-moving environmental changes and gives a help-hand to manage them. The benefits of applying scaled agile frameworks are remarkable, however, if we are talking about large scale organizations then the overall integration becomes much harder and costly.
In this Thesis, I try to uncover and identify the effects of the application of scaled agile frameworks on IT Services in large enterprises based on the experience of ŠKODA AUTO DigiLab and DHL Information Services Europe.
Objectives and methodology
The main goal of this master thesis is to identify the effects of the application of scaled agile frameworks on IT Services in large enterprises based on the experience of ŠKODA AUTO DigiLab and DHL Information Services Europe. In the theoretical part of this master thesis following literature review and case studies, I will review the scaled agile frameworks to gain a general understanding of different approaches and terminology with a help of literature review and case studies. Afterwards, I will research to determine the relationship between scaled agile frameworks and IT services, which will serve as a great basis for interview preparation for ŠKODA AUTO DigiLab and DHL Information Services Europe.
The objective of the practical part is to run personal interviews/discussions with IT managers and application specialists from ŠKODA AUTO DigiLab and DHL Information Services Europe in order to:
a. Identify the effects of applied scaled agile frameworks on continuous development and improvement of IT services and processes.
b. Compare and outline the unique benefits of applied scaled agile frameworks in large scale organisations.
c. Uncover the potential drawbacks of applying scaled agile frameworks in larger-scale enterprises.
d. To critical evaluate the use of scaled agile frameworks in both selected enterprises.
e. To recommend improvements for the usage of scaled agile frameworks in the selected large-scale enterprises.
The overall objective of this master thesis is to uncover the real process and drawbacks of applying scaled agile frameworks in large organisations based on the combination of quantitative and qualitative research methods. I will strive to understand the impacts of
scaled agile frameworks on IT Services management and development in a large-scale organisation.
Expected Contribution
This thesis will be valuable for large companies who would like to apply agile frameworks to enhance company’s IT Services performance.
This thesis will be beneficial for general audience who wants to get knowledge about different scaled agile frameworks.
This thesis could be beneficial for small to medium business that will have an opportunity to forecast their transformation based on practical examples.
This thesis will uncover different agile frameworks and compare their scaling approaches based on real-case scenarios in large companies such as ŠKODA AUTO Digi Lab and DHL IT Services.
This thesis theoretical part will bring benefits to scientists, professors, educators by covering general common knowledge about agile frameworks and application.
This thesis will be beneficial for managers and decision makers since it will provide a know- how approach to enhance company’s services and products through applied agile frameworks.
Literature Review
This sub-chapter focuses on an overview of different sources of information that were used during the formation of the current master thesis. In most cases, professional publications and academic works were used in the English language. No foreign literature or/and translation was used to write this master thesis. The following online libraries were used during the research sources gathering ProQuest, DOAJ (Directory of Open Access Journals), VSE online library, books, other scientific journals and internet sources specified below in the current sub-chapter.
Internet Sources
One of the most important online resources for this master thesis is the documentation of the “SAFe” on its own official web https://www.scaledagileframework.com/ (Scaled Agile Inc., 2021). This website has full documentation and an overview of a roadmap to implement different layers of SAFe in various size organisations. It provides case studies, images, videos and plain text information that forms the basis of understanding SAFe and its integration. On this website, there is also a Blog section, where Scaled Agile Inc., posts updates and interesting videos/interviews/facts about SAFe.
The second most important online resource for this master thesis is the documentation of the “LeSS” – https://less.works/ (The LeSS Company B.V., 2021). This website has full documentation and overview of principles, structure and LeSS rules organisation need to follow to integrate and promote this framework. One of the most important sections of this source is the “Case Studies” tab where they have stored all case studies of applying LeSS framework in various size organizations. Such companies as BMW Group, Huawei, JP Morgan are presented among others in the case studies section.
Another important internet source that was used during the research process is “Medium”
- https://medium.com/ (Medium Corporation, 2021). It is an open-source American platform where authors and companies around the world can share their content, thoughts about certain topics. For this thesis, I was using only company verified profiles and scientific publications from this “open-source platform”. It helped to broaden the perspective of the integration of SAFe in various size organisations alongside agile drawbacks and benefits.
Professional Publications
While writing this master thesis, I decided to give preference to scientific journals and articles, rather than a previously written thesis on the current problem. By using ProQuest and VSE Online Library, I have managed to find several verified journal publications that covered different topics reviewed in the current master thesis.
One of the sources is the article "My Scaled Scrum: Integrating Mega Framework and DAD" published in Advanced Networking and Applications (Radwan, M. A., Farid, A. B., &
Nasr, M. M.,2016). This article talks about a tendency to move from traditional software development to agile one. It also uncovers one of the main controversial topics of integration of agile methods in large organizations/projects/teams. The authors of the current article suggested the hybrid approach that large scale organizations should follow to eliminate drawbacks and problems that will come alongside the integration of agile methodologies.
Another important source for “DAD” framework is online publication by IBM corporation in the PDF format (Ambler, S., & Lines, M., 2011). This is the introductory PDF written by the founders of DAD framework that is describing the way framework operates, rules, guides and principles. The whole publication was taken as the main source and basis for the DAD framework subchapter of the current thesis.
Books
Among other sources, several books with online access were used as one of the major sources and foundations of the current master thesis. “Agile software architecture:
Aligning agile processes and software architectures”, written by Babar, M. A., Brown, A.
W., & Mistrik, I., contains fundamental information we need to know about agile architectures. This book gives an entertaining practical overview based on the real project scenarios where managers can see how various changes can bring different decisions on the flow. It uncovers the failures and success of projects and provides real-life examples that professionals from the industry can easily put into their lives.
Another electronically obtained book is the major source for DAD framework chapter of the current master thesis – “Disciplined agile delivery; a practitioner's guide to agile software delivery in the enterprise”, written by Scott W. Ambler, Mark Lines. Disciplined Agile Delivery is what is called a hybrid approach that combines various agile methods and practices. I promote this book among others since authors are giving major attention to people as the key sources to successful agile development and implementation. In case a team is built effectively, and collaboration is promoted, then everyone is going to work together as a whole unit to hit the organizational objectives.
1. Scaled Agile Frameworks
In Chapter One of the current thesis, you will be introduced to the following agile frameworks: SAFe, LeSS, DAD, and Nexus. Each of them is going to be discussed separately in the devoted sub-chapters with the primary focus on a general framework overview; history of growth; the reason why organizations selecting these frameworks. The potential drawback and benefits of applying each of the selected above frameworks will be also discussed in the separate sub-chapters. Every selected framework will be discussed from both small and large organization's point of view to see if any agile framework can be scalable for possible adoption in the corporate environment.
1.1 Scaled agile frameworks definition and history
We are living in the fast-developing world, where digitalisation and globalisation are the main two trends around which everything is moving. Companies were and are always trying to find a way how to be faster, smarter and deliver higher quality services and/or products than competitors to their customers. The agile approach became a high trend due to its core values and principles laying in fast delivery through incremental work-to-be-done management. By following the agile approach companies started to deliver results faster with fewer mistakes due to continuous testing and enhancement during the development process.
Yet, even despite its popularity, large enterprises could not scale it effectively since in their structure there is more than one team working on the same service or/and product. When we are talking about enterprise, we are not thinking just about scaling agile across cross- functional teams; but we also have to think about scaling it up to numerous departments.
Here it’s becoming complex to handle, and this was one of the main reasons why agile got its popularity at first among small to medium companies. Since the problem was recognised, several frameworks were developed to help large enterprises to adopt and scale agile inside their teams and departments.
Nowadays we can differentiate among numerous agile frameworks that are aimed to help corporations to scale agile inside their organization. Such as Spotify, Nexus, Scrum at Scale, LeSS, SAFe, DA, and so on. All mentioned frameworks are aimed to help organizations to scale agile principles; by scaling it is either meant to make a team more successful in the delivery of the results; or to resolve problems related to coordination/management in cross- functional teams.
For this master thesis, it was decided to choose the following frameworks and to give them review from the perspective of core values, principles, drawbacks and application example:
SAFe, LeSS, DA and Nexus.
1.2 SAFe – core values and principles
The Scaled Agile Framework (SAFe) is an agile framework for teams oriented to development that is standing on three pillars: Team, Program, and Portfolio. It's like a set of workflow patterns and best practices that will help an organisation to incorporate agile practices. It was first introduced in 2011 (Wilson, 2020), and referred to as "Agile Enterprise Big Picture". SAFe's creator - Dean Leffingwell - before introducing his methodology to the corporate world had to work a lot with his team to enhance the enterprise knowledge base and best practices.
According to KPMG report and the 14th Annual State of Agile Report, we can see that SAFe is holding its place of the most favourable framework to go with when implementing Agile frameworks (Digital,2020; KPMG,2020). The primary goal behind this framework is to give stakeholders or/and product managers a high-level view aka “big picture” over the whole process from governance to development and customers rolled out versions. SAFe was developed primarily to help enterprise organizations to implement and after scale agile inside cross-functional teams.
SAFe became a top choice for enterprises not just due to its core values and principles that are going to be covered in the next subchapter of the current diploma thesis, but also due to its educational value for teams and leaders. This framework gives valuable knowledge on agile transformation, principles and methods – and only by understanding agile from the bottom to the top, management can lead and inspire, and the team can work accordingly without questioning the selected approach (KPMG, 2020). Enterprise-level organizations are very complex in terms of team’ building and cross-functional / cross-level departments.
SAFe is the framework that was formed to help complex migrations to agile by enabling cross-functional portfolio-level collaboration between numbers of departments. By adopting agile methodologies with SAFe an enterprise achieves a high-level visibility over all processes following agility and scaling.
The whole process starts with the primarily step - a transformation of enterprise into a lean one. Lean enterprise is all about eliminating insufficient and useless processes by focusing on value creation through the perspective of consumers (Kenton, 2020). Nonetheless, even during this step, your enterprise will have to have enough competencies and knowledge to
not only transform itself to being lean, but also to change its culture, way of thinking, and way of working and delivering results. It's like we are working on developing a new model of BMW - this one will have better power, motor, visual appearance; thus, it will require a different level of engineering behind. Same with SAFe transformation - it's not enough just to apply the framework, you have to change the way of operations to adopt it efficiently and successfully.
As it can be seen on the Figure 1 below, SAFe 5.0 framework has seven core principles that allow organization to enable agility and focus on execution together with development. In the previous version of SAFe we were talking about five core principles, however due to changing environment the new SAFe framework incorporated another lens that will help enterprise to adopt and scale agility among cross-functional teams and departments.
Figure 1
Scaled Agile Inc. (2019, November 5). The SAFe Big Picture [Digital image]. Retrieved December 2, 2020, from https://www.scaledagileframework.com/wp-
content/uploads/2019/09/SAFe-for-Lean-Enterprises_F02_WEB-2.png
The first principle is “The Lean-Agile Leadership”, where leaders and managers can learn how by empowering teams and individual players, they can enhance their potential and delivery results. This is more about learning by example or learning-model, what makes sense, since those who are in management positions have to be the first people in the
organization who would change their way of thinking and operational performance, so others can learn from them. Any change management process is hard operationally and
“mentally” for organizations, this is why it’s important to make sure that those who are leading this change have enough knowledge, understanding of the change; so, they are able to actively empower their teams to follow the new flow. Leaders in SAFe framework empower respect to people, innovation and quality among the quantity. They constantly focus on relevant planning and briefing; transparency over the processes; quality of the work, and smart resource planning. All these activities initially have one goal – to protect team members or/and individuals from feeling overburnt; to increase their motivation to grow and move forward, and to deliver high-quality results to the customer. It’s all about setting the “right mindset”, and it cannot be done without an understanding of how this new mindset should be lead. This is why one of the first and one of the core principles of SAFe lays in Lean-Agile Leadership.
Moving on to the second principle of SAFe – “Continuous Learning Culture”, it has to be said that this principle is about changing the organization’ mindset, not only management or/and teams. This stage or principle is rather about being continuously hungry for learning and increasing knowledge to bring innovative approaches to operations.
The organization has to become a learning one with a commitment to the promotion of innovation and continuous improvement among all its’ members. Today it is not enough only to deliver results faster than your competitors; those delivered results also have to be according to current trends and standards. Adaptation of continuous learning culture in organizations requires a contestant improvement and adjustments of techniques, mental models, group thinking, and work-to-be-done approaches. All of these requires a certain fund of investments that organizations would dedicate to their employees. This promotes not only learning culture but also provides an intrinsic motivation boost to employees.
There are different ways of how organisations can promote a continuous learning culture, and they are not particularly monetary ones. For instance, by following one of the core agile practices – sharing vision and knowledge – we can enhance learning and knowledge sharing among agile teams. The second principle of SAFe guarantees that enterprise organizations who are focusing and investing their resources and time into learning would see a long-term benefit through a flexible innovative agile team.
The third core value is called “Team and Technical Agility”. During the SAFe’
implementation roadmap after we make sure that our management and leaders know how to manage the change, it’s time to make sure that the team itself will be able to delivery solution accordingly with the new principles and customers’ needs. As it can be seen from
Figure 2 below, there are three main dimensions according to SAFe that will secure team and technical agility (Team and Technical Agility, 2020):
• Agile Teams – that are led by the scrum master and product owner to continuously deliver high results incorporating the agile principles.
• Team of Agile Teams – this one is relevant particular to a corporate environment with thousands of employees and numbers of cross-functional teams. Here, following the SAFe’ ART1, a team of agile teams by sharing the same vision deliver the desired and outlined solution.
• Built-In-Quality – same as with leaders, here all teams should run their operations according to agile principles and practices with an aim to delivery high quality solution.
Figure 2
Scaled Agile Inc. (2019, September 24). The three dimensions of team and technical agility [Digital image]. Retrieved December 2, 2020, from
1 ART (Agile Release Train) – when a team of Agile teams following the incremental approach develops and continuously delivers one or more solution (Agile Release Train, 2020).
https://www.scaledagileframework.com/wp-content/uploads/2019/09/Keystone-TTA- WEB-1.png
When we are talking about agile teams in SAFe, we usually have in mind a team up to 11 people who can function independently from their scrum master/leader/manager with the whole spectrum of responsibility to deliver their work frequently in a small batch to speed up the feedback and further the release process. The agile cross-functional team can be independent during the process because of the essential skills each individual has to deliver the project/product successfully. Following ARTs, agile teams are able to align together to achieve the common goal by having a necessary skill to create the best solution. The third SAFe core principle opens up doors to a completely different level of teams’ operations – although, we all know that hierarchical approach is great and proven to provide corporates with results; speed and quality of delivery sometimes are lacking a lot. With lower pressure and more freedom, this core principle helps leaders and organizations to open themselves to innovations, fasten delivery, and empower and motivate team members.
After we aligned the team, management, and learning culture, it’s time to move on to the fourth core component – “Agile Product Delivery”. SAFe is a customer-centric framework, thus here everything from the definition to release is built based on a customer- centric approach. SAFe principles lay in fast delivery; however, it is very easy to lose a track of delivering a product or a service that is relevant to customer’s needs and requirements.
This is where Agile Product Delivery principle plays the main role. We have to make sure that what we are working on can be considered as the right solution for our customer; and that we can deliver it on the right agreed time. According to SAFe, it can be done by following three main dimensions of Agile Product Delivery, see also Figure 3 (Agile Product Delivery, 2020):
Figure 3
Scaled Agile Inc. (2020, April 06). Three dimensions of agile product delivery [Digital image]. Retrieved December 2, 2020, from
https://www.scaledagileframework.com/wp-content/uploads/2020/04/Keystone- APD-web-new-2.png
• Customer Centricity and Design Thinking – this is something that today we don’t see only in SAFe framework; it is something that already became a trend or a new mindset – to bring customer to the centre and surround your organizational’
activities to create a positive interaction with customer and to allow your customer to have an engaging and positive experience with your service/product. Design thinking is a process that helps to ensure customer’ needs and interests during the process design stages. It helps to make sure that what we are working on is really something our customer requires/needs. This pillar is more about understanding what our customer wants and then making sure that we did not forget about it during
the process realisation (Berea, 2020).
• Develop on Cadence, Release on Demand – as it was already discussed above, SAFe framework is built on the principle of developing and delivering by iterations.
Scrum master or product leader should put a standalone length per each iteration so agile teams know exactly by when and what is expected from them. In case we are working on a larger project/product then we can use Program Increments to merge a set of iterations and organize them into ART for delivering. Following this logic,
we are developing continuously based on the transparent and visible high-level pipeline; so, in case there will be a business inquiry, we will be able to release and deliver in the shortest time possible. Nevertheless, as an agile enterprise, we have to delivery not only based on the request, but also according to the current demand.
What is logically providing us with an opportunity to obtain a leading market position, depending on how fast and precise our response to a customer will be.
Apart from taking the leading market’ position, we also can win loyalty from customers by giving them what is currently trending; and allowing them to be fancy
and trendy.
• DevOps and the Continuous Delivery Pipeline – to be able to guarantee and/or develop the continuous delivery pipeline there is a need to align development and operations. In the agile team’s delivery cycles are fast and there is a crucial need to eliminate the gap between two worlds – business and IT or as they called in SAFe – DevOps. The SAFe framework promotes DevOps based on five core principles (Berea, 2020):
o Culture of shared responsibility among all team member from product manager to testers, developers, operation officers, etc.
o Automation of continuous delivery pipeline to remove or partially eliminate human intervention during the release processes.
o A lean flow that is followed by imitating the work in process so we can delivery to the customer faster.
o Measurement of everything by quantifying everything that can be quantified.
o Recovery to enable low-risk releases and fast-track potential bug fixing in a live environment.
Basing our product delivery on the described above pillars allow enterprises to create the right solutions based on customer’s requirements and to deliver them upon agreed schedule and time range.
The fifth SAFe competency is “Enterprise Solution Delivery” – that will guide organizations in applying, managing and developing the world’s famous and largest networks, software applications, and cyber-physical systems (SAFe for Lean Enterprises, 2020). It is no secret that building a large enterprise solution requires enormously high resources and efforts with more than thousands of people working on them. There is also a high probability that one system or/and application are going to be built by separate vendors/suppliers. Meaning, that there is a need to align multinational teams. Each team is
potentially located in different countries, thus regulations and compliance should be controlled and monitored closely. As it can be already seen, this process won’t be successful without a sophisticated system in-placed. SAFe frameworks address the development and delivery of such an enterprise system based on three key principles (Enterprise Solution Delivery, 2020):
• Lean System and Solution Engineering – achieved by applying lean-agile practices over a spectrum of activities: design, test, evolve, develop, architect, etc.
• Coordinating Trains and Suppliers – achieved by coordinating different suppliers to achieve a shared goal. Here the best strategy according to an agile approach is to visualise through roadmaps and create synchronization points so
everyone stays on the same page.
• Continually Evolve Live Systems – same as in everything described above, we have to make sure that our delivery is continuous, and the delivery pipeline supports it.
The SAFe framework allows teams who are working on the development and release of world’ largest software’s to stay more flexible and reduce risks of information loop communication during the release due to agile approach and transparency over the whole bunch of processes.
Moving towards the sixth core competency of the SAFe framework, we are going to cover
“Lean Portfolio Management”. Traditionally, portfolio management was not designed to support digital innovations and economic trends. This is where its’ replacement, Lean- Agile-Approach-to-Portfolio-Management is coming to the scene. The new approach to portfolio management stands on the main three dimensions (Lean Portfolio Management, 2020):
• Strategy and Investment Funding – this dimension is more about the collaboration between enterprise executives, business owners and enterprise architect to ensure that the entire portfolio is covering all business needs and targets. The main target here is to connect the portfolio to the company’s strategy, align its vision and realise them through epics; establish budgets, controls and
portfolio flow.
• Agile Portfolio Operations – here APMO/LACE cooperate with RTE and SM CoP to support the execution excellence. Following the agile methodology, we are
going to constantly enhance the efficiency of portfolio’ operations.
• Lean Governance – business owners, enterprise architect and APMO communicate here to align on questions of spending (forecasting expenses), measurement (quantifying metrics), and compliance & audit. In agile we are not talking about classic “years-ahead” budgeting; we rather forecast and plan more fluid and aligned with increments/cadence.
Ten years ago, it was hard to forecast and quantify metrics; nowadays, it’s even more difficult. However, to ensure continuous delivery, centric-customer development and agile teams, we have to have right strategy for investments and funding. The sixth SAFe principle is going to help organizations to strategically manage their finances and to allocate their budget strategies to enhance organizational performance and support business agility.
The last SAFe’ competency core principle – Organizational Agility – is about how fast we can respond not as a team, but as an organization to market changes, customers’
requirements and digitalisation. Business terminology, processes, values – everything was developed long time ago and unfortunately, the majority of principles are not corresponding to the current era we are living in. At this time there was a need to control so the organization can generate stable profits and results. However, nowadays to generate the same, organizations need to be agile and delivery results fast. Organization agility can be achieved by following (Organizational Agility, 2020):
• Lean-thinking people and agile teams – we have to make sure that everyone who participates in the delivery of the solution is adequately trained and has knowledge in Lean and Agile practices and methods so he/she can promote practices among the process delivery. It is not only about development, operations and finances; but it is also about people, marketing, and legal. It’s about all processes in the enterprise. We are starting always with adopting agile in teams, following the first core competences of SAFe. Here our mindsets, values and operations are changing completely to be able to mirror agile methodology principles and practices.
To be able to control and continuously deliver an effective solution, agile teams are joining an agile release train where they are synchronized and share the main vision – to delivery quickly with highest possible quality.
• Lean business operations – by applying lean principles teams are going to map and continuously improve delivery and support processes. Following this methodology, developers need to understand the value of the solution they are
working on from operational perspective, so they can deliver what customer wants;
and, on the other hand, operation management should be on the same stage as development teams and make sure that roadmaps and vision maps are in-placed.
• Strategy agility – by achieving an ideal state, when the enterprise can quickly react to market changes whenever it is necessary through being agile. It’s more about how well enterprise can sense the market need and conditions to be able to react quickly to current changes and trends. We can sense market only based on some research;
data analysis; and feedback from customers. After we conduct some research and we are able to “feel the market”, we can test if our hypothesis were correct or not.
One of they how we can test is called MVP – minimum viable product – that will secure budgeting and reduce risks connected with investment into something innovative. The strategy is not just about the market forecasting and responding; it’s also about change management processes and brining innovation to departments that are historically standalone ones (ex. Accounting).
To sum up seven core competencies of SAFe, it can be said that adopting SAFe will give an enterprise a possibility to agile business not only from the perspective of product delivery and team management but rather from the agility of the organization itself. Since SAFe is largely implemented framework, it has different configurations that could meet the needs of different size organizations (SAFe for Lean Enterprises, 2020):
1. Full SAFe – the most extensive set up that includes all seven pillars described above. Usually, this configuration is used by large enterprises that need a complex solution for their portfolio management with more than 100+ people.
2. Portfolio SAFe – as per its name this is the limited configuration that will help the enterprise to adopt agility principles over portfolio management and operations.
This solution will be suitable for an enterprise that requires a moderate number of
agile teams.
3. Large Solution SAFe – can be implemented by enterprise where during the solution building there is no need for portfolio levels. Usually adopted by organizations who are working on scaling the development of large solutions.
4. Essential SAFe – the most basic configuration from all mentioned above; it is used by enterprises when there is just a clear need to adopt agile, but not a clear
understanding on from where to start. Here the starting point is clear and there is always a possibility to move to a bigger configuration package.
To conclude, SAFe framework is holding its leading place on the market among other competitors when it comes to teams and organizations agility. It has proven results, case studies and is suitable for the largest enterprise. This framework is constantly modified and updates to stay relevant to current market trends and changes. SAFe provides not only a guide on how to adopt agile methodology in the enterprise, but it also serves as an educational platform to give the required knowledge to run agile organizations.
1.2.1 SAFe – outlined benefits and drawbacks
After understanding SAFe core values and principles, we can critically evaluate its benefits and drawbacks compared to its competitors. This framework was initially developed to help development teams to deliver higher quality products to market as fast as possible. One of the benefits of adopting SAFe in an enterprise organization is transparency over the processes or ability to see the big picture. When we are talking about the multinational corporation and teams there is a lack of visibility and centralised communication among departments and teams. This is where SAFe will be beneficial since according to its centralised approach and transparency over the processes, it will eliminate information loop and potential misunderstanding.
Another advantage of SAFe lays in being a customer-centric methodology – sometimes during the product run, we forgot what actual customer’s requirements we had and when we were supposed to deliver the product. Especially when we are talking about large enterprises where cross-functional teams from different organizations and countries are working on one product release. SAFe through clean roadmap and shared responsibility &
knowledge approach creates a stable vision that everyone is following to achieve the outlined at the beginning of the process goal.
The third advantage that needs to be outlined lays in supportive forums and documentation of SAFe developers. They do provide up to date, constantly renewal documentation that is helping those who are working with this framework on a daily basis.
The final advantage I would like to outline is connected with encouraging continuous delivery and integration. What brings not only operational excellence on the table through higher ROI, lowering human resource costs; but also increases integrity over workflow since we have a guarantee that task will always be performed in the same manner. There are certain repetitive tasks that enterprises can do hundreds of times per day, and there is a
need to eliminate mistake/bug. Through continuous delivery and integration, enterprises can secure its performance and enhance team capacity.
Despite holding leading positions among agile adopted frameworks, SAFe as any other software or/and methodology had received criticism. According to Norville, although, SAFe promotes agility, it restricts developers and cut their freedom by implementing additional layers of controls and approvals (Norville, 2020). It’s basically distancing developers from the decision-making process, what can potentially prolong the release since it’s not given that product manager or scrum master will have enough skills to implement the decision without interactions with development teams.
Another disadvantage of SAFe lays in its main advantage – continuous learning and development. According to SAFe main competencies, leaders/managers have to be the one who promotes framework’ knowledge and principles among organizations. But since SAFe is developing and changing constantly, you as a manager or a leader will have to continuously work on new skills and renewal of your certifications. Sometimes this can create pressure since there is not always enough time for self-education and learning experience. However, without this SAFe is a very inefficient framework, since it has a lot of heavy terminologies that you won’t be able to proceed without basic knowledge and orientation after passing needed certifications.
In conclusion, it can be said that to adopt this framework enterprise needs to make sure that it understands and do not underestimate the implementation roadmap process and further workflow. Due to SAFe complexity and scalability up to the largest enterprises, there is a long adopting cycle, meaning that logically there should be no way back to where we started.
It’s a long way that enterprise agrees to follow to adopt agility principles. There also should be enough resources to cover training of at least management and stakeholders, so they can promote knowledge and culture among teams and organization. Apart from one-time fee, enterprises also have to count with renewal; so, there is no lack of knowledge due to constantly enhancing framework. Due to SAFe’s market position, it’s obvious that benefits outweighed drawbacks, however there is still a room for improvement in terms of agility (moving completely away from waterfall approach).
1.3 LeSS – core values and principles
Agile is about stepping back from the documentation and focusing more on teams and the project itself. It’s about fast delivery and hitting the goals as effective and efficient as possible. However, what happens if we are working on a large-scale project where we need
to pass the information, documentation and requests from one internal department to another? We have to interact with the business inside the business, rather than just the development team and the customer. This is where the idea of the LeSS framework came.
LeSS is a simple Agile framework that helps managers and organisation to apply and go agile, having multiple teams working simultaneously on large scale projects. The LeSS framework stands among others due to its flexibility and adaptability to different team size.
According to LeSS official website, this framework can be defined as a “scrum applied to many teams working together on one product.” (The LeSS Company B.V, 2021). Since this framework takes scrum as its basis, it’s better to introduce the scrum concept first. Scrum is another framework developed for project managers to emphasize transparency, adaption and inspection. It simply helps teams work together to achieve the common project goal and to deliver the project successfully. Scrum provides project managers with a set of tools, meetings and roles for teams to structure project and work accordingly. As other frameworks focused on agile mindset, scrum’ main goal is to utilise agile principles by focusing on sustain delivery of projects with different complexity. LeSS’ creators took scrum as a basis and developed a framework that is scaling scrum across multiple teams that are working together on the project. Following other scaled agile frameworks, LeSS’ main priority is also to reduce the complexity and waste of time during the product/project delivery.
Craig and Bas, founders of the LeSS, from 2002 were working on developing the framework that will allow now only small teams to follow scrum and agile mindset in large scale projects (The LeSS Company B.V, 2021). They have developed now only one framework, but actually, two different frameworks that organisations, depending on the team size, can adopt in different project domains – smaller LeSS and LeSS Huge. Smaller LeSS framework according to founders can be used in smaller teams of up to 8 people; then there is a need to transform and apply the second LeSS Huge framework. The logic behind the transition is that the single Product Owner simply cannot guarantee the quality and delivery of the entire product since the product backlog becomes too large to scale and work with. At first, we are going to look into the small LeSS framework principles and summary.
Figure 4
The LeSS Company B.V. (2021). LeSS Framework [Digital image]. Retrieved April 10, 2021, from https://less.works/img/framework/less-framework.png
A smaller LeSS framework is used for teams of up to eight people. This framework is designed for only one product owner who is overseeing the product backlog that his/her team is working on. The crucial aspect of this framework is rooted in the agile mindset – a cross-functional full-stack team that works together in a shared environment to create and finish assigned items. To maintain transparency and ongoing delivery, LeSS implements sprints that have to be attended by all teams participated in the project. The product owner and/or product leader should prepare for the sprint and outline major items to line up on the table during the sprint meeting. They have to assign priorities and dependencies and explain why they believe that it’s the right order. Then each item is divided between the teams and they are working separately and together during the product backlog on them.
The product owner here has to make sure that each team is choosing items not only based on their interests, but also according to their strengths and best abilities. Scrum Master, though, has to make sure that a single team won’t end up having a bunch of high priority items, so the project goes evenly, and the risks are under control. There is always a need to distribute power accordingly. As a result of the first sprint, each team has their priority items to create spring backlogs and track the progress till the next sprint.
Figure 5
The LeSS Company B.V. (2021). LeSS Sprint Planning [Digital image]. Retrieved April 10, 2021, from https://less.works/img/framework/less-framework.png
As can be seen on the Figure 5 above, after the first sprint there is a clear picture of teams and items they are holding. It may occur that multiple teams are holding very related to each other items. In this case, following small LeSS framework, these teams are going to run the second sprint meeting to go over common tasks to uncover the shared work to be done.
Following this session teams are eliminating misunderstanding and overlapping work so as a result on the next sprint no one will come up doing the same thing over the product backlog.
After the sprint planning stage, teams start to work towards developing assigned items. As it was mentioned above, the key here is a shared code environment, which again created transparency and visibility over the progress and helps teams and leaders/managers to keep up with changes. Every day during the project lifecycle teams hold the sprint meetings till the end of the project/deployment. As it can be seen from the flow of small LeSS, this framework/approach is based on the daily iterations and sprint meetings to connect different teams that are working on different items to deploy the final product. Due to Product Backlog Refinement (PBF), there is a possibility to split bigger items into larger
parts and estimate risks and duration for the whole butch based on each part. Multi-team PBR is an original side of the LeSS framework since it requires multiple teams to gather in the same room to run a big workshop to split big items and clarify them in more details so the product owner can create real estimations and evaluate associated risks accordingly.
All these seem to be great and scalable, but it’s hard to imagine how to scale smaller LeSS if you work in a project where you manage, for instance, twenty different teams at once. This is where Craig and Bas came with a framework “LeSS Huge”, that supports the division of the teams around the requirements areas (areas of the major customer’ concern). Example of “requirements areas” can be described as following (The LeSS Company B.V, 2021):
- Imagine your product is a “Trading Platform”.
- Then customer clarifies that his main areas of interest or as we call them in LeSS Huge “requirement areas” are:
o Trade Process.
o Asset Division Process.
o Deploying to new African Market.
o Deploying to new Asian Market.
After defining these requirement areas, we have to add them to the product backlog. For instance, following the example from above, we can create multiple Area Product Backlogs like “deploying to Market A” and “deploying to Market B” and different teams can focus on these backlogs. However, it doesn’t mean that after separation into different areas each area will be held in a separate sprint window. Quite opposite, in the LeSS Huge we have one produce-level sprint to help to maintain continuous integration and development. Since we have a new component, requirement areas, then a new role is introduced – Area Product Owner. If we recall agile, it’s like a team leader that is assigned and focuses on its Area Product Backlog. And since we have different areas, it’s only logical if we will have different Area Feature Teams that will be assigned to one Requirement Area. Following the introduced example earlier, the team in LeSS Huge could be summarised as follows:
- Product Owner.
- Product Owner Team:
o Four Area Product Owners.
- Four feature teams in area A.
- Four feature teams in area B.
- Six feature teams in are C.
Figure 6
The LeSS Company B.V. (2021). LeSS Huge Framework [Digital image]. Retrieved April 10, 2021, from https://less.works/img/less-huge/less-huge-framework.png
All other processes are the same as in the smaller LeSS framework. Both frameworks are sharing the same process for one product backlog, same statuses (done, ready, pending), one product owner, one sprint. However, due to the new Requirement Area in Less Huge, there is a need for new roles as described above, such as area product owners, area feature teams. And this brings area product backlogs, which creates a need for parallel meetings attached to the Area to ensure continuous team integration and project delivery. To finish the LeSS overview, it’s good to mention the main principles this framework is based on (The LeSS Company B.V., 2021):
1. Large-Scale Scrum – LeSS is not redesigning the Scrum, it simply applies the principles of scrum in the context of large-scale organisation.
2. Empirical process control – to create transparency and share the control over the processes, product and design, the LeSS stands for the situational approach of adopting the Scrum rather than following a book-stand approach.
3. Transparency – LeSS stands for short development interactions that help to focus on the timeline and “done’ items bringing teams together to work on the common goals.
4. More with less – LeSS stands for learning without diving deep into the process definition; wasting fewer resources by lean thinking; sharing ownership with less division by roles or/and artefacts.
5. Whole-product focus – LeSS main requirement is to have one product backlog, one product owner, one sprint and one product increment – following this framework we are focusing on delivering the whole product rather than parts of it.
6. Customer-centric – customer’s feedback and interaction both play a huge role in the LeSS framework.
7. Continuous improvement towards perfection – sprint meetings and continuous improvement to product/project create higher perfection in terms of delivering customer-centric product.
8. System thinking – LeSS stands for overseeing and optimising the whole system rather than parts of it. Here it’s again more about putting “doers” in the “customer’s shoes” – they pay for the result, not for the steps that brought the result.
9. Lean thinking – supports managers in “leading and teaching” rather than
“controlling and dividing”. Everyone respects each other.
10. Queuing theory – prioritising the right item at the right time and putting the right team for efficient and effective delivery.
Keeping in mind the main principles LeSS stands for, and comparing it to earlier described SAFe, we can see that both of them share the same principles of continuous improvement, development in small iterations, sharing risks and responsibility among the team, and customer-centric process of delivery of a solution. LeSS, in comparison with SAFe, though, simplifies the roles what makes it a less complex framework to apply. I would say that in terms of preparation and learning needed for successful adoption of the framework, LeSS Huge or LeSS Small are both winning over the SAFe, which definitely requires courses and training before adoption.
1.3.1 LeSS – outlined benefits and drawbacks
According to the subchapter above, we can say that the fundamental focus of the LeSS framework is to apply principles it stands for to multiple teams that are going to work together with a common goal of delivering a complete customer-centric solution. In the following paragraph, I am going to outline the benefits of LeSS as a framework by own and compared it to previously discussed frameworks.
Due to simplified ownership and having only one product owner there is a higher understanding of the framework and principles what then helps to shorten the gap between IT and the business world. Following the same principles of having fewer roles than for instance in SAFe, LeSS brings the opportunity to deliver the product having more scattered resources and overhead costs. We have also discussed that in larger organisations we can
apply LeSS Huge that introduces the new term “Requirement Area”. With help of areas, the product owner can have a bird-view over the entire product (and in case it’s a big product, then this view even enlarges to the area of focus dashboard). LeSS is also stepping back from the “old-school” model where only project owners and stakeholders talk with customers. In the LeSS framework teams have the power to be in direct contact with both the customer and the stakeholder. This helps to shorten the gap and misunderstanding in requirements and speed up the delivery. Due to focusing on the product itself rather than the project or team, LeSS is known for higher-performing product deliveries and customer satisfaction. Applying LeSS is also known to be a “comfortable way of going agile”, due to its Scrum roots. Companies, in general, do not have to invest in onboarding as much as in applying SAFe. Overall, as it can be seen from the above, LeSS is a comfortable and easier way to go agile if you have multiple teams and a higher organisation structure. It values the identical agile and scrum principles as major scaled agile frameworks, thus the benefits of applying are quite common among them all.
However, even in a more straightforward approach, there might be a drawback to consider.
LeSS is based on Scrum principles and approaches, thus, in case your team is not familiar with Scrum methodology, it will be a tough task to implement this framework. In this case, the benefit of less training and prerequisites won’t apply, since the organisation will have to invest in Scrum onboarding first to unlock the full potential of LeSS. Another benefit that was discussed above is having a one, and only one, product owner, which could be seen as a drawback. One can find it hard to manage multiple cross-functional teams and coping with a great number of sprints and updates. Especially, if we are talking about the corporate environment, where the hierarchy is strictly opposite - one cannot have that amount of responsibility since it becomes too hazardous.
The bottom line is that LeSS will be a suitable framework to choose in the organisation where Scrum is a familiar word. So, I see LeSS rather as the second step to take when teams enlarge, and they need to scale their scrum practices further. Following LeSS companies will achieve balance between “paperwork” that needs to be done due to legislative perspective;
and agile mindset delivery that frames the scaled agile frameworks such as LeSS. This is why we do not have many new roles as in SAFe, we rather focus on adopting well-known scrum approaches to a larger team(s).
1.4 Disciplined Agile Delivery (DAD) – core values and principles
Disciplined Agile Delivery (DAD) is a relatively new methodology, comparing with previous frameworks, the purpose of which is to deliver an IT solution to the client. The founders of
DAD - Scott Ambler and Mark Lines - decided to work, develop and introduce this framework to produce a more united agile approach to software development projects. Like this in 2015 DAD framework was developed. The difference from other frameworks that were covered in this thesis is that DAD is a continuously developing framework with updates introduced each year. The huge step forward for founders was selling their know-how to Project Management Institute in 2019 (Pradeep, 2019).
DAD same as LeSS stands for simplifying overlapping terminologies and roles used in Scrum by focusing on the process to deliver the software solution. Scott W. Ambler defines DAD as a “decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable” (Ambler, 2013). DAD is known for being a “hybrid framework” combining and extending other well-known frameworks and approaches like Kanban, Scrum, Agile Modelling, and others. According to Project Management Institute, DAD was originally developed by IBM, nevertheless, it stays as an open free tool that does not require any particular software (Project Management Institute, 2021). This framework stands for the whole project life cycle from the initiation to production release. Like other agile-based frameworks and methodologies, DAD focuses on small teams working on delivering efficient solution. There are several important principles that DAD stands for (Ambler & Lines, 2011):
1. People first.
2. Learning-oriented.
3. Agile.
4. Hybrid.
5. IT solution focused.
6. Goal driven delivery lifecycle.
7. Risk and value driven.
8. Enterprise aware.
People First
In business we tend to hear a lot that people are the organization’s main asset. When it comes to software development project, we can't go anywhere without people collaborating.
The success of any project depends on the resources available, and human resources are so- called "first-order components". DAD stands for people coming as a first major component of the success of any software development process. Combining it with agile manifesto principles, DAD teams are self-disciplines and self-organised units. When it comes to software development project, we can't go anywhere without people collaborating. The
success of any project depends on the resources available, and human resources are so- called "first-order components". DAD stands for people coming as a first major component of the success of any software development process. Combining it with agile manifesto principles, DAD teams are self-disciplines and self-organised units.
In the traditional approach or as we may call it the "waterfall approach" we have to follow formal handoffs between different stages like test, development, analysis. This usually creates misunderstanding and waste of time since when there is a gap, you have to come back to where you start until everyone is on the same page. While working on the project in the majority of the times we always add something on top of the original requirements.
Imagine, you are working on the development of an application for android, and during the process, a customer comes with a requirement to add iOS. Following a traditional approach will bring a tremendous amount of paperwork and the project team will have to come back to the project iteration stage. On the other hand, the agile environment was designed in a way that boundaries and handoffs should be minimized, and the interest should be put on working as a team to reach customer's goal; rather than working individually just to push the release according to requirements that may be outdated by the time project finished. In the DAD team, you won't face any hierarchy, as this approach encourages cross-functional team collaboration so every skill set can be valuable during different project lifecycle stages.
This interaction and spreading of the power allow everyone to get a better understanding of what is going on in the project, what are the dependencies, together with better resource utilisation.
Building a team according to DAD means making sure that the following five roles are covered in your project (Ambler & Lines, 2011):
1. Stakeholder - here we are not talking just about the end-user, a stakeholder could be anyone who is affected by the developed and deployed solution. Ex. senior manager, auditor, staff, etc.
2. Product Owner - as in other agile frameworks, we have a product owner role in DAD. It's the person who is going to voice customer concerns, thoughts, and desires in the team. A product owner is responsible for clarification of requirements for the final solution/product; together with prioritising the items that team is going to work on to deliver this final solution. This role helps to eliminate traditional "coming to documentation" approach, since one of the responsibilities of product owner is to make sure that he has answers for any incoming questions from the team. In DAD each team has its product owner (what is very different to, for instance, LeSS
