The Routine of a Distributed Team: A True Team with Authentic Values

In this blog post, I would like to talk about my personal experience working in Saxonia Systems (since 03/2020: ZEISS Digital Innovation) first distributed team in Dresden and Miskolc, Hungary. The exciting thing about this is that 60 people located almost 1000 km from Saxonia Systems head office can work on the same project as the colleagues in the office next door, and yet they are a true team. People who do not have experience working in a distributed team will probably have some difficulty understanding how this type of collaboration works. I am writing as the scrum master of a team, half of which is located in Dresden, the other half in Miskolc, Hungary. This blog post is meant to show how we started working together, and how we gained the trust and courage to build this team.

Initially, the team consisted of the following people: Three developers and a business analyst from Dresden, and three developers and a scrum master from Miskolc. The German half of the team had already been working on the project, but there was still a lot of work to do before the deadline. At the beginning, we all had different expectations in the collaboration: At first, we were afraid of the camera on the wall. How are we supposed to work when someone is watching us all day? How is a distributed team supposed to work when our German language skills are not that great? How are we supposed to work with colleagues who are that far away?

People standing in front of a screen during a video conference in a distributed team
Figure 1: Brief discussion in the team

Time was short, and we quickly set up the offices according to the ETEO concept. Once the basics had been established, we met in person for the first time. The trip only took a few days—just enough time for us to get an idea of the project together. We thought, now that we had met in person, there was no more preparation left to do—we all liked each other. So now we should focus on the project start, and that’s that. However, we soon realized that it was not going to be that simple.

We came to realize that the permanent video connection is not the solution for distributed work, but merely a tool that helps the team in their work. It is great that we can see the others all the time, but nobody had the courage to stand before the TV. How could we expect team members who had met only once or twice to have the courage to ask a simple question in front of the entire team? More likely than not, the answer would be “I don’t want to bother the others. Instead of asking them, I’ll just google the problem, right? If I’m lucky, I’ll find the answer quickly; worst case, I’ll spend hours on this.” I think it is obvious that the team cannot afford losing that much time in such a situation if they want to be effective.

I believe that this kind of courage grows in people if we are able to approach and start to trust each other. It is not easy to build trust without meeting in person, talking casually, having dinner together, and undertaking team-building activities. Based on my experience, I can say that what really helped us build a true, geographically dispersed team was the possibility to travel back and forth between the locations in the early stage. Team members need to be able to sit next to each other; they need to be able to feel like a team, not just like people working together on something. Later, meeting once a month or every other month is enough. Still, that should be the maximum interval because the connection has to be maintained; otherwise, the team’s productivity diminishes.

Smiling people sitting at a dinner table on a terrace.
Figure 2: Team-building dinner

Being agile is another important objective. That may sound cliché, but it helps the team to evolve and demonstrate their individual values. Below I will describe a few examples that helped us get where we are today.

For example, we started working with new technology that not all of us were familiar with. In the past, we used to try and share knowledge in pair programming sessions because we did not have specific scrum meetings for this kind of activity. As a result of a retrospective, we found that we needed to organize “Developer Cafés”, weekly meetings where we sat together and exchanged our knowledge of the selected issues within the team.

Learning German is another example. Our project language is English, but the team decided to speak German in the daily stand-up meetings because they wanted to learn the language. You might think that this was only difficult for the Hungarian colleagues, but that is not true. It was a great challenge for the German colleagues as well because they had to speak more slowly than usual, and be careful to use simple sentences.

People sitting at a long conference table in a meeting room
Figure 3: Workshop in Dresden

This kind of thing is usually the result of the retrospective, the most important scrum ritual in the team’s life. We have to resolve our problems within the team and improve. This is the best opportunity for the team to evolve. In this context, it is very important at times for the team to be able to do a retrospective together in one location. Personal meetings help to strengthen the bond within the team—this is my most important advice. Because over time, the team will evolve, provided that they are encouraged and feel that they are a team.

The User in the Center of Software Development

The focus of this blog article is the integration of User Cantered Design (UCD) into our software development process at Saxonia Systems AG (since 03/2020 ZEISS Digital Innovation). A highlight is put on the tools and methods used to tailor the software to the actual user’s needs.

