A for Agile Maturity Model

“It’s not the biggest companies that will survive, but the most adaptable” – Joe Kaeser

“It is not the big that eat the small, but the fast that overtake the slow.” – Eberhard von Kuenheim

These two quotes from the former top managers are more timely than ever. Companies must be able to react dynamically to rapidly changing customer requirements in order to be successful in the long term. Product development in particular is a crucial vehicle for this.

Traditional project management methods, such as waterfall-like procedures, no longer meet the requirements.¹ Agile methods are seen as an efficient alternative in software and product development to be able to react to the complexity and changing requirements in a short time. In the area of software development, agile methods are already standard in many companies or are considered best practices. In the area of hardware development, on the other hand, agile methods are still not very widespread. One of the reasons for this is that agile approaches were originally conceived for software development.² n the meantime, more and more companies want to use agile approaches in system development for software and hardware development, which must be continuously synchronised. One question is: How can agility be adapted in hardware-related product or system development?³ This blog post provides an answer.

Agile development

Agile values and principles gave rise to many different methodologies and practices for agile development.⁴ Within software development, the best-known agile framework, Scrum, is already considered the standard for developing new software products.⁵

The use of agile practices enables change by generating customer value. These changes are achieved, for example, with the help of iterations based on customer feedback or through evolutionary requirements.⁶ Other agile methods promote knowledge sharing such as dailies or pair programming.⁷ Basically, agility is associated with the Agile Manifesto as well as with the attributes of

• flexibility,
• willingness to learn,
• speed,
• working on a self-organising team basis,
• iterative-incremental development,
• clock-based working with many deliveries and
• the will for continuous improvement within the organisation.⁸

Agility in hardware development

The Agile Manifesto was written against the background of the challenges in software development. This “limitation” can be seen in the description and also in the values.⁹ However, hardware development differs in parts from software development. Accordingly, the Agile Manifesto cannot be used one-to-one for hardware development, although it can serve as inspiration. For this reason, about 30 experts met at the first “Scrum for Hardware Gathering” in 2016. The aim was to work out the differences between Scrum in software and hardware development and, building on this, to define values that can be used for hardware development. The result is the “Agile Product Charter”, which is described below.¹⁰

“We embrace agile methods as the engine driving innovative solutions and collaboration to amplify economic, ecologic and social benefits across our planet. Through this work we have come to value:

1. Cross functional team collaboration over specialization, process and tools.
2. Modularity over tightly-coupled solutions.
3. Continuous customer collaboration over inflexible contracts.
4. Useful continuous delivery over a single comprehensive delivery.
5. Extending development through manufacturing over fixing problems in the field.
6. Useful continuous documentation over comprehensive documentation.

That is, while there is value in the items on the right, we value the items on the left more.” ¹¹

When comparing with the Agile Manifesto, some changes can be identified. The first value from the Agile Product Charter highlights cross-departmental collaboration and the issue of specialisation. Especially in the area of hardware, development is influenced by several departments. In addition to development, purchasing and production, for example, are also strongly involved in product development. Furthermore, a way of working is supported where several people can perform the same tasks. This shift from specialisation to generalisation is emphasised. Modularisation is also emphasised in the Agile Product Charter. As a result, several modules can be developed decoupled from each other within product development.

Another point is the expansion of development beyond manufacturing. With this, the view of the entire value chain can be expanded in product development. This view is particularly helpful in the hardware sector. It is worth noting that the focus on documentation and continuous delivery has been somewhat adjusted. This is also necessary in the development of hardware, as documentation is required from a legal perspective, for example.

Scaling agile development

As knowledge of agile methods has expanded in practice, there has been a growing desire among many companies to implement agile for large development projects, the entire development cycle and throughout organisations.¹²

If large development projects are to be handled in an agile manner, i.e. several teams work on one product, scaling is necessary, which regulates the synchronisation of the individual teams. When synchronising, it is crucial for a company that develops both software and hardware to also integrate hardware development into this development cycle.¹³ Scaling frameworks that also regulate this integration have been developed and are already used in many companies today.

Among the most widely used approaches in practice are the Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS). Furthermore, the experiences that Spotify uses in the course of scaling are highly applied in practice.¹⁴

