Implementing SAFe with Jira (part 2)

This is part 2 about implementing SAFe with Jira. In part 1 I explained how we implemented the portfolio, program and team backlogs as the 3-layered structure of SAFe in Jira. You may recall that we renamed them to business, system and product levels. In part 2 we will dig more deeply in connecting the layers.

Structure plugin

Since Jira (core) is not able to visualize linked relationships, we use the Structure plugin from ALMworks. On a structure board, you can add Jira issues, you can sort them and put them in a hierarchy (i.e. an issue nested under its parent issue), manually by drag-and-drop or automatically by synchronizers. A synchronizer interprets the data in Jira (e.g. a filter, Epic link or issue links) and puts the issues in the structure at the right place. Synchronizers work bi-directional. For example, by adding or removing a link the synchronizer places the issue on the right place in the structure, and by changing the place of an issue in the structure, the synchronizers adds or removes links in Jira.

So if we have a business epic -> system epic -> product epic -> product story -> subtask relationship (through Epic links and Issue links of the “Implement” link type), the Structure board visualizes the hierarchy structure as nested issues. By adding the columns on the Structure board (through views), you can see, check and even change the value of a Jira issue. For example, when a release on team level is later than the release on program level, you can easily see this by looking at the FixVersion/s column.

One of the features of the structure plugin is its time tracking capabilities. The plugin is able to aggregate the planned and actual effort (original estimate, remaining estimate, logged work) over items in a structure. For example, if an epic contains 4 stories each estimated at 3 days work, and the epic itself requires an extra 1 day work, the estimate of the epic is 13 days work (4 * 3 days + 1 day).

There is a lot more to say about using the structure plugin and its synchronizers. I may come to that later.

Agile Release Trains (ARTs), Program Increments and Sprints

An Agile Release Train (ART) is planned and organized in iterations called Program Increments (PIs). We define 2 PIs per year, corresponding with the commercial windows of product marketing to the market. In fact, we don’t even use the term “Program Increment” and call them “windows”. Each PI (window) consists of 3 releases, and each release consists of 4 sprints. In Jira, PIs (windows) and releases are defined in the FixVersion field and sprints are defined in the Sprint field.

  • Business backlog items are planned in windows: W1/2015, W2/2015, W1/2016, …
  • System backlog items are planned in releases: 1.1, 1.2, 1.3, 1.4, …
  • Product backlog items are planned in releases (1.1, 1.2, …) and assigned to sprints

As you can see development and releasing are both on cadence. SAFe says “develop in cadence, release on demand”, but since we come from a traditional stage-gating world, releasing in cadence is a old habit. We may change that in the future.

Portfolio/business level and program/system level have no sprints; they use Kanban, which represents a continuous flow of input (new items) and output (closed items). On team/product level we do use sprints with Scrum. Typically, sprints are 2 week time-boxes. The name or numbering of each sprint is dependent on the team; sprint 6 for one team may not coincide with sprint 6 of another team. But by using separate projects in Jira for portfolio, system and for each product team, each project may have their own set of version values and sprints in Jira. This requires some alignment between system and product level, because we want the release numbers to be the same for all projects, at least for now.

Of course, our world is not ideal. We have teams with a different iteration lengths and we even have teams that do not even follow Scrum, e.g. hardware development. That is okay as long as they are able to deliver for and integrate with the release.

The Structure board shows the hierarchical relationships from portfolio to system to product level. The fixversion column shows the windows and releases and the sprint column shows the sprints, so we can spot inconsistencies easily. The estimated effort column shows the aggregated effort and the story points column shows the aggregated story points. This helps us decide about the release content. And the progress bar shows the aggregated progress of a portfolio item and all its descendants. That way, we can visually check the consistency and progress.

Agile release train (ART) planning