The root of bad usability

Why doesn’t anyone use the new software? If this question arises, it is usually too late. The development is already completed, and the users stay away or continue to use the previous solution. If this happens it maybe has happened again, that the requirements collected do not align with the actual user’s requirements. This is a common real-world phenomenon, which shows itself in bad usability and low acceptance of the finished solution. One of the possible approaches is offered by User Centred Design (UCD). This puts the tasks, properties and goals of the future groups of users in the centre of the software development process to achieve a high usability of the final product.

User Centered Design at Saxonia Systems AG

Due to our agile software development process, reaction to changes and new requirements is fast. Early feedback from the future users is essential for high levels of usability. Our Scrum inspired agile process is extended with tools and methods of usability engineering so that the user is involved regularly from the beginning.

UCD deliverables of our agile process
Figure 1 UCD deliverables of our agile process

At the start of the project the UCD elements are incorporated into the product vision. Beside classic parts like project goal or system scope, the description of prospective user groups and the usage context are sensible UCD additions.

The product backlog does not only contain user stories and technical spikes, but also contains room for design spikes, that enable the team to focus on usability issues. This can include prototypes as a basis for decisions or the planning and the carrying out of user studies.

Additional quality gates are added to the scrum artifacts Definition of Ready and Definition of Done, in order to guarantee, that the software fulfils future user requirements.

Before user stories are ready for implementation, they are supplemented with sketches, mock-ups or designs. These visualise the functions, that are to be implemented, to the team. If they can be applied, process models are also included to show more complex sequence of events.

User stories are considered done in the UCD perspective if the usability principles are met. This can be checked via an expert evaluation. Hereby the usability engineer checks the functions heuristically for the adherence to the rules. Additionally, the consistency of the application and the style-guide conformity are checked.

It is advisable to have a central storage for usability background knowledge, e.g. a team wiki.

That way a team can always get information on user feedback and current status regarding UCD. Recommended content is:

  • Information architecture
  • Domain model
  • System documentation
  • Studies and test results e.g. user studies and CUI tracking
  • Personas

As you can see in the preceding sections, we incorporate the prospective user into the development of custom software development. In our experience this is essential for a high usability and acceptance of the final product. By getting early feedback by the user and using agile and lightweight methods you can eliminate the starting question “Why doesn’t anyone use the software?”, from your vocabulary.

From sprint to sprint – my journey to becoming a Scrum Master

In my blog post I describe my path to becoming a Scrum Master and show, how exactly such a role change can look like. I will give you some tips to help you on your way and I hope it is also entertaining.

Scrum Master im Arbeitsraum

Many of us will know: A new project begins, new colleagues come up to you, new networks, tools, and so on. As a consultant you start getting to know your new environment. As a specialist I will do a good job, despite the new variables. It always gets interesting when I leave my specialist role behind and therefore leave my comfort zone. So how about slipping into a new task at this point? A role that can and should indirectly influence the project team?

First sprint: All beginnings are hard or what was that?

Initially restless nights were to be expected. Many questions and ideas all around the Scrum Master are in the air: Where do I begin with my work? What is the team thinking about it? What the hell am I exactly supposed to do?

There is something good about having so many thoughts in your head – apart from missing sleep. All the questions I have asked myself, I would like to have answered.

Tip 1: Clarify open questions as soon as possible to gain more and more security.

By now I can say, you do not have to answer all questions alone. Support will be given upon request.

schlafender Panda

Second sprint: The preparation phase

I was able to acquire the theoretical knowledge for my new task quite fast by using podcasts, blogs, and professional journals.

Theory is good and sets the foundation but without practical utilisation it is not worth much. Values like trust and empathy have a greater importance in this role. What you must be aware of is that you as a Scrum Master cannot really make a difference without the team. This is where I wanted to start and put my focus on. Maybe I could get into conversation with colleagues from the new project earlier.

Tip 2: It is no problem to openly admit that you have not yet completed x projects as a Scrum Master.
It possibly might incite the team to take the new paths together
.

