top of page
  • Writer's pictureHuub Rutten

System Engineering in an Agile environment

Andrew is a senior Director System Engineering in a big manufacturing company: “You should understand Huub, Agile gives a lot of freedom to the development teams. Of course they like that. In pure software companies that is fine, but not in our company, where hardware is the major part. The company is moving completely towards Agile and management wants all of us to work in an Agile way. They believe it will make us better, quicker and cheaper, but I don’t see it. The process is very shaky at the moment. I am a Scrum Master by the way. Just to learn what it is. And to be able to play a role in the discussions.”

In my previous post I wrote about Digitization as a Core Competence and now I want to see how this works from a system engineer/architect perspective. System Engineering has an important role in any company that creates physical products, with or without Digitization. System Engineering takes care of the entire system, combines different components and features into the product to make it work together. I wonder how that works in a world where the top down architecture is not dominant but the bottom up Scrum approach. I expect that it must be difficult for the system engineers to get the product done as an integrated system.

“Andrew, can you tell me a bit more about why you don’t seem to be happy with the transformation towards Agile?”

“Well Huub, there are several reasons. First, we don’t know where the development teams will end up. They deliver something based on their time boxes. Secondly, every subsystem should have clear system requirements, but we are still not part of the Epics. Epics do not contain the system requirements. The word requirement seems to be taboo, by the way. So imagine you have several feature projects going on, without harmonized system requirements, without a predictable outcome, how can we compose the system? At the moment we can only advise, we are not part of the development teams, have no authority. Authority does not fit the Agile philosophy, you know”.

I ask: “And what is the impact of this? From your professional perspective?” “Well, with the introduction of Agile we lost control over the system side of the products and technologies. We cannot combine the software and hardware components anymore without many re-doings. We have to compromise the scope from a system perspective, tweak the product to launch it, because it was already committed to the customer or market. The consequence is recalls, which we can predict. It is a nightmare. As system engineer I need transparency of what we do, very much of the changes. Team A makes a change with impact on team B and on the system as a whole; this we should have visible to not mess up the system; we should see changes on a daily basis. But they are not in Jira, or anywhere else. I don’t have any control over the system”.

Andrew has a team of 15 system engineers. He really tries to add value to the company he serves since many years. He is prepared to change. But he cannot see how bottom up Agile will work. He is not against the agile way of working as such, but in his view the system architecture should be leading the work in the teams from the beginning. Collaboration with other teams should be pro-active and changes should be agreed before you do them.

Digitization is a Core Competence, sure, but it will never be a mature competence if there is no upfront technical coordination, if hardware and software requirements are not aligned in terms of connectors, APIs, data formats, etc. Not having System Engineering in a dominant position will make product realization very difficult. A nice feature standing alone won’t work, won’t have effect. Agile without strong coordination will not be successful I am afraid.

This story will continue.

Related Posts

See All

1 Comment

Hans-Cristian HC Eppich
Hans-Cristian HC Eppich
Apr 29, 2021

From a corporate perspective there need to be a balance between connecting business layers to ensure strategy execution while at the same time making sure business decisions are not based on technical details! Maybe the term "connected autonomy" holds merits for business layers as well as for business units?

bottom of page