When I was on vacation, I realized that lots of people already know that we need development architects on complex programs. And, lots of people forget that we also need test architects on complex programs.
The more complex the product, the more you need integrated testing, so the more agile makes sense for your product. The bigger the team, the more you need program management approaches. So agile program management makes sense. Agile architecture for development work makes sense to us, right? We also need agile architecture for the testing, otherwise, the testing effort will be sunk.
I haven’t talked to Rebecca Wirfs-Brock about how we will integrate this into our workshop yet—I had this insight on vacation. But that means it affects our triad a little.
Our initial triad was this: the Program Manager, the Program Product Owner and the Program Architect are all concerned with the business value of the product, although in different ways.
The program manager manages the program’s risks. The program architect manages the business value of the architecture. (This is the part that might change.) The program product owner manages the business value of the backlog.
Now, that’s all deceptively easy-sounding. The way that happens is this: The architect talks to the PPO, and says, “Hey, we need to know when you want that feature off the roadmap there, because it has architectural implications for the product. If you want it later, ok, but it will cost you big time.” That’s when the PPO is supposed to say, “How big?” and the two of them have a civilized conversation.
We all know how often those conversations occur now (almost never), which is why the Program Manager is part of this triad, to ensure that those conversations occur.
The reason those conversations don’t occur is because many PPOs don’t realize what their jobs are, or their organizations don’t realize how critical their jobs are, or they don’t have roadmaps, or many other reasons. I will have more on that later.
The Program Architect does not lead a BDUF architecture effort. The PA leads many just-in-time architecture efforts to develop frameworks that evolve from features. The PA makes sure that no one develops a framework without a feature to hang on it. The PA leads wayfinding, scouting, nosing around, exploration in advance of features, so the feature teams have a level path, or pretty close to a level path for their feature delivery work.
And, that’s when I realized that someone or some architecture team needs to do that for the test system(s) on a complex product, too. Does every complex product need an architecture team? Maybe not. But more teams need them than I see right now.
Now, the test architect also needs to talk to the PPO. The test architect needs to discuss the roadmap with the dev architect. I had—naively—assumed the dev architect could help the developers and testers with their system development. After some email discussions and after a workshop and some client discussions, I no longer think so. Some extraordinary architects can work with developers and testers. Most architects—right now—cannot.
What would it take for architects to take off their development-centric hats and stop optimizing at a lower level? I don’t know. Have they ever looked at test systems? If they are new to testing systems, they would have a learning curve. They would not be architects, not for test systems, not alone. They might even have to pair. This opens up all kinds of possibilities when you hire for an agile team, doesn’t it? (I’m cackling with glee over here 🙂