Third sprint: The start

My work begins with the introduction in the team. As described in sprint 2 I already did that. So first and foremost, it was about what I would contribute for the team. Words like organizer, moderator, supporter, and a few others fell. I was not very surprising. In sprint 1 and 2 those expressions were used a lot when it comes to the duties of a Scrum Master.

The next step was about applying all the information I have read and heard in my everyday working live. Here I definitely needed people with experience in this domain – contact persons that guided me throughout the first time. At this point my thanks again to my coach Ines. I was able to join first reviews and plannings followed by an evaluation and coaching. Slowly I got an idea of what I was heading for.

One of the first lectures I read in the beginning was “Was macht der Scrum Master den ganzen Tag“(German for “What does the Scrum Master do all day”) from Henning Wolf. Soon I could put this reading aside. It was much more than I thought.

Tip 3: Do not just ask yourself as Scrum Master the following question in the beginning, but in every iteration: “What did I contribute to make out team better?“

Fourth Sprint: Do It!

In my first days as a Scrum Master it was my task to create the foundation for improvements in the team. By closely working together with the Business Analysts (supporters of the product owner on the client side) and the team, we were able to identify open issues quickly. The end in which I was jumped was not as deep here. Step by step we optimised schedule chains, adapted processes, and worked out new ideas with the team, which should move us forward in our work. In addition to the organisational aspects, my first retrospective was also on the agenda. I think you can imagine that this was a pretty exciting date for me.

While the first attempts at the flipchart looked rather, well let us say, “modest”, it got better and better over time.

Beispiele für Flipchart-Coaching

Tip 4: Visit a flipchart coaching if you have the opportunity – even just a few tricks can improve your presentation considerably.

Fifth sprint: Conclusion

I don’t find it hard to answer the question of Henning Wolf “Was macht der Scrum Master den ganzen Tag“(German for “What does the Scrum Master do all day”) mentioned before. It is a constant challenge for the Scrum Master and therefore for me to provide optimal support for the team and to continuously develop myself further. I was able to successfully complete my certification “CSM”, but this was certainly not the last milestone.

I am looking forward to all the things to come in my new role and of course to further Scrum Masters colleagues 😉 So if you are interested in supporting our team as a Scrum Master in the future, please contact our staff team at jobs.digitalinnovation@zeiss.com.

Successful Collaboration with Students from Zittau/Görlitz University of Applied Sciences

Students of Computer Science at the Zittau/Görlitz University of Applied Sciences have to complete a three-month practical project at the end of the Software Engineering module to demonstrate the skills they have acquired in their past lectures and seminars. The students at the campus in Görlitz have the advantage that several IT companies that are willing to cooperate with the university are located in the city. Saxonia Systems (since 03/2020: ZEISS Digital Innovation) is one of the companies that have decided to support a group of students in their practical project.

In order to give the students a realistic impression of agile software development, Saxonia decided to use the tried-and-tested scrum process model. With this method, a team of developers headed by the scrum master develops software increments in iterations or sprints, and these increments offer a certain added value for the client from the start. With each software increment, new functions are implemented according to the client’s prioritization. The IT company’s task is to provide the topic of the project, and the company’s role is that of the product owner. Saxonia Systems thus represents the client, who was represented vis-à-vis the scrum team by Nico Förster (software developer) as the product owner. The scrum team primarily consisted of the three students, Marco Gotthans (scrum master and developer), Paul Bachmann and Johannes Thies (both software developers), who faced the following challenge:

The requested software is to assist the user with the selection and ordering of pizza. For this purpose, the menus of three pizza delivery services in Görlitz have to be stored in the program, including special features such as pizza packages and discounts. The user can specify the number of persons and the average quantity of pizza eaten, and then obtains an optimal pizza order based on this input (best possible price-performance ratio) for each of the

