agile methods Archives - Digital Innovation Blog

In our experience, creating transparency plays a crucial role in our agile approach on the path towards our objectives because corporate objectives should always be supported by both the management and the team.

The Best Practice Framework that ZEISS Digital Innovation (ZDI) has developed over the course of the last few years has already been described in detail in the first post of this series. The Framework is the result of the continuous optimization of our strategic work. The factors of success contained therein are meant to help us achieve our primary corporate objectives in a flexible manner.

Transparency regarding our long-term objectives and the strategy to achieve them

As a company, we jointly pursue long-term corporate objectives that are defined for the next five years. From these objectives, we derive a strategy map with all the strategic fields of action where work is required in order to achieve the objectives. The objectives and the strategy map form the framework of objectives, which is the decision-making basis for the development of new strategic initiatives to be implemented within the framework of our agile strategy process.

Only when everybody knows where they are headed, i.e. with the framework of objectives, is it possible to pool everybody’s strengths, energies and independent entrepreneurial activities within the company. With transparency towards the objective, we create the basis for all the employees to contribute their thoughts and ideas and help pave the way towards it.

In order to achieve transparency regarding our long-term objectives and the strategy to achieve them, we use our ZDI standup, the strategy portal in Confluence, and corresponding notices regarding the strategy map, including the strategy sprint at each of the ZDI locations.

The ZDI standup is a 30-minute plenary of our company that takes place every four weeks, in which every employee at every location and workplace can participate. We use this format, for example, to present our latest strategy sprints. A sprint contains all the prioritized strategic initiatives for the next four months that deal with topics that serve to achieve the long-term objectives. The ZDI standup is meant to call attention to the initiatives, their objectives and background and their value regarding the achievement of our long-term objectives, and to encourage employees to get involved.

In addition, all the information on the approach, objectives and current initiatives in the strategy sprint is documented in our strategy portal, where it can be retrieved at any time. The strategy map that visualizes our objectives and the path to achieving them is put up as a poster at each of our locations. This way, our projects are always with us during our daily work.

*Figure 2: Exemplary presentation of a strategy map*

Transparency for strong employee participation

We want our employees to participate in the company’s continuous development, creating commitment, employee loyalty, independent action, and greater creative power. Therefore, we take care to ensure not only that our employees know the objectives, but also that they have opportunities to actively help shape the path towards our objectives. We do this by offering anyone who is interested the chance to participate in strategic initiatives.

To enable them to decide to participate in an initiative, the content, value and planned result are clearly presented in the ZDI standup. This way, we give all our colleagues the opportunity to contribute wherever they can have the greatest effect. Team members who are intrinsically motivated because their task is fun or a special challenge for them can achieve great things.

Transparency for a strong, consistent focus on implementation

We want to achieve our challenging sprint targets and keep the implementation pressure steady throughout the four-month period. It is important for us to get a sense of the progress of each initiative in the strategy sprint, and to know where action needs to be taken.

For this purpose, we make the implementation status and the intermediate results of individual strategic initiatives transparent, e.g. by means of our biweekly strategy standup and our digital task board, the ZDI board. This transparency helps us to avoid the duplication of efforts, to share knowledge, and to promote the teams’ creativity. This often gives rise to valuable new ideas for our continued development. Pooling our resources and the internal knowledge transfer help us to achieve our objectives more quickly.

*Figure 3: ZDI board with all the strategic initiatives in the current strategy sprint*

All the strategic initiatives in the four-month strategy sprint are made transparent on the ZDI board, detailing all the tasks and the respective people responsible. Furthermore, the initiative teams record their results in our strategy portal, contributing to the in-house knowledge transfer.

In the strategy standup, which takes place at two-week intervals, the respective owners of each initiative report on recently completed tasks and the tasks to be addressed in the next 14 days by means of our ZDI board. This standup is a format that covers all the locations across the entire company where we provide the employees brief, but detailed insight into the current goings-on and an overview of the initiatives’ implementation status. This way, everybody who is not immediately involved in the initiatives is able to give our clients information and to take action. Furthermore, it is important for us to get a sense of the progress of each initiative, and to know where action and decisions need to be taken.

This approach puts a face to the owners and the members of an initiative, making it easier to contact them directly.

Making successes transparent is also important to us. We want to celebrate them together with our colleagues. Every time an initiative is completed, we are one step closer to achieving our primary long-term corporate objective. This motivates and encourages us. Upon completion of an initiative, we report on how close we have come to the objective, the specific results of the initiative and the integration into the operative business within the framework of our ZDI standup.

How does transparency help us during the coronavirus pandemic?

The past few months have shown us just how important corporate communications are—especially in uncertain times like these. Therefore, we significantly shortened the cycles of our ZDI standups at the beginning of the coronavirus pandemic in Germany. This allowed us to directly react to our employees’ increased need for information without delay. At the same time, we were able to respond to the highly dynamic development and the continuously changing current situation.

Since March 2020, the ZDI standups have taken place every week, then biweekly, and, for some months now, at four-week intervals again. This way, we were able to quickly share all crucial information with all the employees and to make the most recent changes transparent.

The teams themselves also introduced shorter coordination cycles, and they use agile methods and appropriate technology to cope with these times of social distancing. The lack of physical proximity and the transparency that comes with direct contact with colleagues is not a problem for us. Our many years of experience with distributed work allows us to create a similar degree of transparency while increasing flexibility at the same time.

How can we permanently ensure transparency?