Before a release starts, we have an ART planning session, which we call the “release train workshop”. The portfolio backlog in Jira containing the  business epics on the strategic roadmap for the coming years, specifies the business epics for the coming window. Since we have 4 releases per window, we don’t need to do everything in a single release. But the question is: how much can we do in this release?

The first step is to divide the portfolio items (epics in the Portfolio project in Jira) into multiple system items (epics in the System project in Jira). Typical system epics are a minimum viable product (MVP) of the business epic and successive increments.

After putting them in Jira, they need to be estimated: how much capacity does it require from each of the teams for each of the system epics? In Jira, you only have one estimate field per epic, so that is insufficient to capture the individual estimates of each team. So instead of trying to extend the system epics with extra custom fields, we make epics in the Jira projects for the product teams and link the product epics to the system epic with an “implement” issue link. Through the structure plugin, the product epics show up underneath the system epics and the estimate column (or story point column) shows the aggregated effort (or size) of the product epics for the system epic.

Unfortunately, Jira (or better, the structure plugin) does not allow us to extract the aggregated data to reports or even to queries.

Having these estimates brings us to the next question: will it fit the release? Accumulating the estimates of the system epics for the release may give the impression that the total capacity of the teams is able to cope with the total amount of work for the release. But fortunately, it is not a realistic approach either. If one team is overloaded, the release cannot be completed in time anyway. So a better metric would be to look at the total estimate for each team for the release. And since the estimates for a team are all in the same Jira project, it is easy to create a report that shows the totals.

Knowing the total estimate per team allows us to decide whether the release content fits. Of course, we are running into the situation that it does not fit! In those cases, the MVP definitions may even be reduced further and the estimates need to be redone. So in practice, the information is not actually entered in Jira until there is sufficient consensus about the feasibility of the release content and the estimates. Jira is not a planning tool and does not allow the dynamics of what-if scenarios; I wish.


In part 1 I described how we have implemented the 3-layered backlog structure in Jira. In this part 2 I have made the first step of making use of this structure to deal with release content and estimation. Part 3 will take us to the next step. If you have ideas what next step you would like me to focus on, feel free to let me know.

Posted in agile, complex systems, large projects, project management, systems, tools | Tagged , , | 11 Comments

Implementing SAFe with Jira (part 1)

In this article I am not going to explain what the Scale Agile Framework (SAFe) is and what Jira is. I assume you know, and if you need more information go to and

But before we start, there are a few things that are important to know:

  • Jira is not designed for agile development. In essence it is an issue tracking tool. You need plugins to added support for Scrum/Kanban. Currently, there is no plugin for SAFe support.
  • SAFe is not a prescriptive process model. It is a framework. You can implement it anyway you like, leaving out what does not work for you and adding thing that you need.

My experience with SAFe and Jira is based on the implementation of SAFe (with Jira) with a customer I worked with in a development and innovation organization of a large, multinational technology company for commercial products for consumer and professional markets. It concerned development of software (embedded and applications), hardware (controlled by the embedded software) and other disciplines (e.g. mechanics, optics). In this article, I will try to guide your through our thought process so that you might understand why we made our choice.

Implementing the 3-layered model of SAFe

SAFe (v3.0) defines a model with 3 layers:

  1. Portfolio layer – for managing the business epics
  2. Program layer – for managing the release trains
  3. Team layer – for managing and executing the development activities

For us this was confusing. Teams exist at all levels, so we renamed “team” level to “product” level. This may suggest that teams directly deliver commercial products to the market like an ordinary Scrum team, which some teams actually do. However, all teams deliver to system integration to build integrated systems for the agile release trains (ARTs).  Therefore, we renamed “program” level to “system” level. And finally, we call “portfolio” level “business” level, although we also use the term “portfolio”.

So we have the 3 layers:

  1. Business level – for managing the business epics and architectural epics
  2. System level – for managing the release trains
  3. Product level – for managing and executing the development activities