three pizza restaurants. Since this order covers the demand for pizza, but likely lacks variety, the user is to be given an opportunity to shuffle the result. This way, different pizzas are selected on a random basis, such that the order still covers the demand, but may be a little more expensive. The software is furthermore supposed to be able to observe a maximum amount so as not to exceed a defined budget. The last specification was for a possibility to save orders placed so they can be called up again at a later time, e.g. for billing purposes. The students were given free choice regarding the technologies used, and they chose a Spring application with a web front end. The following software stack was used: Java, Spring Boot, Hibernate, H2 and MySQL database, Thymeleaf, Lombok, HTML, and JavaScript.

Already at the end of the first iteration, the team was able to present a surprisingly comprehensive software product to the product owner. The look of the web front end was immediately captivating because it was based on the design of the Saxonia website. Once the increment had been approved by the product owner, the requirements to be implemented with the next software increment were presented. Any questions that arose were clarified together, and problems and methods were discussed. In the subsequent retrospective, the scrum team received valuable assistance from Michael Klose (software developer at Saxonia), whose many years of project experience and whose presentation of various versions of the scrum retrospective were a valuable contribution to the practical project.

With each two-week sprint, the functionality of the application increased, much to the product owner’s satisfaction. Tests and trial orders showed that a few bugs had occurred, and the scrum team itself felt the need to refactor (improve and anneal) the program code. The refactoring was impeded by the lack of software tests (unit tests) that could have prevented some bugs, in particular in the computational logic. At the team’s request, Michael Klose and I also carried out a code review, the results of which were gladly accepted, and corresponding improvements were made.

The final product was presented both at the final presentation at the Zittau/Görlitz University of Applied Sciences and within the framework of a meeting at the Saxonia Systems premises in Görlitz. All the reactions were positive, and the team received well-earned praise for their good work. Showing the students the benefits of tried-and-tested software development methods such as scrum, test-driven development, clean code and refactoring was particularly important. In the end, the intensive support provided by Saxonia, which far exceeded that which the university required of the company, paid off. The students were able to gain valuable practical experience, and in return, Saxonia got an optically and functionally excellent product.

Successful collaboration between students of Zittau/Görlitz University of Applied Sciences and Saxonia Systems!

Couples Therapy – Successfully Integrating Service Providers

In a survey carried out by Capgemini (Capgemini Consulting, 2016), the respondents stated that the biggest obstacle for digitalization in their company was “Too few employees with relevant know-how”. It is not uncommon to try and overcome this problem by integrating one or several external service providers. The same survey furthermore shows that these service providers are increasingly used in areas or projects where innovative solutions are to be developed. It is likely in this context that an average 23.3% of the respondents already use agile frameworks, methods or philosophies such as scrum, Kanban, DevOps, or the Scaled Agile Framework in their projects.

As a service provider, we have already been relying on agile methods for a long time. Since 2013, we have formed mixed teams involving the client and the service provider according to our concept of distributed agile development, ETEO (German for “One Team, One Office”), and we provide tools and good practices to assist these teams during the initial unfamiliar work situation. The concept uses the results of a survey of our teams that had already been working according to this model, and it was subsequently further developed on a scientifically sound basis by a cross-functional team, with new findings from our teams continuously being integrated.

In our case, the team is assembled in a project room. The physical rooms (typically 2-3) at the distributed locations are connected via permanent video conferences. Each location preferably has an 80 inch screen, creating the impression that you see the other part of the team through a window.

A tool that we work with both in our teams and in external coaching sessions is the ETEO Value Compass, which combines the five scrum values of openness, commitment, focus, respect and courage, along with additional values that appear to be essential, particularly, but not only in distributed teams: identity, trust, empathy, collaboration and simplicity.

During the coaching, we usually ask the teams which of the values is most important to them. Not surprisingly, many of them say that the value of trust is most important. In his book “Five Dysfunctions of a Team” (Lencioni, 2002), Patrick Lencioni stated that trust is the basis for any kind of collaboration in a team. And ultimately, the individual values also appear to affect each other. Openness in the team, for example, creates trust. And with scrum, where it is not the individual contribution, but the team performance that counts, committing to a common sprint goal is possible only if everybody trusts everybody else.

But how do you build trust in a distributed team that rarely meets in person, where a little misunderstanding cannot easily be resolved over lunch or a cup of something hot in the communal kitchen? Unspoken issues can quickly spark conflicts, disturbing or completely destroying the trust within the team.

