Agile Transformation | Methodology | Scrum
NEW scrum process overview 
Daniel Burm 23 May, 2012
Share 
For many, introducing agile methodologies is the perfect way to future-proof their company. But the larger the size and complexity of teams and projects, the less adequate the bare-bones methods of Scrum and the like turn out to be.
Agile Methodologies
According to the 2019 State of Agile Survey, a whopping 97% of the globally surveyed companies reported that their organisation practises agile development methodologies, with 95% saying that their agile projects have had a positive impact. The report also states that 19% don’t know how they should scale agile working methodology on a larger scale.
Lean and Agile methodologies basically serve to simplify processes and coordinate them effectively. Now if you’re already working with agile methodologies, you’re probably familiar with approaches like DevOps, Kanban, or Scrum. Small, flexible teams work on a product step-by-step and transparently deliver quick and high-quality results. Thanks to constant client feedback, products can be continuously improved and refined, and teams can quickly react to changes and specific client needs.
That works fine as long as the agile teams are a manageable size. So how can you implement agile methodologies in more complex domains?
Scaling Agile
Agile methodologies originated in IT and are still mostly used in IT, product development, and marketing. They have remained a mystery for many other departments – and all too often, they’re not anchored in a company-wide context.
This is beginning to change, as large organisations are looking at becoming agile on a bigger scale. And they can do so with the help of agile frameworks.
The three most known frameworks are Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Disciplined Agile (DA). In this article, we’ll be taking a closer look at the Disciplined Agile process framework.
It’s applicable in companies of various sizes and allows for the integration of methodologies from both SAFe and LeSS as well as Kanban, Scrum, and many more.
Disciplined and Agile
DA is subdivided into Disciplined Agile Delivery (DAD), Disciplined DevOps, Disciplined Agile IT (DAIT), and Disciplined Agile Enterprise.
The main core of DA is DAD, where IT solution delivery is defined end-to-end: from initial modelling and planning, setting up the team and securing financing to continuous architecture, continuous testing, continuous development, and monitoring during the entire lifecycle.
Building on this, Disciplined DevOps and DAIT focus on the coordination of a company’s IT as a whole – shaping the development cycle, operations, support, data management and other areas to become as effective and uncomplicated as possible.
The Disciplined Agile Enterprise results from all the prior segments – a company that can anticipate market changes and adjust its strategy accordingly. In other words, an agile company.
Across the Board
The end goal is to become exactly that – an agile company. And that’s why DA doesn’t only focus on IT but encompasses other departments. For example, marketing, sales, and procurement can all benefit from agile methodologies as well.
One of the decisive advantages of DA is that it is agile agnostic, meaning you can implement solutions without having to choose one single method. Processes are mainly a mix of Lean and Agile methods, but even traditional methodologies are part of the game, like Kaizen, the philosophy of continuous improvement of working practices, personal efficiency, etc.
Within the DA framework, team members are given the freedom to choose the Way of Working (WoW) that make sense to them in the context of their project – even from among the SAFe and LeSS frameworks.
Another benefit of DA is the balance it strikes between agility and risk awareness. This is especially important in strictly regulated industries.
Principles
Working culture is an important aspect in agile working methodologies. The underlying culture of DA is expressed in these seven main principles.
1. Delight customers – this is a key priority; not only should the needs and expectations of clients be met but you should strive to surpass them.
2. Be Awesome – great teams are made of motivated people that work in a positive environment and with the necessary support.
3. Pragmatism Over Purism – effective methodologies go beyond Agile.
4. Context Counts – every person, every team, and every organisation is unique and requires a unique, effective strategy, which should be continuously developed.
5. Choice is Good – different situations require different approaches. Teams should own their processes and must be able to experiment. That way, they find out what works in practice and what doesn’t. The ideal solution can be found early on when teams know the different options to choose from and the compromises that their choices entail.
6. Optimise Flow – an organisation is a complex-adaptive system in which interacting teams and groups develop on an individual basis. A successful strategy requires that teams work in a coordinated way and are constantly improving.
7. Enterprise Awareness – if people view their company as an entity in which they play an active part, they’ll want to understand the needs of the organisation as a whole and achieve its overall goals. Best practices are shared more frequently across the company and used in different contexts – making sure that no one has to reinvent the wheel to get the job done.
Roles
Scrum has three roles – Scrum Master, Product Owner, and Team Member. DA, however, has many different roles. This is mainly due to the size of the projects and the overarching nature of DA.
While there are separate roles for the different subdivisions of DA, we’ll focus on DAD in the following list, since the solution delivery process is at the heart of the framework.
The 10 DAD roles are subdivided into primary and secondary roles.
The following 5 primary roles are relevant in every project, regardless of size.
1. Stakeholder: a person who is directly connected to the result of the solution.
2. Team Member: this role focuses on developing the actual solution.
3. Team Lead: they create and maintain productive working conditions.
4. Product Owner: they’re the contact person for any questions about the solution.
5. Architecture Owner: they’re responsible for IT architecture. In small teams, this can also be the Team Lead.
The secondary roles come into play depending on the size of the project. There are five secondary roles.
1. Specialist: specialists such as Agile Business Analysts are sometimes needed to define the environment in which the solution will be introduced.
2. Domain Expert: other specialists such as tax experts are sometimes necessary to provide their expertise in a certain area.
3. Technical Expert: technical experts such as User Experience Specialists are involved in, for example, designing interfaces.
4. Independent tester: a large part of the tests are done by people from the primary team, but some teams are supported by independent testers who can perform penetration or performance tests.
5. Integrator: for big DA teams that are subdivided in smaller teams, you need one or two integrators to integrate the solutions across the larger team.
The primary roles are, as mentioned above, found in every DAD project. The secondary roles only come into play when projects are bigger in size – and only during a limited period of time.
A larger scale project often means that technical aspects must be taken into consideration that aren’t covered in Scrum. For instance, the role of Architecture Owner is borrowed from Agile Architecture to suit certain contexts in DA.
These roles, however, should not be confused with job titles. The role of the Team Lead, for example, can change from one person to another, when absence planning or other circumstances require this. All team members are equal – DA places a focus on people and on them acquiring new skills. Traditional roles like the Project Manager do not have their place in DAD; instead, the tasks traditionally done by a Project Manager are taken on by other roles.
Phases
As mentioned earlier, DAD is responsible for the delivery of solutions. This is done using a mix of the Scrum and Kanban lifecycles, as well as 2 that support Continuous Delivery, an exploratory lifecycle, and a programme lifecycle. Teams can choose their own preferred method and implement it in 3phases, which DAD calls: Inception, Construction, and Transition.
1. Inception
This is where teams are defined and the planning is done. Agile teams will create a project framework during this phase, , envisioning and prepping a consumable solution. Some goals in this phase are initial modeling, planning, and organisation, as well as identifying, prioritising, and selecting projects and defining the initial requirements and release plan.
2. Construction
During this phase, the solution will be produced on an incremental basis. This can be done via a set of iterations (or Sprints) or a lean, continuous flow approach. Here, the agile agnosticism of DA really shines through, because teams use a mix of practises from Scrum, XP, Agile Modeling, Agile Date, and others. Goals include finding a proven architecture, working through the prioritised items and backlog to create a consumable solution, which is then demonstrated to stakeholders. This can take many short iterations, at the end of which change requests are also taken into account.
3. Transition
The solution is released in this phase. Over time, it becomes shorter and ideally evolves into an activity rather than a phase. Typically, this takes one or more short iterations and culminates in the product being released into production. Any change requests after release will trigger another construction iteration.
Barclays’ Agile Transformation
To highlight the benefits of DA, let’s look at an example of a large company that implemented agile methodologies in their organisation.
Barclays, a 325-year-old bank, rich in tradition and large in size, started a company-wide transformation from traditional hierarchies to agile methodologies in early 2015. To achieve this, they chose DA.
Starting Point
The company already had some teams that worked with Lean and Agile. But they worked relatively isolated from one another, and their methods were not used in the larger company context. They were “agile islands” that had to be connected and scaled.
Every part of the value creation chain was to become agile – from concept creation to cash generation. The end goal was aligned with one of the DA principles: Delight the Customer.
Choosing the Framework
The agility experts had the choice between SAFe, LeSS, and DA.
Scaling in a company of this size required a framework that was flexible and stable enough to incorporate the different agile methods that were already being used in the aforementioned “agile islands”.
SAFe and LeSS are good solutions in certain contexts. But for a company with more than 130,000 employees that has thousands of teams, a more flexible solution had to be found. DA offered this flexibility: depending on the context, you’re able to choose from a range of different methods – even from SAFe and LeSS processes.
At the same time, risk and value creation factors had to be taken into consideration. Due to the highly regulated nature of the banking industry, these risk aspects as well as compliance requirements were especially important in this case.
Because DA ticks off all these boxes, Barclays decided to go with this particular framework.
The Implementation
Within the first year of the transformation, more than 800 teams became agile. To measure the progress of the individual teams, a system of agility levels was introduced: level 1 for teams that were still working in a prescribed and practice-oriented way – meaning the traditional way – and levels 2 and up for teams that were more input and result-focused. This allowed teams to progress at their own rhythm.
The levels were an indicator for the agility maturity of the teams and contained a number of aspects: concept-to-cash, quality, team structure, technical competence, best practices, continuous delivery, etc.
Thanks to this measurement system, teams were able to experiment and develop properly.
The challenge lay in keeping senior management targets and the teams’ targets separate. Managers had to put a lot of trust in the teams, who were constantly evaluating themselves. The change of working culture was the most difficult one to tackle. But with enough training and support by agility coaches, the task was completed in a shorter amount of time than anticipated.
The Benefits
After one year, the throughput increased by 300% – that’s the average number of stories completed per app every month.
For more than 80 apps, code complexity decreased by 50% and, at the same time, testing coverage increased by 50%.
Production incidents also decreased considerably, and more than half the strategic apps quickly began to deploy business value to production at least every 0-4 weeks.
Another positive effect was that employees were generally happier after the transition.
Conclusion
DA is a great framework for companies that want to implement agile methodologies in several, or all of their departments – across the board. It is adaptable and flexible, and apart from being able to compile several agile methodologies under one roof, it also takes into account factors like risk and compliance.
The DA process framework takes the best from many worlds to introduce agile methodologies in complex environments, integrating legacy systems without a problem.
As a result of the culture change, all teams in the company will become enterprise aware. They’ll know how to deliver solutions effectively and understand their impact on the company as a whole.
Business Perspective
DA is ideal for scaling agile methodologies across departments and in the larger context of your company. That’s because it is flexible enough to allow your teams to pick and choose their Ways of Working from a range of agile methods, while at the same time taking into account factors like risk and compliance. Increased customer focus, delivery cycles, throughput, and fewer product incidents are only some of the key business benefits that an agile enterprise has to offer.