On each level we have a backlog as SAFe defines: portfolio backlog, system backlog and product backlog. Each backlog has backlog items. SAFe defines 3 types of backlog items:

  1. Epics – on portfolio level
  2. Features – on program level
  3. Stories – on team level

In later parts of the article, I will extend these backlog items types for defect management.

To get agile support in Jira, you need the Agile plugin. This plugin support Scrum and Kanban boards, and several reporting extensions such as burndown charts. Scrum defines a “product backlog” which nicely corresponds with the product backlog we defined at team/product level. The Scrum board (in plan mode) has epics and stories (and potentially other issue types). Stories (and other issue types on the Scrum board) can be linked to the epics, and these links nicely show up on the Scrum board as colored links.


  • Jira Scrum boards do not support features according to SAFe
  • Epics on the Jira Scrum boards are not corresponding with business epics according to SAFe

The development teams were already used to epics and stories on team level in their product backlogs according to the Scrum approach with Jira. According to SAFe, multiple teams (on team level) may be working on the same epics and features (on program and portfolio level). So we had to find a solution for implementing business epics and features. We saw a number of alternative solutions:

  1. Define extra issue types on portfolio level (e.g. Themes), put epics on program level and stories on team level (see Sander Brienen [2013]),
  2. Define a project for the business epics with a Kanban board on portfolio level, and projects for the Scrum teams on team level (see Agile plugin documentation).
  3. Define a project with a Kanban board on portfolio level, a project with a Kanban board at program/system level and projects for Scrum teams on team/product level (see Agile plugin documentation).

We chose for solution #3 because it allows us to use the same approach supported by the Agile plugin (e.g. the Scrum and Kanban boards) on all levels. Every level has epics and stories (and other issue types) linked to epics, every level has a backlog reflected on a Scrum or Kanban board, every level has the standard reporting capabilities, etcetera. Users don’t need to learn new ways to work with Jira when they use the backlogs of other layers or teams.

Given our translation of portfolio/program/team levels into business/system/product levels, this comprised into:

  1. Business project – contains business and architectural epics (and stories) with a portfolio backlog workflow and a Kanban board
  2. System project – containing system epics (and stories and other issue types, e.g. defects) with a system backlog workflow and a Kanban board
  3. Product projects (short for Product development projects) – containing product epics and stories (and other issue types, e.g. defects) with a product backlog workflow and Scrum boards

Implementing relationships between backlogs

Now, within a Jira project we can use Scrum or Kanban boards to view and manage the relationship between epics and stories (and other issue type). For example, on the Scrum board in plan mode you can drop a story (or an issue of another issue type) on an epic to set the Epic link. As a result the Scrum board shows a colored link on the story, and you can do all kind of nice reports as supported by the Agile plugin.

However, we need to relate the product epics (on the product backlog)  with the system epics, and the system epics (on the system/program backlog) with the business epics or architectural epics (on the portfolio backlog). We do this with an “implement” link, which is a bidirectional link (“is implemented by” / “implements”). (See also Sander Brienen [2013]).

So we use 2 link types:

  1. Epic link – for agile relationships within a Scrum team
  2. Issue link of link type “implement” – for backlog relationships across SAFe layers

The Epic link relationships can be viewed and managed through the Scrum boards provided by the Agile plugin. But Scrum boards cannot visualize or manage issue links. For that you need to open the issue and view/manage the issue links in the issue itself. For example, when you open an epic you see a block with “Issue Links”  and a block with “Issues in Epic”. But to visualize and potentially manage the relationship of product stories linked to a product epic, linked to a system epic, linked to a business epic, you need the Structure plugin. The Structure plugin is a powerful plugin, but also a nasty beast. I will tell you about it another time.


Having backlogs and backlog relationships in Jira in place is only the beginning of the implementation of SAFe with Jira, but it is an important foundation. One of the challenges is of course how to work with the information and with Jira to make the release trains and the development teams effective. There is a lot more to tell, but I’ll have to wait until part 2.