Couples therapy

This is why it is particularly important to get to know each other during an extensive, 6- to 8-week attendance phase, during which you learn to assess each other. Written, asynchronous communication, e.g. by email, can easily cause misunderstandings. The permanent video conference has proven to be highly useful in this context because it allows everyone to see who is present and how they apparently feel. Still, even with a video conferencing system, you should be careful not to use it exclusively for the professional exchange. Once trust has been damaged, it is surprising to see how even a small verbal or non-verbal signal can cause what is left of the trust to be completely shattered. In one of our project teams, for example, the team members in one of the locations used to lean back against the table behind them during the video conference for the daily scrum meeting because it was more comfortable for them. The colleagues at the other location, however, stated that this appeared as a threatening front to them. Such misunderstandings happen in particular if you fail to invest in strengthening trust, and the team does not meet in person at regular intervals (every 6-8 weeks).

Doing each transition from one sprint to the next at the same location is even better. This also offers an opportunity to do the sprint retrospective in one room together—a serious advantage in a meeting where the trust within the team generates a significant added value. Trust is the foundation for mutual respect and for the courage to realize the potential for improvement within the team with creative, innovative solutions.

Working with a common value system is just one of the challenges you face when you want to integrate an external service provider. We will address this issue in more detail in our presentation “Darling, I’ve met someone new – Successfully integrating service providers” at the solutions.hamburg conference. The track „Couples Therapy 2.0“ provides additional exciting insights and therapeutic approaches from the intriguing field “IT meets business”.


References

  • Capgemini Consulting. (2016). IT Trends 2016. Retrieved at capgemini: https://www.de.capgemini.com/resource-file-access/resource/pdf/capgemini-it-trends-studie-2016_0.pdf
  • Lencioni, P. (2002). 5 Dysfunctions of a Team. Jossey-Bass.

The Agile Test Manager – An Oxymoron? (Part 3)

In the first and second part, we successfully completed the agile transition of the test manager’s responsibilities, and we proved that small scrum teams no longer require a test manager. Several scrum teams working together on the same product pose another challenge. Can the previous observations made with respect to a small scrum project with a single team also be adopted for large projects?

Do we need a test manager for large scrum projects?

In many companies that use scrum, several teams work together on the development of the same product. There have already been some thoughts regarding scaled scrum on the company level and how it is possible to comply with agile principles even as the level of complexity increases. In this context, Boris Glober identifies two problematic areas: “compliance with the scaled scrum framework” and “scaling of the requirements process”. To solve this, he introduces additional roles: the company scrum master and the company product owner, who assist all the scrum masters and product owners of the project. Both roles coordinate with their counterparts in the individual scrum teams, and they manage the scrum tools on the company level, such as the company product backlog and the company scrum board.

Can this concept be adopted for testing as well, i.e. do we need something like a company test owner or a company QA master? The purpose of this new tool would be the coordination of and responsibility for the overall, integrative testing process, establishing the necessary common test structures, and filling the backlog with stories, tasks and incidents relating to QA.

Coordination meeting on QA issues
Figure 1: Coordination meeting on QA issues

For projects with a manageable number (2 to 8) of scrum teams, this kind of coordination can be done within the framework of the general coordination meeting, the scrum of scrums. If the coordination becomes more test-specific and time-consuming, it is advisable to establish a separate test meeting as required. Each team sends a team member with the necessary test know-how to this meeting. If the number of teams is higher, or if coordination between several projects is required with respect to QA issues, the guilds can again be used for this purpose. The guilds collect examples of best practices that they provide to all the projects, or they appoint coaches who bring agile testing methods to new projects. The guild masters agree on important decisions and moderate the scrum teams wherever it is necessary to define common rules and solutions.

We can conclude that agile companies no longer need a test manager, even for large projects. However, this is possible only by way of a complete agile transition of the test manager’s responsibilities because each of the test manager’s responsibilities—in particular with respect to communication and coordination—has to be matched with an agile tool.

The Agile Test Manager – An Oxymoron? (Part 2)

