I know the slogan “Be agile, not fragile” has been used so often it’s become cliché, but I’ve got some new insight. The “agile method of software development”* has become the predominant pattern for software development in the world today, and has found traction outside of the traditional enclave of software development in recent years.
Systems engineering organizations are now often obliged to participate in agile development and to integrate into the agile tool chain, set up scrums, and write user stories for their work. Having gone through this transition at a large systems engineering organization, I can testify that the process could have been handled better! Applying agile methodologies without a solid model-based systems engineering base, coupled with typical organizational dysfunctions resulted in an extremely fragile application of the agile process.
Systems engineers—agile from the beginning
The word agile, last time I checked, was an adjective. Then why is everyone selling it like it’s a thing? “Agile” describes the process—it’s not a noun! So why is “agile” such a process change? Does it really incorporate so much new thinking? Systems engineers in general have been agile in their thinking from the beginning. Systems engineers are constantly refining the system, constantly iterating the design and documenting it in the model and requirements as more knowledge becomes available. Isn’t that the essence of agile?
Systems engineers have typically laid out functional capabilities long before the software development team gets involved. The systems engineers are generally responsible for the systems model, which is developed with input from the entire team to serve as the basis for generating the requirements and create a common understanding of the functionality of the system.
“Fragile agile” is very much a product of the typical tendencies of people to hold the model in their minds, and not seek a common way to reference that mental model and share it effectively with the team. When that common understanding between the systems engineer and the rest of the team—including all levels of management—does not occur, this can cause conflict between the systems engineer and the team. And when this happens, the agile framework of epics, features, and user stories can become divorced from the system model. Who’s right in this case? I’ve seen time and again a failure to reach a consensus on top-level functionality, mainly due to the lack of comprehension and agreement on the systems model. If an organization creates epics without reusing the system model’s high-level functions, then there will be serious disconnects between that organization and the systems engineers.
Metrics mania
Another manifestation of fragility in an agile deployment is a form of organizational dysfunction that can result in what I call “metrics mania.” This can frequently be seen with agile toolsets. Typically, what happens is management becomes fixated on completion date and sprint burndowns, but their lack of the systems view hampers their understanding of the burndown. Let’s face it, engineers aren’t always the best at describing their work in user stories, so if management has bought into the systems model, they will have a better understanding of what the true state of the development is. This lack of buy-in to the system model can cause the team to be trapped in a downward metrics spiral.
In this situation, what can happen is that you’re trying to calculate your percent complete while the denominator is constantly shifting because there is no team-wide understanding of the scope of your system in the first place. This produces a metrics-based picture of failure or, at best, a growing backlog of work. Agile in general is designed to help cope with this situation, but when your team doesn’t have a good systems model as a base to work from, the misunderstandings about where you are can cause an immense loss of morale, friction among the team, and frustration within your larger organization.
How can you help mitigate some of these issues? First off, take the time to really do a “Sprint Zero.” The goal of a Sprint Zero is to make sure that everyone on the team and any other stakeholders in your process have reached a consensus on what the expected work scope for that sprint must be. This is the place where having a model-based approach can truly help to get that model out of everyone’s head and into a single repository where a shared consensus can be reached. Make sure this time is used to ensure that a true model-based approach has been taken by the team, and that the team buys into the model.
Epics and features must align to capabilities and functions. A good functional behavior model should be the basis for your agile deployment. Without that modeled base to build your workflow around, you’re engaging in unstructured fumbling towards the end goal. The first step in most agile or DevOps methodologies is to lay out the epics. You have to decide what the big functions are that you’re going to deliver. This must be done as much as possible up front, and the systems engineer is the person to coordinate this effort. Their model should be the basis for the epics.
Epics, essentially high-level functions, should be extracted (or better yet, linked) directly from the systems model. This should be a fundamental concept, and buy-in to the model will help to ensure that. The model must serve as the base, or else you’ll experience an untenable amount of agility with your product design.
Not basing your epics and features on the systems model is a disaster waiting to happen. It’s a clear symptom of fragile agile. It causes churn and uncertainty about the top-level function you’re trying to achieve. Imagine developing all the user stories needed to complete an epic and then beginning to work on those stories only to find out that those epics weren’t aligned to the systems engineer’s view at all. Our goal should be to minimize re-work, not ensure it!
Engage your program managers
One way to combat the fragile tendency toward metrics mania is to engage the program managers in the modeling process. Include them in the modeling review and concurrence process. Find ways to get them excited in the process, and make them active participants. You’d be amazed at the results you can achieve when you get the program managers engaged in the model.
Schedule model walk-throughs, try and jazz things up a bit with fancy graphics perhaps, and above all, show your stakeholders how the model connects to what you’re trying to achieve. Ensuring that your metrics are based on the systems model will increase everyone’s understanding of the scope of the work. You can use that knowledge to craft better epics, user stories and achievable tasks, which in turn will cause your metrics to improve. This will be meaningful due to the systems-model-to-agile-planning connection.
A model-based systems engineering approach focused on functional behavior modeling is one key to beating a fragile application of agile, and transitioning to the true application of agility in your engineering processes. My hope is that by stressing the importance of using a solid systems model as a base, you and your organization can build a solid and connected agile implementation, and minimize the fragility in your process.
The model is the underlying source of truth, the common ground, and a language to bring all your team together into a common understanding of your problem space. Once that concurrence and synergy is built, wrapping the agile or DevOps processes around the model becomes easy and natural for your team. Consensus is built before execution in this approach, which is not to say there won’t be iterations—of course there will be—but you’ll be iterating within the bounds of the model, and you’ll find that with each iteration—each time you’re forced to be agile—your product and processes will continue to improve!
Part 2 will cover tips and tricks for connecting GENESYS to your agile toolset.
*This word is often capitalized to refer specifically to “Agile Software Development,” as set forth in the Manifesto for Agile Software Development. I have lowercased it in this post.
To learn more about agile MBSE, view the webinar More Agile Than Agile: A Layered Approach to MBSE.
Thanks for the post, I recognize many of the challenges you describe. Agile is here to stay, at least if your system contains software. One ordeal I have with agile concepts like user stories and epics is that they claim to represent system requirements, but in practice, they represent work to be done. Agile focuses on splitting up work in manageable chunks, so the user stories tend to be written with this in mind. Also, when the epic is written, there might not exist a system model (or concept) to link it to.
GO ANDY! This is such a great jawb for you! I am feeling a bit verklept… talk amongst yourselves. This is a great move and you will do much good to aid the systems engineering community.
Rainman
The “internal mental model” is the single, biggest detriment to effective complex systems development, IMHO. I have been part of way too many design meetings wherein most people are operating from the models inside their heads, without ever realizing that everyone’s mental models could have varying levels of differences that make them incompatible. That leads to a completely ineffective, and perhaps even counterproductive meeting. Add this to the fact that no one really enjoys documenting technical meetings, and senior people often leave that task to junior engineers. If the entire team buys into an external, observable, searchable system model this could at least give those junior engineers a coherent means to capture the discussions. And let’s also not forget that, when discussing software requirements and solutions that they cannot be divorced from the reality of the hardware that does all the work of the system. And by hardware here, I am certainly not only talking about the computing hardware upon which the software executes. I mean the actual physical devices that do the heavy lifting of a system. Those devices have performance requirements they must meet, and performance envelopes that they must not exceed. Software solutions can either play a big part in helping the hardware elements achieve their objectives, or that software can be a nagging problem that may result in those hardware elements not obeying their performance boundaries.
Thanks for this article, Andy. And I look forward to your Part 2.
Rainman