Posted in agile, complex systems, large projects, project management, software development, systems, tools | Tagged , , | 5 Comments

Nieuwe vleugel bij het CKE – Fazioli

Gisteren moest ik op de muziekschool zijn om een vioolleerling te begeleiden op piano. Het was de laatste repetitie voor het examen volgende week. Terwijl we wat stonden te kletsen kwam haar vioollerares naar me toe. Ze had de sleutel van de concertzaal bij zich, met daaraan een grote sleutel. Ok, dacht ik, we spelen op de vleugel. Hier, zei ze veelbetekenend, een verrassing, en ze overhandigde de sleutels aan me. Nog altijd niks vermoedend ging ik voorop naar de concertzaal.
Daar, midden op het podium, stond een vleugel met een gekapitoneerde afdekhoes er over. Fazioli stond er op. Hmmm een nieuwe, dacht ik, maar waar is de Steinway? Onder de afdekhoes, zwart met een prachtig rode binnenzijde, verscheen een schitterende zwarte vleugel van concertformaat. Ik denk wel ruim twee en halve meter lang.

Ik ben er achter gaan zitten. Mooie toetsen, niet wit maar een licht romige kleur. De eerste voorzichtige tonen klinken mooi. Maar ja, van een nieuwe vleugel verwacht je dat ook. Maar het leek wel meer dan mooi. Dan maar een paar maten van de begeleiding. Mooi! Heel mooi! Fijne aanslag. Dan maar een stukje Reflet dans l’eau van Debussy. Als boter zo zacht kwam de warme klank uit het instrument. De noten gleden uit mijn vingers als vanzelf, zo gemakkelijk, zo egaal. Moeiteloos dansten mijn vingers over de toetsen, die precies stroef genoeg waren naar mijn smaak. Geen enkele oneffenheid in de aanslag, een perfecte klank, mooie romige klank en nog veel mooiere bassen die zwaar grommend en mysterieus aanzwelden. Dit is een hemels instrument. Alles gaat zo makkelijk, zo licht maar niet te licht, volkomen egaal en perfect. In combinatie met de op dat moment vrijwel lege concertzaal was het alsof ik in een droom verzeild was geraakt.

En de Steinway? Die was ik al lang vergeten. Die mag dan de reputatie hebben om de beste ter wereld te zijn, ik heb die altijd als veel te direct en onvergevingsgezind gevonden. Geen instrument voor begeleidingen maar voor solopartijen. Deze Fazioli is daar perfect voor. Past precies bij mijn smaak en mijn spel. En ja, de repetitie was werkelijk een genot om te doen op “mijn” Fazioli. Mag ik ‘m echt houden, vroeg ik nog, maar dat zat er helaas niet in.

Posted in music | Tagged | Leave a comment

How to double your money?

In this article I am not talking about doubling your revenue or profits, I am going to focussing on doubling your costs. Why? Because nothing is for free: if you want to earn more, you need to pay more. And because you have direct control over your costs, not over your earnings. Like in darts or archery: you have control only until you release the arrow.

Suppose you are managing a small racing team. You are spending 1 million on the car and 5 million on the driver. If you double the money on the car to make a better car you will win more races, and if you double the money on hiring a better driver you will win more races too. Which one would you choose? I would choose doubling the money on the car. It will cost you 1 million extra, not 5 million.
Now suppose you are running a production factory. You are spending 1 million on machines and robots and 5 million on workers. If you can increase your production, where would you double your money? Again, I would double the amount of money on machines and robots. In fact, most car manufacturers are spending over 90% on equipment.

Well it is not always that obvious. System and software development is a knowledge industry. People are the most valuable assets, but also the most expensive. It is no exception when 10% of the costs are spent on tools, such as licenses, servers and support and maintenance, while 90% is going to the engineers, architects, testers and project managers. No development manager will approve doubling the costs on tooling. It is considered as “overhead” costs and overhead should be minimized, not increased. But he is willing to spend even more money on better training, process improvement initiatives, metrics programs and new methodologies. Workers in projects are allowed to spend a considerable amount of their time on implementation and deployment of better processes and tools, time they do not spend on actually developing the system or software.