In the first part, we successfully completed the agile transition of the test manager’s operative responsibilities, and we proved that small scrum teams no longer require a test manager. But will this work for the test manager’s strategic responsibilities, too? And who assumes the test manager’s strategic responsibilities?

Who assumes the test manager’s strategic responsibilities in agile companies?

A test manager’s strategic area of responsibility includes quality management (QM), which, according to ISO 8402, comprises “all activities of the overall management function that determine the quality policy, objectives and responsibilities and implement them by means such as quality planning, quality control, quality assurance and quality improvement within the quality system”.

Figure 1: Responsibilities of the test manager (according to the ISTQB)

Irrespective of whether a company uses traditional or agile methods in development, the company’s management is responsible for the quality management. The scrum team cannot, should not and must not assume this responsibility. At first glance, nothing in the organization and the division of responsibilities changes. At second glance, however, a problem arises for agile companies. In the traditional world, the test manager used to act as the interface between the operative and the strategic level. They transmitted information between the management and the operative level, passed strategic specifications and methods on to the test teams, or forwarded developments and improvements to the management.

But how does information get transmitted from the strategic to the operative level and vice versa in an agile environment? The answer: The agile transition does not stop with the allocation of the test manager’s operative responsibilities to the scrum team. The solution for the agile transition of the “interface” between the two levels is similar to the agile transition of the test manager’s operative responsibilities. New concepts and tools are available for the current corporate communication tasks.

One of the new concepts is the so-called guild. Guilds (called competence teams in our company) are a tool that puts and keeps knowledge and information management on track. They are organized in a matrix structure apart from the normal company structure. The objective of the guilds is to pool the company’s know-how carriers, offer the staff a platform to exchange knowledge or carry out training programs, or agree general project decisions such as the development of test environments or rules for code quality. Depending on the company’s goals, the structure and composition of the guilds can differ: For example, guilds can be divided according to competence areas such as Java development, .NET development, test or process analysis. Or entire scrum teams can be aggregated in guilds, working together on a specific subject in the project, such as QA, database connection, GUI, or interfaces (see Figure 1).

Figure 2: Example of classification and structure of the guilds by competence area

The guilds work according to the following pattern: The primary role that each employee assumes in their daily work (e.g. developer, tester [QAlas], product owner and scrum master) is determined. With this role, they are allocated to a corresponding guild. Within the guild, the members exchange information relating to their areas of responsibility, carry out in-house training seminars, collect the available knowledge in portals, or discuss best practices in individual projects. A guild master is responsible for the moderation and coordination within the guild. In accordance with the motto “primus inter pares”, they do not have more rights than their colleagues in the guild, and they are elected from among the guild members. The guild master is the principal contact for the members of their own guild, the other guild masters and the management. This is necessary because the guilds engage in active interdisciplinary exchange, and they are also supposed to forward feedback from the operative level—such as new developments or technologies—to sales, or suggestions regarding training seminars to HR.

In the last part, we will look at what happens when several scrum teams work together on the same project and the effort required to coordinate them increases for the field of QA as well.

The Agile Test Manager – An Oxymoron? (Part 1)

Some time ago, a colleague of mine asked me whether we still needed a test manager in an agile development process like scrum. My first response was no because the Agile Manifesto and the scrum framework only know three roles: product owner, development team, and scrum master. Accordingly, the scrum team—i.e. the three scrum roles mentioned above—does not provide for a test manager. But on second thought, I wondered who among the scrum team was supposed to assume the test manager’s responsibilities in and around the sprint?

Studies such as the 2014 ASQF Industry Report[1] and the 2011 Standish Chaos Report show that agile methods have already become a permanent fixture in companies. Furthermore, the Standish Chaos Report shows that projects using agile processes are more likely to be successful than “conventional projects”.  The Agile Manifesto of Ken Schwaber and Jeff Sutherland was the basis for this development. It defines basic principles and specifications that uncover “better ways of developing software by [the parties involved in the process] doing it and helping others do it” [²].

Scrum process and parties involved
Figure 1: Scrum process and parties involved

