A day in the life of a Configuration and Technical Change Manager in an Agile Organization.

Co-Authors:??Florian B?hme ?and?Lucas Heckmann

In the fourth edition in the?CM+Agile series ?we will take you through a day in the life of a configuration and technical change manager in an agile organization.

Daily Standups: Checking the Config and Software Release Status

The day started like any other at Cargile, an agile car software company. As the Configuration and Technical Change Manager, my first task was to check last night’s automated software release status report from our Application Lifecycle Management (ALM) tool and communicate issues in the daily standup of the supporting release process team of my Agile Release Train (ART a.k.a. Team of Teams) and product teams .

This report is supposed to collect the latest data from all the development departments – Requirements Management, Architecture Management, software teams, and others – working on the next major system software release which will be distributed to vehicle projects in the field.

But as usual, there were issues. The baseline data wasn’t complete. Requirements Management hadn’t submitted all the necessary information as part of their tool baseline, and in turn Architecture’s models were not updated. This was a big problem because I couldn’t tie the baseline data back to the release, which is important to track everything and make sure it’s all connected. Without that, I didn’t know if the software was ready for the next design review. I had to raise a problem report to the requirements management team with high urgency.

What did we learn…

Tracking the status of the build is critical to understand the status quo. To do so all information must be available, on time, properly identified, linked, owned, validated, and released. If not, it will be very difficult to make the right decisions and stay on track with product development timelines.

Change Management Awareness Session with Scrum Team

In our 15 Scrum team Product Management Team (PMT) sessions, I focus on the basics of Technical Change Management and its importance. I explain that tracking changes, even in Agile teams, is essential to prevent unexpected issues and manage costs. Each change should be documented through a Change Request (CR), which outlines the change, its impact, and the required time. Also, changes shall be linked to software items that lie in the team’s responsibility?and might have dependencies with software items that are owned by other teams. I explain how scrum teams must review and approve these CRs in standups or planning events, ensuring that changes are necessary, well-planned, and cost-effective.

What did we learn…

Communication of the Why of CM is key. People need to understand why they need to create a Change Request or why an impact analysis is important. What is the value and what could go wrong if you don’t? Change is the only constant in an organization, so you best make sure you pick the most valuable change proposals to implement.

Morning Meeting: Agile Release Train Change Control Board

Later, I headed into our agile release train Change Control Board (CCB) meeting (some people will use the Backlog Refinement for this) with the Product Management . We needed to decide which new features from the portfolio management would go into the next update version of a specific software release. Of course, this requires high coordination with the project management teams of the vehicle projects and with the testing and validation department, e.g. to check if the required test beds and resources are available to check possible compatibility issues with all possible vehicle field configurations.

But things didn’t go smoothly. We quickly realized we didn’t have reliable baseline data, so we couldn’t tell how the changes would impact the existing software. It was hard to say which product teams or release trains were responsible for different parts because a lot of the product data hadn’t been tracked correctly. There were strange software components that weren’t linked to anything. We have to investigate their origin and designated use.

As a Configuration Manager, this was frustrating. My role is to ensure that everything’s in order, but without the right data, I couldn’t help the team make decisions. By the end of the meeting, we were stuck. We didn’t have enough information to make any clear decisions.

What did we learn…

Configuration Management can only be done well if all the information is there and traceable as it should be: Identified, linked, owned, validated, and released. Only then can you become truly agile. Otherwise, you will keep firefighting and fixing problems, which is just creating a lot of frustration. Where Agile frameworks fall short of properly synchronizing many teams working on complex products, CM helps to coordinate the activities of different teams working in parallel.

After Lunch: Big Problem with OTA Update

After lunch, I got an urgent message about a problem with the latest release for the premium segment. The over-the-air (OTA) update for the infotainment system had caused major compatibility issues. Instead of fixing performance and adding features, the update was breaking the system in some cars.

Tesla owners reported that their?cars did not start after an update , had to get towed, and even required hardware replacements to fix them.

?

I got pulled into an emergency task force to figure out what went wrong. As we dug into the details, we found out that the testing and verification team hadn’t used the latest configuration of test benches and the latest baselines from the supplier. This meant the testing was basically useless, and the release should never have happened in the first place.

I quickly raised a high-urgency change and problem report to let the organization know about the issue. We had to delay and pause the scheduled update immediately and investigate how many cars were affected.

What did we learn…

In an agile DevOps environment, the test team should not have been able to use the wrong version of the baseline. Using a different version other than the latest should be a conscious choice, not a mistake. Baseline releases should be communicated and distribution must be planned. Now a lot of time has been wasted and a potential recall is needed to fix the problem. Whereas baselining is an easy way to support the coordination of the activities of differen teams and ensure consistency.

Afternoon: Planning Preparation

Preparing for the next Program Increment (PI) planning as a Configuration Manager requires experience and coordination with other teams. First, improving how our latest methods harmonize with other support processes like quality management and DevOps teams. This will help with tracking and managing changes more effectively and solving audit reports that were raised some time ago.

Second, I need to estimate the resources for managing baselines, attending Change Control Boards (CCBs) / refinement meetings, and dealing with urgent issues through task forces. For this, I prepare alignment with the Product Owners and Release Managers to determine the number of features and releases scheduled for implementation. For example, if the customer requests a large feature to be delivered across multiple small releases instead of a big release, I typically need extra support.?

With the upcoming specialized Advanced Driver Assistance Systems (ADAS) software product release, which must fulfill very strict regulations, alignment is especially important. We’ll need additional resources, budget, and time to meet the complex regulations for autonomous driving, ensuring everything is traceable and compliant.

However, while our product management wants to push forward quickly due to market pressure, I’m not sure we’re fully ready yet. Our tools and processes still need improvements and rushing could fall back on our feet. In the PI planning, I will raise these concerns in breakout sessions, suggesting a balanced approach that ensures quality while meeting deadlines. Agile methods are great for pivoting towards the path that generates the most value, but maintaining strong configuration management is critical for delivering reliable products in the long run and being fast and efficient.

What did we learn…

A good configuration management plan is required to ensure the right outcomes, even more so in a highly regulated environment. Fail fast, Ask questions later is not the way to go. You can achieve quality and time-to-market goals, but only if you are serious about configuration management.

End of the day: Retrospective

By the end of the day, it was clear that having reliable data as well as mature methods and tools is important.

What could be improved?

Agile is great for moving forward and adapting fast, but you need to have a solid foundation to make sure what you’re delivering is reliable and high-quality. The OTA update issue showed how easily things can go off track when the foundation isn’t solid (also read Software Over-the-Air Updates and CM ).

Lessons learned

In a fast-moving environment like ours, Configuration Management, even though it's usually seen as shared service ,? is what keeps everything tied together (like glue), ensuring we are delivering the right product, at the right time. Without it, even with agile methods, things can quickly go off track.

Ultimately, my job is not just about tracking software versions; it's about ensuring we deliver the right product (configuration) while staying agile and ready for the transformation of software-defined products. That means not only focusing on the features or fixing bugs (short-term value), but also on tasks that improve the performance of the teams (long-term value).

Action items for next sprint (day)

• Increase awareness of CM with Product Management
• Improve my prioritization and take breaks, this day has been packed!
• Improve baseline deployment to all the teams
• Use the Change Request as a vehicle to communicate with other teams

This article was originally published on mdux.net .

Don't forget to subscribe to this newsletter and follow me !

Disclaimer

?