Why is that? Why is a factory manager willing to spend over 90% on equipment to maximize productivity of the factory, while a development manager is not willing to go beyond 10%. If people cost 10 times more than tools, an increase of 10% on the people would be equivalent of an increase of 100% (doubling the money) on tools. Which one would ultimately be more effective for the organization?
I argue that if you spend 90% of your development costs on tools, tool integration and automation, and 10% on the best possible teams that you can buy, where the people can fully focus on the intellectual work that cannot be done by tools, the organization would be far more effective in speed and delivering quality than any organization with the reverse ratio.

Of course, you should not double the costs of tools and equipment blindly. But in system and software development there seems to be a taboo on doubling the “overhead” costs even if that would be more effective than spending even more money on improving the capabilities of people.

Posted in integration, people, software development, systems | Tagged | Leave a comment

Would you spend 1 FTE more to save 2 FTE?

Suppose you have a software or system development organization of 400 people, working in 4 development programs with each 5 projects and 20 people per project, on average. You are using a heterogeneous tooling landscape of different tools from different vendors to support the projects, such as a requirements management tool (e.g. Doors), an architecture modeling & analysis tool (e.g. Enterprise Architect), integrated IDE editing-build-test tools (e.g. Eclipse, Visual Studio), a test management tool (e.g. HP ALM), source control tool (e.g. Git, SVN, RTC), defect control tool (e.g. Jira, Bugzilla, Trac), Scrum support tool (e.g. Jira Agile, Rally, RTC, TFS).

Of course, the tooling infrastructure did not drop out of thin air. It is the result of an evolutionary growth, where also practices evolved over time. Some tools are used in isolation but at a certain moment the need for integration of tools emerges. Let’s go through some of those integrations:

  • Defect control – Source control
    We need this integration to understand which source code was changed to solve a particular defect. Oppositely, it helps understand why a piece of code was modified.
  • Test management – Defect Control
    We need this integration to understand which defect was submitted because a test run failed, or more accurately because a particular step of a test case in a test run fails. Oppositely, we need to understand which test cases to re-execute when the defect is solved.
  • Requirement management – Test management
    When a test case passed, we need to know which requirements are OK. And oppositely, if a test case fails, we need to know which requirements are not OK. In addition, if we want to release our product, we need to understand how much of the requirements are OK – the essential requirements must be OK 100% and less essential requirements may be less than 100% OK. So we need to integrate requirements with tests
  • Agile Planning – Requirement management
    Most projects have limited capacity to develop the product or systems. We need to plan which requirements will be delivered in the next releases. That requires integration between requirements and plans.
  • Agile Monitoring – Test management
    A burn-down chart visualizes the amount of stories that are ready over the course of a sprint. A story is ready when it passes the acceptance criteria which typically involves testing. We need the integration between the stories counted as ready in the burn-down chart and the status of the test. Typically, this is a 3-way integration from the agile planning/tracking to requirements to tests.
  • Agile Planning – Defect Control
    To understand that you can finish the delivery of a release, you need to understand the amount of open work (e.g. stories) and the amount of open rework (defects).
  • Source control  – Requirement management & Architecture modeling
    To implement a piece of code, you need to understand what it is expected to do. In traditional organizations you would have a specification document; in modern organizations the specifications are stored as requirements and architecture models in the corresponding tools. Oppositely, if you want to change the requirements or the architecture, you need to understand which source code is affected.
  • Reporting – any tool
    Many tools have limited reporting capabilities and when there are reporting capabilities it reports are often only accessible within the tool itself or as a PDF or Excel file. Integration with a reporting or data warehouse tool is often a neglected integration.