In the following, we will focus on scaling with SAFe, as it provides a good starting point for traditional companies, has a clear structure, is aligned with value streams and enables continuous development.¹⁵

SAFe is a framework designed to create enterprise-wide agility using methods from lean, agile as well as DevOps. SAFe was first introduced in 2011 and has been further developed several times since then. The current version SAFe 5 was introduced in 2020.¹⁶

There are four different implementation levels in SAFe 5: Full SAFe, Portfolio SAFe, Large Solution SAFe and Essential SAFe.¹⁷ he individual implementation levels in SAFe are made up of several roles and methods:

• In Essential SAFe, the Agile Release Train (ART), which consists of several agile teams, forms the centre of this level. The roles in this level are divided into the agile team, which works operationally on the product, and the ART in general. In the agile team, a distinction is made between Scrum Master, Product Owner and the development team. The ART consists of several agile teams, product manager, system architect/engineer, release train engineer (RTE) and a business owner. In the course of Essential SAFe, activities such as a Programme Increment (PI) Planning or a Scrum of Scrums are carried out, among others, so that the teams can better synchronise with each other.¹⁸
• In Large Solution SAFe, the concept of ART is extended to several ARTs. To ensure the coordination of these ARTs, three new roles are introduced: Solution Architect/Engineer, Solution Management and the Solution Train Engineer. The main activities here are pre- and post-PI planning.¹⁹
• At the Portfolio SAFe level, Lean Portfolio Management is introduced to guide the strategy of the organisation with the investments and the remaining resources.²⁰

Like the Agile Manifesto, SAFe is defined by values and principles²¹, which are used below to develop a model.

Distinction between values, principles, methodology and practices

The distinction between values, principles, methodologies and practices/methods is particularly important for understanding. The distinction is described in more detail in the following, German-language figure:

Figure 1: Differentiation between values, principles, methodologies and practices²²

As can be seen in the figure, values are the most powerful way to be agile, but also the least visible. They form the cornerstones in the course of agile adaptation. Practices, on the other hand, are the most visible but have the least benefit because they are mostly solutions to individual problems.

Agile maturity models

The will of companies to implement agile methods has increased in the last decade. A common problem in adapting agile methods is identifying how agile the company already is and how agile it wants to become or can become. These problems led to the need to find ways to support companies in adapting agile methods. Structured approaches such as maturity models aim to guide companies in their agile transformation. They provide comprehensive guidance on the use of agile processes, show roadmaps for implementation and describe what agile means at its core.²³

There are numerous maturity models in the literature, which have been examined and evaluated by Ozcan-Top and Demirors, among others. Sidky’s Agile Adoption Framework (AAF), for example, was recommended for use in practice because it is particularly convincing in the categories of defining maturity levels, consistency and accuracy of content. In addition, Sidky places the importance of agile values and principles at the centre of the model. Based on this, practices were defined that help to support the agile values and principles.²⁴ owever, Sidky’s maturity model refers to software development, which is why a further development based on the AFF is presented below. This further development accordingly includes both scaling and hardware aspects.

An evolved agile maturity model

The advanced maturity model is intended to support companies in adapting to agility. On the one hand, it shows steps (maturity levels) that build on each other in a meaningful way, which a company can take when expanding agility, and on the other hand, it gives recommendations on which practices help to achieve these levels.

The structure of the maturity model to be developed is based, like that of the AAF, on the agile values and principles. In order to break the focus on the software area, the values from the Agile Product Charter, SAFe and Scrum are used. The principles are also extended to include the SAFe principles. By integrating these values and principles, the validity of the model is to be extended to hardware and non-software development as well as scaling aspects. The structure of the model is as follows:

Figure 2: Structure of the maturity model²⁵

The relationship between the agile values or stages and the principles can be described using the analogy of “slicing the cake”, which is also used for sharing user stories. A fully agile development process is compared to a cake that has several layers. Each layer represents an agile principle. The individual pieces of the pie show the agile maturity levels. To ensure that each piece of the pie (agile maturity) contains the essence of the whole pie (agility), all layers of the pie (agile principles) must be present in each piece.²⁶

Figure 3: “Slicing the Cake” analogy