The key principles from the Agile Manifesto are:

  • Individuals and interactions are more important than processes and tools.
  • Working software is more important than comprehensive documentation.
  • Client collaboration is more important than the original specifications.
  • Responding to change is more important than following a plan.

Companies that switch to the agile method of development have a competitive advantage compared to companies using traditional methods. However, transitioning the processes to development methods such as scrum—also called agile transition—presents a great challenge. Agility is not achieved by divvying the development milestones up into sprints and appointing a product owner (see Figure 1). Comprehensive changes in the organization are required to achieve an agile way of working and living.

The challenge of the agile transition becomes very clear when you look at the example of the test manager. The question:  If we do not need a test manager in scrum, who assumes their responsibilities? The product owner? The scrum master? The team?

According to the Scrum Alliance, the product owner is the person responsible for developing the product accurately and on time. The product owner fills and refines the product backlog, and ensures that everybody knows what it contains and what is given which priority. Consequently, they are usually closest to the “business side” of the project. Scrum requires the development team to be a group with mixed functions—pooling all the necessary skills—that are required for the development of the product. The team organizes itself, i.e. it independently chooses the content to be implemented in the sprint and takes care of the planning, management, and implementation. The scrum master is the “pilot” guiding them through the depths of the scrum framework, helping the rest of the scrum team to comply with scrum principles. Another task of the scrum master is removing obstacles that hamper the team’s progress

Even after studying the scrum roles, we do not know who assumes the test manager’s responsibilities, or how they are allocated. To answer these questions, we must first determine the test manager’s responsibilities in the traditional testing and quality assurance process. According to the International Software Testing Qualifications Board (ISTQB), the certification board for testers, the test manager’s role and responsibilities include more than just supervising the test project. They manage the testing department or the test team, and thus, the resources for the tests. They prepare reports; escalate to development, technical department and project management; assess test projects; ensure compliance with the company’s quality processes; procure the testing tools for the organization; and review the test plans and the test cases.

The responsibilities can be allocated to two fields: strategic and operative (see Figure 2). The operative level includes the planning and conceptual design of the test cases and tests, monitoring the execution of the tests, and the communication within the project. The strategic level includes the quality management tasks.

Responsibilities of the test manager (according to the ISTQB)
Figure 2: Responsibilities of the test manager (according to the ISTQB)

The operative responsibilities cannot be assumed by the scrum master or the product owner. The product owner does not get involved in the implementation, nor the scrum master in the development. In agile development, the testing tasks are assumed by the team. Following the definition and allocation of the test manager’s responsibilities, we can examine how they can be integrated into the agile process. However, there is a problem: It is not possible to allocate them to a specific person because within the scrum framework, all tasks are distributed across the agile team.

The solution to the problem lies within the scrum framework itself. It provides a comprehensive package of tools and artifacts that can be matched with the test manager’s responsibilities. We did a complete agile transition of the responsibilities in our scrum teams, and we found that scrum provides a tool or artifact for every one of the test manager’s responsibilities.

Agile transition of the test manager – test coordination
Figure 3: Agile transition of the test manager – test coordination

For example, the test strategy and the paramount quality characteristics are considered during the planning of the sprint and the backlog grooming. The pass-fail criteria, i.e. the criteria that determine whether a sprint has been successful or the test has been completed, are defined in the definition of done (see Figure 3).

Agile transition of the test manager – test implementation
Figure 4: Agile transition of the test manager – test implementation

In the sprint review, the implementation of the specifications is verified and validated (see Figure 4).

Agile transition of the test manager – test coordination
Figure 5: Agile transition of the test manager – test coordination

In addition, the stories and their representation on the scrum board and in the backlogs facilitate documentation of the progress and the assessment of the quality level (see Figure 3).

Accordingly, there is an agile tool or artifact for each of the test manager’s responsibilities. And thus, complete agile transition of the test manager’s responsibilities is achieved. Provided that the scrum team has the testing know-how required for the implementation of the upcoming development and testing tasks, small projects do not require a test manager. If the know-how is not yet given, the team has to be coached accordingly.

In the next part, we will examine who can assume the responsibilities on the strategic level, and what happens in projects where several scrum teams work on the same product together.