Now suppose you want to implement those tool integrations. Some integrations are supported by a plugin, adapter, integrator or synchronizer of the vendor of the tools. By the way, if you have tool A from vendor AA and tool B from vendor BB, it is not always obvious which vendor provides the integrator and how far that vendor is willing to support integration issues with the other tool (free of charge as part of the license agreement). So it takes effort to find the integrator, to install it, to configure it, to test it, to troubleshoot it and to solve problems of the integration. If there is no vendor with an out-of-the-box integrator, you might make your own scripts or application to integrate the tools. That takes effort to learn the APIs of the tools, to discuss and define the integration needs, to implement it, to test it, to troubleshoot it and to solve problems.

And then the vendors come with a newer version of the tools, that you need because bugs are solved and extra functionality is needed in the projects. When upgrading a tool, you may need a new version of the integrators, you need to reinstall it, to reconfigure it, to retest it, to troubleshoot it and to solve problems. And if the integrator belongs to vendor BB while you are upgrading tool A, you might run into issues with vendor BB to support it.
And in case of your own integrations, you need to learn the updated APIs for the new tool version (hopefully, no functions are deprecated that you use), to redefine the integration needs (to take advantage of the new capabilities of the new tool version), to adjust the implementation, to retest it, to troubleshoot it and to solve problems.

And then you want to add a new tool and/or replace an existing tool. You need to reconsider all your integrations with those tools, (re)install or (re)define and (re)implement them, (re)configure them, (re)test them, troubleshoot issues and solve problems.

To make things worse, you need to maintain resources with technical knowledge and expertise with the integrations and keep that knowledge up-to-date.If someone leave, he/she must be replaced. For integrations that you made in-house, you need to maintain that knowledge in-house; for vendor-based integrations you may depend on the vendor or external service provider partners, but still the organization specific knowledge needs to be maintained in-house. For open-source tools it may even be more difficult.

And to make things even more worse, software engineers have a tendency to invent their own tools and integrations in the margins of their work. What starts by retyping information from one tool into another tool, often ends in a “handy” little script that extracts information and import that in another tool. Run it in a crontab on a local computer and your done, until another projects wants the same thing. Before you know, your machine is overloaded with processes that are not yours, but that you need to support anyway in case there are issues.

“How much resources does maintenance and development of tool integrations cost?”

As I started, we assumed an organization of 400 people. What do you think, would you be able to support, develop and maintain all tool integrations (including maintaining technical knowledge of the APIs and the integrations) for about 10 tools for 400 people with 1 person or 1 FTE? And how much time do projects spend in the margins to work on integrations? Would 0.1% be realistic, which is 2 hours/year per person on average? And how much overhead would the projects lose because an integration does not work properly, is missing or down, and synchronizations need to be recovered? Would 0.2% be realistic, which is only 4 hours per year per person? Would that be a realistic representation of reality?
Anyway, in that case the total costs would be 1 + (0.001 * 400) + (0.002 * 400) = 2.2 FTE which is about $250k per year. My estimate would be that this is highly underestimated!

Now if I can do the same amount of tool integrations and more, keep it up-to-date with the latest version of those tools, better tested and of higher quality, for the cost of 1 FTE (about $120k per year), which solution would you prefer? If a tool integration is missing, I could add it for another $50k with no yearly cost increase, it would still be cheaper than the underestimated current reality.

“Impossible? Unrealistic? Are you mad?”

This is a absolutely realistic and possible. The only problem is that I have never met a development manager who is willing to increase the operational overhead costs by $120,000 per year on tool integrations. Why not? Because less effectiveness in projects are hidden costs counted as “normal” development costs and because a tools support team of – say – 4 people is already considered “overhead” costs.

“We ‘d rather hire an extra engineer than spend an extra $120k per year on tool integrations that we already have or don’t need!”

Posted in configuration management, integration, tools | 3 Comments

Flipboard magazines