This concept was also used in the conceptualisation of the AAF. To ensure that each stage in the maturity model contains the agile characteristic, an attempt was made to include as many agile principles as possible in each stage. The composition with the agile practices is based on the extent of compliance with these agile principles per stage. Each stage uses the agile principles for different purposes depending on the agile value(s) described by the stage.²⁷

The idea behind looking at all agile principles per stage is that a company should not implement only one aspect of agile when adapting an agile maturity level. This approach in itself would not be agile, but rather resemble a waterfall approach in that the whole product (agility) is not ready until the end of the whole process. In an incremental approach, there is a deliverable product after each iteration, which in this case would be a “piece of cake” that takes all principles into account.²⁸

Clustering of values and principles

The use of all values and principles would make the maturity model unnecessarily complicated or confusing, and it would be more difficult to present an implementation in practice. For this reason, the 17 values and 22 principles from the Agile Manifesto, the Agile Product Charter, Scrum and SAFe were considered and a grouping of the values and principles was made according to the AAF template. Through the grouping, all values and principles can thus be taken into account in the maturity model. After this consideration and grouping, the model could be set to five values (maturity levels) and five principles.

In the course of the first level “Collaborative” of the maturity model, the basis for the agile way of working is created by promoting the topics of communication and collaboration. Within the second level “Evolutionary”, the incremental and evolutionary approach is examined more closely in accordance with the value “Useful continuous delivery over a single comprehensive delivery” from the “Agile Product Charter”. The product is to be developed based on a Minimum Viable Product (MVP). In particular, this stage is about introducing a temporal rhythm into the development process that promotes continuous delivery. After the introduction of this way of working, the increase in efficiency is addressed in the third development stage, “Efficiency”. In this stage, teams focus on developing solutions that work, taking into account high quality standards and continuous improvement. Level four, “Adaptive”, focuses on cooperation with the customer. Here, an attempt is made to react to the customer’s wishes during the ongoing development within the framework of an intensified cooperation. In the last stage of the maturity model, “Comprehensive”, it is important for companies to create a sustainable environment that supports the agile way of working in the long term. Special attention is paid here to agile leadership and the continuous focus on the customer and the market.

The second pillar of the maturity model is the principles. The development and composition of the principles results from the clustering of the 22 principles from the Agile Manifesto and SAFe.

In the agile approach, the focus is on the employee. Accordingly, there are a total of nine principles in the agile manifesto and SAFe that focus on this centring. Topics addressed by these principles include

• communication,
• intrinsic employee motivation or
• motivated teams with decision-making authority.

The agile approach promotes the development of products in small steps. Thus, not even one big product is delivered at the end but several smaller increments, each of which has a customer value. This reduces the risk that a product or function is developed without customer value. Furthermore, plannability can be improved through shorter cycles and continuous feedback. This way of working is emphasised in the Agile Manifesto and in SAFe with a total of nine principles. Topics include

• early and continuous delivery,
• queue consideration/assessment,
• feedback including learning cycles,
• sustainable,
• constant development velocity, and
• progress measurement on working increments.

Developing good quality by looking at the product or system is highly valued. Thus, seven principles from the Agile Manifesto and the SAFe framework can be summarised under this point. Topics include

• simplicity through standards,
• technical excellence,
• design,
• ensuring variability.

The last point is also underlined in the agile hardware values and described there as modularity. This offers the possibility in agile hardware development to react better to late changes in the development.

The agile approach promotes development that is focused on creating value for the customer. The importance of customer and stakeholder orientation is described by seven principles, among others

• openness to change and
• close cooperation between all people involved.

As already mentioned, the agile approach was developed especially against the background that requirements for a development project are not always fixed before a project starts. Requirements evolve in the course of projects and changes even in late project phases become necessary more and more often. Thus, the reaction to changes is explicitly described in SAFe and in the Agile Manifesto with five principles, including

• regular reflection in the team and
• visualising and limiting the work in progress.

Basic framework of the maturiy model

The following framework for the maturity model results from the description of the values and principles:

There are various practices that support companies to work in a more agile way. These practices are either newly developed agile practices or those adopted from other disciplines. In both cases, non-agile practices are replaced, redefined or supplemented by agile practices. One example is user stories, which replace a traditional requirements specification. Test Driven Development complements traditional development practices. Pair programming is also an agile practice that is often used in practice.³⁰