Our approach thrives on a high level of discipline, consistency, cooperation and participation, among other aspects. Therefore, everybody should know how the process works, what the rules are, and how each individual can participate in a strategic initiative.

For this purpose, comprehensive documents detailing the approach, the rules and principles, and templates are provided in the strategy portal. The Strategy Process Officer is primarily responsible for this. All the retro action items resulting from the retrospectives that take place every four months in order to optimize the agile strategy process are also recorded on our ZDI board. The Strategy Process Officer reports on the implementation status within the framework of the biweekly strategy standup.

Creating transparency was the basis for our process of change over the past few years, and the transparency in turn accelerated this process. As a driver that acts across hierarchies and locations, transparency stimulates the transformation of our culture and organization towards our objectives. Once again, we see how important transparency is in order to be able to deal with unforeseen situations together and prevent the development of knowledge silos.

However, transparency is not our only factor of success. You will learn more about the others in the subsequent posts in this series.

Using agile methods is not a 100% guarantee of better software. This is due to the fact that the agile context constitutes a major challenge for many traditional methods of quality assurance. In a system that frequently changes, how can we permanently ensure that the components that are deemed functional now do not fall back into an undefined state due to future improvements?

While the waterfall model provides for testing only at the end of the project, and the frequently used V-model (see Figure 1) also has a clearly defined chronological sequence, in an agile environment, it is crucial that tests are, if possible, always done under the exact same conditions and with the least possible effort because of the frequency at which they have to be done. Furthermore, they should be ready as soon as possible after the implementation of the function to be tested. This is the only way to ensure that they can keep up with the continuous changes.

Test-driven Development

The biggest problem with traditional testing in this context is the fact that it is usually done downstream. It is only done when there is something to test. This seems to be trivial at first glance because you would think that if you want to test something, you need a corresponding test object.

Even though the test cases and the relevant data can be derived from the specifications, without an actual test object, the execution seemingly does not produce an analyzable result. However, this dogma does not apply for automated tests. Whereas continual manual testing would be far too expensive in the long run, automated tests can safely be written and executed shortly before the actual implementation, so that they temporarily test only a shell of the future test object. A shell like the one provided by an interface specification, for example.

In this case, the test is a kind of automated specification, the requirements of which are not fulfilled at first (red area in Figure 2). During the implementation stage, the developer can check their code against them, getting immediate feedback whether their work meets the requirements. Once this status is achieved (green area), the state of the source code is assured, and the developer can then restructure it (yellow area). In the case of new requirements or fundamental changes, the tests will fail again (red area again) and must first be passed correctly again (green area again).

More finely granulated structures then result from this general sequence of actions. They result in a very high test coverage that allows for errors to be found early on and simplifies the correction of such errors. Furthermore, interfaces and their implementation are defined more thoroughly than with traditional methods. This is what enables the high level of adaptability of the source code, which is essential for agile software projects.

Der Ablauf der testgetriebenen Arbeitsweise — *Figure 2: Sequence of the test-driven method*

In addition, one of the most important characteristics of automated tests is their legibility. Basically, they can be understood to be not only a test of the functionality, but also a kind of documentation of the latter. Because of how close they are to the functionality they test, and because of their clear structure, they describe the behavior of the code to be tested in a way that a normal written text would not be able to. And as their result is furthermore completely independent from the test object, they automatically tell the observer if they are no longer up to date.

Behavior-driven development

Component tests are clearly legible only for the group of people who understand the respective programming language and who know the test framework used. Outsiders, such as test managers, project managers or even end users, gain very little from the granularity and the level of detail.

Another weakness becomes evident when you consider the development process as a whole. Tests created with test-driven development are excellent for verifying parts of the software based on their specifications, but not for validating them against the acceptance criteria. But those are the criteria that need to be fulfilled, which is why they should come before the implementation in testing.

This is why the so-called behavior-driven or acceptance test-driven development evolved from the well-known test-driven development. With this type of development, the tests and specifications merge thanks to the use of certain tools and keywords, allowing the test results to be analyzed in plain language. For this purpose, we turn away from describing individual functions towards detailing the expected behavior. This way, the definition of the individual test cases no longer requires background knowledge of the program’s architecture, allowing even non-developers to understand it, and often, it even goes so far as to no longer speak of test cases, but of specifications.

Behavior-driven development and test-driven development are not to be understood to be rivals, however. The former primarily serves to validate the software and test the system integration, while the latter serves to verify and thus ensure the functional correctness. Consequently, it makes sense to combine the two.

Effort

Due to the fact that developers are expected to write the tests in addition to the actual product development, test-driven development involves greater effort than traditional methods at first. An adequate infrastructure needs to be established, the use of additional tools needs to be learned, and additional code that does not immediately result in usable features needs to be written. This may be discouraging at first, but in fact it only illustrates the effort that will otherwise be required much later over the course of the project. Instead of the effort involved in long testing and bug-fixing phases near the end of the project, a large part of the quality assurance is prepared at a time when the project team still has quite a lot of room to maneuver. The work required decreases as the project progresses because the infrastructure usually has to be established only once, and then only needs to be adjusted here and there.

Conclusion

Using the methods presented in this post constitutes a significant break with the traditional methods of software development in some ways, but it facilitates a kind of quality assurance and documentation that is difficult to achieve otherwise. Basically, the software itself reveals its current status without the need to maintain external resources that can quickly become obsolete. By combining the different approaches, you can ensure a high level of quality and a comprehensive understanding of the project across all levels of abstraction.