If you are interested in what I find interesting internet reads, have a look at my Flipboard magazines.

Posted in blogs, community, configuration management, music, software development | Tagged | Leave a comment

Is the configuration manager going to disappear?

The simple answer is: Yes, configuration managers are going to disappear!

The more comprehensive answer to this question is that configuration management is not going to disappear, but the configuration manager will be. We can compare it to the change of the crew in the cockpit of an airplane.

In the early days of aircraft, there was only a single pilot in the cockpit. With the growing need for air transportation of people and goods, the airplanes became bigger, requiring more advanced engines, more advanced hydraulics, electronics, aeronautics, navigation, communication and much more. So a second pilot was added. With the growing complexity of airplanes, a flight engineer was added with thorough technical knowledge of engines, electronics, hydraulics and dynamics; and with the growing complexity of the technology even a second flight engineer was added.
This trend was stopped when computers were introduced. Initially, the computers aided the engineers by replacing gauges and switches by screens and buttons, so one flight engineer was enough again. The next step was that computers not only relayed the information more concisely with better structure and overview, but computers were also put in control of complex systems like the engine, hydraulics and hydraulics. The user interface to the flight engineer was simplified and the responsibility of the engineer moved from decisions what to do and how to do it, to only what to do; the computer controlled the how-to-do-it. Currently, the flight engineer has disappeared completely.

Does that mean that flight engineering has disappeared too? No! Airplanes and flight control has become tremendously difficult. There are so many control processes running continuously and simultaneously that it is impossible for human beings to executed that. In fact, flying modern airplanes is not even possible anymore without computer systems.

Now, let’s go back to software and system development. Developing a control system like an airplane is complex, extremely complex! But developing a car is complex too, and even a “simple” device like a phone is very complex. A lot of people have to work together to develop a system and bring it to the market, each of them using a lot of information and producing a lot of information. The information is in constant flux; content is changing, relationships are changing, structure is changing, expectations and interpretations are changing constantly.

The traditional role of the configuration manager is to assure that the right data is available to the right people at the right time with the right status in the right format. To build a complex system requires a lot of work from a lot of people, requiring a lot of information to be used and produced. Adding to that a growing demand for speed, visibility, traceability, responsiveness to customer changes and a high level of quality, and collaborations between multiple projects and project teams in multiple sites at various locations and timezones… In other words configuration management is becoming more important than ever before.

In fact, similar to flying modern airplanes, developing modern systems is not even possible anymore without computer systems. And similar to the flight engineer, the configuration manager role is replaced by these computer systems, or Application Lifecycle Management (ALM) systems. So yes, configuration managers are disappearing. Project managers and quality managers can take control of configuration management through the ALM systems.

But something else is also happening: configuration management is disappearing as a separate discipline. Similar to saving and printing of documents in office application, configuration management is being embedded into the ALM applications that support the various engineering disciplines. For example, requirements management involves managing requirement which implies unique identifiers, versioning, storage and retrieval (including searching), baselining, status, delivery, and even branching and variant management. Some for testing management, portfolio management, roadmapping, and other disciplines. If we look at amazon, facebook, twitter, phones and tablets, cars, trains, airplanes, booking agencies, street lighting and security systems, healthcare and wellness systems, or even ALM systems, nowhere is configuration management a separate discipline. Isn’t it important then? Yes, it is so important that it is becoming a basic functionality of every system that manages information, like saving or printing in office applications.

So there we have it: configuration managers are disappearing and configuration management is disappearing as a separate discipline. Does that mean that I will be out of a job soon and many other CM-ers with me? No! Configuration managers will move into operational engineering or management disciplines (e.g. testing or project management), or into strategic process, business and development management disciplines (e.g. development manager, product manager), or into technical or managerial IT roles (e.g. tool expert, IT manager).

Posted in agile, complex systems, configuration management, excellence, large projects, software development, tools, tracking | Tagged , | Leave a comment