These practices were assigned to the defined principles and in a further step classified into a maturity level. The following practices were identified with their assignment to the principles:

Figure 7: Grouping of the principles

Maturity model and application

In the final step, the practices are assigned to the individual levels. The final maturity model is thus composed of a combination of all results and culminates in the following model:

Figure 8: Final maturity model

The application of the maturity model has two overarching steps. Firstly, the current state of the company or project team must be determined and, based on this, a target state is defined, including the suggested practices from the maturity model.

The assessment of the current status can be carried out with the help of a self-assessment. The self-assessment is based on a questionnaire that asks each practice or the goal of each practice with at least one statement.

The questionnaire refers to the frequency of use. In this way, it is determined whether a practice is applied systematically. Furthermore, it can be helpful for the implementation of new practices to know whether certain structures are in place to build on. An example of this is the practice of user stories, which is about describing requirements from the user’s point of view. Here, for example, it could be that a company has already defined what is to be observed when describing requirements. This work instruction or process could be used as a basis for implementation. In addition to a reduced amount of work in the definition, building on familiar structures is important for the area of change management. Staff/project members can thus be more easily involved in the change.

The evaluation of the ACTUAL analysis is presented graphically using a colour scale with Harvey Balls. The individual colours here represent the overall evaluation of a value-principle pair, while the Harvey Balls reflect the evaluation of the individual practices. The following figure shows an example of an ACTUAL analysis:

Figure 9: Exemplary ACTUAL analysis

A green area indicates that the practice is used systematically. If the area is yellow, the practice is used up to 75% of the time. In this case, it can also be assumed that the practice is described systematically. At this point, however, it could be that the goals of the practice are not always fulfilled yet, which is why the rating is not yet higher. Red fields indicate that a certain structure is present, but has not yet been systematically described. Fields not marked in colour indicate that the practice or practices from this field are not used.

Some practices have been described with several statements in the course of the questionnaire. The calculation of the score for this case results from the mean value of the statements. If, for example, the first statement achieves a score of 50% and the second statement a score of 60%, the practice receives an overall score of 55%. This is due to the fact that the statements build on each other and each asks about a part of a practice.

Conclusion

In conclusion, the path to an agile organisation requires a cultural change. Companies will only succeed in this change if they manage to root the values and principles in the corporate culture. Here, the topics of communication, employee empowerment, trust and decision shifting are important. The maturity model developed functions as a guide and serves as a tool to show companies and managers a way to achieve successful and individual adaptation.

Notes:

