Agile, Architects, and Programs

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.

Integral Triad: Program Manager, Program Product Owner, Program Architect

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 🙂

11 Replies to “Agile, Architects, and Programs”

  1. Lots of food for thought here. I’m not comfortable with the idea of having ‘architects’ in any kind of authority or power role. When I worked for a company with 25 Scrum teams, there was an ‘architecture’ team, and they worked in isolation, never seeking to know what the development teams needed. The resulting architecture impeded good practices such as testing at the API level, and forced us to do our “specification by design” or “ATDD” via automated GUI tests. Perhaps better communication between the architects and the developers might have helped, but IME, some people think that once they’re in that architect role, their word is all. And IME developers do not enjoy having to code something to someone else’s design, and having no freedom to experiment and find the best way to design the code.

    I’m also not comfortable with the idea of a “test architect”. In too many companies, testing is seen as a separate activity from coding. It is not. It is part of software development, along with coding. Perhaps we might need some testing activities that take place once coding is complete, but we need to stop isolating “testing” from “coding”.

    On my team, we – the entire team, including the product owner – start each new theme and user story by first thinking about how we will test it. Certainly, the testing experts on the team have a lot of input into what testing needs to be done, but the developers (and we do have someone with the title of “architect”, but he never decides anything in isolation, he is just one of the team) are test-obsessed and want to design the code to make sure all the testing activities can be achieved in a timely manner. For example, they may change the design when we talk about the need for API-level testing.

    Perhaps in a huge organization, there needs to be some small number of people having the initial conversation about a huge new feature that will be worked on by multiple teams. But I hope those people are all part of one development organization, even if they have different areas of expertise.

  2. I agree with Lisa Crispin about the role of the architect. I don’t believe that an (external/isolated) architect is generally good for the team. The more experienced the team, the less there is need for someone holding their hands (restricting them).

    I haven’t seen many projects where testing was sufficiently integrated to the development process. Quite the contrary. I don’t see how the role of a “test architect” would remedy this situation.

    However, I’m eager to learn how to solve this problem. Perhaps I just misunderstood the intent? Was there something I missed? What would the actual job of a test architect be?

  3. This is interesting. One could argue that in an ideal world there is no difference between writing the software and testing it. Testing should be part of the job. On the other hand, testing a major enterprise system is a specialized skill. There’s a lot more to it than just verifying and validating code modules.

    The entire system must function as an entity and cooperate with other systems on the corporate network. It must meet performance goals without hogging system or network resources. It must fail gracefully and not drag other systems down with it.

    Expecting the software developers to cover all this may be asking too much. “Test architect” may be a bit grandiose but the concept of having an enterprise-scale testing expert on the team is valuable.

  4. There are two roles integral to a development effort: the customer and the developer. On self-organizing teams where a significant difference of skill level exist among team members, the more experienced within the group should be looked to for helping guide design efforts, but they should also actively work to reduce this disparity by mentoring the more Jr. members of the team. For large scale enterprise efforts, a steering committee may be warranted to help define and enforce strategies surrounding certin types of concerns, but this may not require full time responsibilities. As far as solution architects that act as an interface between the “feature teams” and bee-keeper roles within the company, I’ve always found this to be a poor approach and one that tends to do more harm than good.

    As far as testing concerns, apart from following test-driven development practices, the development team should establish any other testing practices expected by members dedicated to QA tasks, but again there is no real need for an ivory-tower “architect” for perpetually defining/steering the testing needs.

    In summary, the last thing most teams need is someone whose responsibilities can be described as “wayfinding, scouting, mousing aroung and exploring”. Let’s move beyond these antiquated ideas.

  5. My initial gut reaction sides with Lisa. You definitely start entering some very sticky territory when separating the architects out of the delivery team. It is very easy for this to seem like the architects dictating design and bordering on BDUF and can easily make the delivery team feel less empowered. On the flip-side, I can also see some need for a little bit of up front planning/thought on some of the larger items, especially if the work will span multiple teams. Then the questions arise about when does this work happen? Are the architects in your model also part of a delivery team? If so how is this time balanced and planned for when committing in sprint planning? If not, are they ever contributing code?

    I’m definitely interested in picking your brain and discussing this. If you’re going to be at Agile2011 I’d be interested in meeting up. If others are interested maybe we can schedule an OpenJam session?

    1. I will be at Agile 2011 and I would love to schedule an Open Jam session about this. And, see How Agile Architects Lead. The architects are not separated from the teams. Although they may sometimes have different work, they are part of the team.

      Matt, let’s coordinate and have at least one session at Agile 2011. Large and complex programs are quite different from smaller projects. Let’s talk about what you’ve seen work. I’ll share what I’ve seen work and what I’ve seen not work.

  6. I’m with johanna on this one…

    Explicit Architect roles are a good thing for larger programs. I agree that they are part of the team. I also agree that we need to avoid BDUF and architects dictating from afar.

    This is why If i have architecture teams I typically make architects manage these teams, and I empower business feature focused development teams to become first class clients. This puts architects into more of a servant / client facing role with feature developer teams.

    That’s just one model, there are others. In another instance we used Kanban to identify which parts of the delivery lifecycle an architect would focus on, (ie up front stuff and guidance throughout)and which parts the architect would provide guidance for, pulling in developers as needed.

    I’ve had to play architect on many projects, and have coached architects on numerous agile engagements. The trick is to get them to focus on the feature they are working on, and and not architect for the world. I also coach architects to realize that anything they come up with up front is always mostly wrong, and that developers are required to validate design decisions, typically in a very collaborative JiT approach.

    Finally, I have test architects on really big programs. They focused on how to make sure things like TDD, CI, BDD, etc could possibly work when dealing with agile “hostile” technologies like many vendor ESBs, SAP, etc etc. This requires a lot of focus, so I’m ok with giving this role to someone who can focus on it, working collaboratively with the team of course.

    I like taking the time to describe testing architecture, sort of a parallel architecture to the main one.

    I described the concept in a posting I did about XP awhile back…

  7. By whatever name you want to give it, on a large software project IMO you need people who sit between/across the teams and focuses on how the features become a system. Likewise with automated testing, someone has to see the whole testbed+product as a system and make sure it works as a whole. I agree that BDUF is not the way. This work can and should be done incrementally, aligning with incremental product development.

    When we talk about developers doing proper test driven development, the underlying assumption is that the test infrastructure is already present and satisfactory. For any new-ish product that’s a reasonable assumption because setting that up should be part of the first sprints. But with a large legacy system, that’s often neither true nor trivial. Hacking or crafting test tools to fit a not-designed-for-testability system is not something that comes naturally to developers. Especially developers and offices that are still learning to be Agile.

    Even in some of the worst cases, BDUF is not a good idea. Sometimes you need to buy an expensive test tool but buying it is neither the start nor end of the process. You need some sprints for a pilot project running on demo licenses. Then you need to engage the developers over many sprints to tailor that system to meet their needs. That work helps developers properly account for the cost of testing when they plan their sprints. After every sprint, especially the one just before you put the cash down, you need to evaluate your direction and be ready to change it.

Leave a Reply