[1] SCHRÖDER, AXEL (Hrsg.) [Agile Produktentwicklung; 2018]: Agile Produktentwicklung: schneller zur Innovation – erfolgreicher am Markt, 2., überarbeitete Auflage., München: Hanser.
[2] DYBÅ, TORE; DINGSØYR, TORGEIR [Empirical studies of agile software development; 2008]: Empirical studies of agile software development: A systematic review, in: Information and Software Technology, Bd. 50, Nr. 9–10, S. 833–859.
[3] FUCHS, CHRISTOPH; GOLENHOFEN, FRANZISKA [Mastering Disruption and Innovation in Product Management; 2019]: Mastering Disruption and Innovation in Product Management: Connecting the Dots, 1st ed. 2019., Cham: Springer International Publishing : Imprint: Springer.
[4] [26] [27] [28] [29] [30] SIDKY, AHMED [A structured approach to adopting agile practices; 2007]: A structured approach to adopting agile practices: the agile adoption framework, Blacksburg, Virginia: Virginia Polytechnic Institute and State University
[5] [8] [13] PFEFFER, JOACHIM [Grundlagen der agilen Produktentwicklung; 2019]: Grundlagen der agilen Produktentwicklung, Wien: peppair Verlag.
REITTINGER, ANTONIUS [Hybrid Agile; 2018]: »Hybrid Agile« – best of two worlds, in: Agile Produktentwicklung: schneller zur Innovation – erfolgreicher am Markt, München: Hanser, S. 234–251.
[6] [11] JACOBSEN, CHRIS; DORN, DAVID; PARENT, JASON; JUSTICE, JOE; THOMPSON, KEVIN; FELSING, MAC; BERLUCCHI, MATTIA; FERRERO, NICOLA; DEZUTTI, PAOLO; BOYAN, RICH; TESSIER, THOMAS; QUAGLIA, DARIA; GUTTMAN, DAWN; SCHREUDER, JASON; STARKWEATHER, KATRINA; WEAVER-JOHNSON, LONNIE; GARDA, MARCO; CARROLL, MICHAEL; GIORGETTI, NICOLO; CARSON, PAUL; PATRIDGE, RICK; BOEBERITZ, DAVE; SMITS, HUBERT; BRADFORD, JEANNE; SANKAI, KAZUTAKA; BERGERO, LUCA; BUCKNER, MARK; FEW, MIKE; SAMMICHELLI, PAOLO; BORSELLA, PETER; VAIDA, THEODORE [Agile Product Charter; 2016]: The Charter for Agile Product Development
[7] LAW, AMY; CHARRON, RAYLENE [Effects of agile practices on social factors; 2005]: Effects of agile practices on social factors, in: Proceedings of the 2005 workshop on Human and social factors of software engineering – HSSE ’05, the 2005 workshop. St. Louis, Missouri: ACM Press, S. 1–5
[9] BECK, KENT; BEEDLE, MIKE; VAN BENNEKUM, ARIE; COCKBURN, ALISTAR; CUNNINGHAM, WARD; FOWLER, MARTIN; GRENNING, JAMES; HIGHSMITH, JIM; HUNT, ANDREW; JEFFRIES, RON; KERN, JON; MARICK, BRIAN; MARTIN, ROBERT C.; MELLOR, STEVE; SCHWABER, KEN; SUTHERLAND, JEFF; THOMAS, DAVE [Manifesto for Agile Software Development; 2001]: Manifesto for Agile Software Development
[10] SAMMICHELI, PAOLO [Scrum for Hardware; 2018]: Scrum for Hardware, 2. Auflage
[12] [15] MATHIS, CHRISTOPH; LEFFINGWELL, DEAN [SAFe – das Scaled Agile Framework; 2018]: SAFe – das Scaled Agile Framework: Lean und Agile in großen Unternehmen skalieren, 2., überarbeitete und aktualisierte Auflage., Heidelberg: dpunkt.verlag.
[14] BÖHM, JANKO [Erfolgsfaktor Agilität; 2019]: Erfolgsfaktor Agilität: Warum Scrum und Kanban zu zufriedenen Mitarbeitern und erfolgreichen Kunden führen
[16] SCALED AGILE INC [Welcome to Scaled Agile Framework® 5!; 2021]: Welcome to Scaled Agile Framework® 5!
[17] SCALED AGILE INC [SAFe 5 for Lean Enterprises; 2021]: SAFe 5 for Lean Enterprises
[18] SCALED AGILE INC [Essential SAFe; 2021]: Essential SAFe
[19] SCALED AGILE INC [Large Solution SAFe; 2021]: Large Solution SAFe
[20] SCALED AGILE INC [Portfolio SAFe; 2021]: Portfolio SAFe
[21] SCALED AGILE INC [Core Values; 2021]: Core Values
[22] SAMMICHELI, PAOLO [Industrial Agility; 2017]: Industrial Agility – How to respond to the 4th Industrial Revolution
[23] [24] OZCAN-TOP, OZDEN; DEMIRÖRS, ONUR [Assessment of Agile Maturity Models; 2013]: Assessment of Agile Maturity Models: A Multiple Case Study, in: WORONOWICZ, TANJA; ROUT, TERRY; O’CONNOR, RORY V.; DORLING, ALEC (Hrsg.): Software Process Improvement and Capability Determination, Communications in Computer and Information Science. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 130–141
[25] In Anlehnung an SIDKY, A structured approach to adopting agile practices, 2007, S. 80, sowie BAGASKARA, RABBANI MAHATMA; SAMPE, VERAWATY [Scaled Agile Maturity Measurement in Manufactoring; 2021]: Scaled Agile Maturity Measurement in Manufactoring, Göteborg: Chalmers University of Technology, S. 33

This article is a joint work by Dierk Söllner and Kai Hahn.

Dierk Soellner has published three other posts on the t2informatik Blog:

What does t2informatik actually do? One click and you'll know.