Build Your Own Radar: Using the Technology Radar as a governance tool

Episode transcript

Prem Chandrasekaran: Welcome, everyone, to yet another edition of the Thoughtworks Technology Podcast. Today, we're going to be talking about the Build Your Own Technology Radar. We have two eminent guests, both of whom you probably recognize. We've got Neal Ford here. Neal, do you want to quickly introduce yourself?

Neal Ford: Hello, everyone. When he said we had two eminent guests, I looked behind me to see if there were two other guests here, but I guess not. I guess it's just me and Ken. Neal Ford. I'm one of your regular guests. If you've listened to our podcast, you've probably heard my voice at some point. Thanks for listening, everybody.

Prem: Also welcome, Ken Mugrage.

Ken Mugrage: Yes, exactly the same thing. Also one of your regular guests and hosts. Good to speak at you again. Hopefully to speak with you soon.

Prem: Wonderful. Just so that you know, I am Prem Chandrasekaran. I am also one of the regular co-hosts on this podcast. Let's get started. This episode is about building your own Radar. Before we get there, what exactly is the Technology Radar? Can you tell us what the Radar is?

Ken: Sure. Radar is a publication that we put out roughly twice a year. That's a snapshot of different things that we're using. It comes out as a website and as a downloadable PDF. There's some basic structure to it that I'll go into at a high level so that the conversation makes more sense. Not going to get real deep into it. First off, there's the concept of rings. The rings in the Radar are, they start on the outside.

It's Hold, which is don't do this. Assess, so hey, you should think about this. Trial, which actually means not just you should try it, but it's actually a statement of fact, meaning we are trying it. That's something that a lot of people don't realize is that to get into that Trial ring, that means that we have to be using it on production Thoughtworks projects. A lot of people sometimes are like, "Hey, there's this new thing, and it hasn't made it into Trial yet. Yes, we're really excited about it. It's been in Assess, but it's not in Trial because we haven't convinced a client or the client hasn't convinced us to try it."

Then the inside ring is Adopt. We used to joke around many years ago that this is the-- If you're not doing the things in this ring, we make fun of you in the bar. It's not quite that far, but these are the things that we think you should be adopting. Now, I do want to differentiate that. A couple of months ago, Thoughtworks, we published a thing we call the sensible defaults, which is what we tell ThoughtWorkers, "Hey, this is the default. Unless you have a reason to do something else, this is what you should be doing."

This is a little bit different. The bar is not the same, I guess, is the way to say it. Adopt is if you're looking for a technique in this area, these are the ones that we have adopted that we are using. It doesn't necessarily mean they're a default because often there will be competing technologies in Adopt. Just something to pay attention to. Just because it's in Adopt doesn't mean it has to be a singular sensible default or the horrible term “best practice.”

Neal: A couple of nuanced things about that, that I'll interject just for a second before Ken goes on. Adopt doesn't mean you should use it no matter what. It means within context. If reverse proxies show up in Adopt, which they have, it doesn't mean you should go out of your way to use a reverse proxy. If you need a reverse proxy, this is a good idea. I want to double down again on what Ken was saying. This is a snapshot in time.

That's particularly true on that Hold ring, which doesn't mean to stop doing what you're doing right this second. It means don't start anything new in that technology because we're trying to create a perspective here. We realize that organizations are like cruise ships. You can't turn them on a dime, but you can gradually nudge their direction. That's the idea of Hold. Almost always we try, if we put something on Hold, to offer an alternative, a better alternative than the thing we're putting on Hold, rather than just saying bad things about it because we don't like it.

Prem: Wonderful. Thank you both for the clarification. I had one more question about the Radar. There are these quadrants. There are four of them, right? Do they mean anything specific? How did they come about?

Ken: They mean something, but to be honest with you, we're not as bothered about which quadrant something goes into. We had the challenge of splitting the entire software development world into four buckets. The buckets we chose for our Radar are techniques, tools, platforms, languages, and frameworks. The truth is that often tools is really heavy. There's just a lot of blips in there. It's like, well, could this be called a platform? Is this a tool? It's important, and the quadrants are important, but they don't carry the same weight as the rings.

Neal: During the meeting itself, there's a bit of parsing of web pages to see if they've mentioned the word platform or framework or something in them to give ammunition for where it goes one versus the other. The quadrants are not completely arbitrary, but they're not meant to be exhaustive. It's probably worth mentioning where the quadrants came from. The origin of the Radar itself came from--

Rebecca Parsons, when she became the CTO of Thoughtworks, she realized that there was a lot of technology stuff happening globally that she just couldn't possibly have a handle on as being a single person. She created this advisory group called the Technology Advisory Board that met twice a year face-to-face and advised her on technology stuff. One of the things that we always did informally was, "Hey, what cool stuff are you working on in your region, in Australia, or China or wherever?"

At some point we thought, well, it'd be really cool if we could take that conversation and publicize it internally to let other Thoughtworkers know what kind of cool stuff other Thoughtworkers are working on. Rebecca's assistant at the time, Darren Smith, came up with this idea of the Radar visualization, and actually created the first one in Keynote because that was the only drawing tool he had on his laptop. He used the little shape tool in Keynote to draw the first version of the Radar, which we published internally.

As soon as we started publishing this thing internally, favored clients started wanting to get the insider info on that. We thought, well, if people are interested in this, we should start publishing it for real. That's when this idea of the Technology Radar was born. Very shortly after we started publishing the Radar, the question came up, should we allow other people to create radars? In particular, could we use this as a way of building a sort of governance framework for clients? Because we realized how useful this thing really is.

Ken will get into the actual secret sauce of the usefulness of this thing because he just sat through one of these meetings. We realized the really hidden usefulness of this, and that it would be a really useful thing for a lot of our large clients as a way of organizing their technology landscape the way we're trying to organize the industry technology landscape and organize it in a way that you can consume it.

We got into a really big discussion at the time, should we try to make this a purely proprietary Thoughtworks thing and yell at other people who try to create radars, and et cetera, or should we publicize this thing far and wide and make it open source and encourage other people to do it and trust in the fact that it'll be associated with us because we were the first ones to do it? Obviously, the second option won out.

We've now created a tool that's on the Thoughtworks website to build your own Technology Radar that helps you either with a Google spreadsheet or with a tool you can host yourself to build your own Radar because we realized this is actually a useful exercise in several ways for both clients and actually as individuals. I'll talk more about that a little bit later. I wrote an article probably more than a decade ago, it's on the Thoughtworks website, about Build Your Own Technology Radar, which is about using this as a way of organizing a technology landscape.

Prem: Excellent. So thanks for the perspective on what the idea was behind allowing other people to build their own Radar. Because I do remember that as soon as we published our first few Radars, I think there were several other clones that came by that looked pretty similar in terms of content and even the visualization. Making it open source definitely did level up the playing field. Absolutely.

What I've gleaned from what both of you have said thus far is that, one, we are not very sacrosanct about the items that appear and the positions in which they appear. That varies and can vary and depends on context. The other thing that you said was that the quadrants, although there is some method to that madness, again, we are pretty flexible in terms of how those quadrants can be formed. If I'm building my own Radar, we don't have to have to restrict ourselves to exactly those four. That's what I've gleaned thus far, right?

Neal: When we do this exercise for our clients, they often have-- We're trying to comment on the industry as a whole. They're trying to comment on their very specific context. We have an entire quadrant called Languages and Frameworks. In most large organizations, they've chosen the primary languages they're going to be using and the primary frameworks they're going to be using. In fact, they're not trying to have a large discussion about that, no matter how much the developers would probably like to have a larger discussion about that.

They are dealing with things like package software, which does not show up on our Radar, but it may be a huge part of their decision process. That's why when we do this outside of the context of Thoughtworks Radar, we encourage people. Because if you're using it as a way of documenting your technology landscape, it should be accurate towards your technology landscape, not some arbitrary set of quadrants that some people created more than a decade ago.

Prem: Absolutely. Again, the whole idea of this is that it's available as an open source tool, isn't it? If I want to use this myself, I can get started really, really quickly because it's available on GitHub. I can clone it. I can do a bunch of other things that I want, customize it the way that I want, and then publish it either internally or maybe even externally.

Neal: Like many things, I think it's a failure to focus just on the tool, because let's talk about what the process looks like when we do it for a client. I've hosted a bunch of these for clients. In fact, I think I did the very first one we did for one of our clients. What we generally recommend is to replicate as much as possible our face-to-face meeting in a slightly abbreviated way.

When I've seen this done most successfully, it's two full days of a group of representative technologists from the company that ideally is off-site because if they're on-site, they're going to get distracted by mundane day job details. If you can get them off-site, then they're less likely to be distracted about stuff. It's really important to get a cross-sectional group, too. A great example is I did this exercise for one of our clients.

One of the topics that came up were containers for developer desktops. Yes, let's do development in containers. Most of the table was rah, rah, rah on that, but the front-end developers put a screeching halt to that and explained how much inadvertent complexity that would add to their life if all their development had to go and be containerized prematurely. It gave a perspective to the other people in the room.

It's like, oh, well, we can't make that a universal policy. That's the kind of thing that comes up a lot in those conversations. You want a mixed perspective. If you have more than 30 people, it's hard to carry on any kind of conversation. You can do this in multiple sessions, and then aggregate the results. As long as you have mixed groups in all of them, the results should aggregate pretty cleanly up toward one another.

Generally, what happens is you have a facilitator who's there. Hopefully, someone who has facilitated one of these before. Their primary job is just to make sure you don't get stuck in the weeds and talk about things too much and keep things moving along. Then you have somebody there that's copying the results of what people say. The idea is that when people come in the room, they nominate things that they want on the Radar and where they want it to be.

Then you go through each one of those one at a time and have a group discussion about where those things should end up. At the end of that meeting, you end up with the Radar artifact that you've created collaboratively. Now, one of the things that we have in our Radar, and we also recommend that people do if they build their own, is that each blip, which is each item on the Radar, has a paragraph-ish write-up. It's a paragraph for historical reasons for us because it used to have to fit on a physical publication, and it was tight.

It could be a lot longer now. We just don't want to take on the writing burden. We recommend that for people who are building their own, that each of those blip write-ups almost resemble an architecture decision record. Why did we make this decision now? What is the context and the meeting and some flesh behind it? One of the cool things about our visualization tool is that each blip is basically an HTML link, and you can put whatever content you want behind that link, and it can be a more fleshed-out document of what the thing is for.

Ken: I think that's a really important note — it'd be very easy, frankly, to-- For what it's worth, I've been a user of the Radar for quite some time. This was my first time actually helping create the Thoughtworks Radar. It seems like, oh, it'd be easy to write a paragraph definition of what this thing is, but that's not helpful, right? You can find a definition anywhere. What you need is that context. The building your own Radar is, I don't know if it's quite as far as a Trojan horse, but darn close.

Neal said that people collect these blips ahead of time and bring them to nominate. That's really where a lot of the work is, frankly. What happens is, for us, at least, is a Thoughtworker gets excited about a thing or they see a thing on a project or their client recommends it or whatever, and they think it's important. They bring it to their local advisory board member. They go through with that local area and figure out what are the blips we're going to take to the meeting.

Then they come to the meeting, and we have a whole big discussion about it. We'll go through some of the mechanics of that, I imagine. Then we go off and rewrite it. That goes out to all Thoughtworkers to take a look at the write-up, et cetera. At the end, yes, we have a very pretty webpage and a very pretty PDF, but the truth is it's, for us, at least, several weeks of fairly deep discussions.

Yes, there's a deliverable, but it's sort of like, for those of us that have been in consulting for a long time, where we're in there for several weeks and the deliverable is a four-page presentation or a two-page spreadsheet. People are like, "Wait. That's all we get?" It's like, no, what you got was the two months of discussion. It's really important that people don't lose sight of that. They don't just go away in their office and create their Radar, and then publish it.

Neal: Having done this a few times with clients, the Trojan horse idea is true because it's useful because there is an artifact attached to it. After two days, we're going to get this artifact. There's a clear deliverable attached to it, but the actual value is the conversation. That's what you see when you conduct, when you act as a facilitator for one of these meetings. About two or three hours into the meeting, the stakeholder that came to the meeting to make sure everybody is using their time effectively, you can see the realization wash over their face.

It's like, wow, we never have these kinds of conversations here because they're in the category of, just call, important but not urgent. You have a lot of urgent conversations, but you don't have a lot of these important things that are not urgent, but you really should know. Every developer thinks they know what the head of operations' perspective on this particular tool is, except you haven't asked that person. You just think you know until you actually have a conversation about it.

That's the real value of this thing. When we do it for clients, we recommend, in fact, one of our largest global clients has been doing this exercise himself once a year, to get people together in the room and have those conversations because that's the actual secret sauce. The icing on the cake is you have an actual physical deliverable that comes out of it.

Prem: Yes. It looks like from what you both said, I think you've mentioned ADRs or Architecture Decision Records. What do you think of using the Radar as a governance tool? It's not uncommon for clients to actually try and use it that way. Do you endorse that, or do you think that's not a good idea?

Neal: Not only do I endorse that, I've actually advised several of our large clients to use it that way because one of the big problems you have in the enterprise architecture realm is visibility in what you're doing because you're in the strategic stratosphere of the organization, and rank and file developers don't-- the only thing they hear from you is no. Oh, can I use this new thing? No. Because we have a standard.

You become the no police because they have no insight into what you're doing. There are a lot of things that are like work in progress. Several of our big, large clients, their enterprise architecture group publishes a Radar internally where all the things that are in Assess are the things that we're looking at as an organization. Trial are the things that you should use on your next project probably if you want to try something new out. What this allows you to do, like I said, our Radar visualization is basically just a hyper-- an HTTP link.

Behind that, what they do is put things like whip limits on, okay, we'll let three teams experiment with Vue.js. When the fourth one comes in, they can click on it, and say, "Oh, no, three teams are already using this. We can't do that. If one of those finishes, maybe we can get in there." It gives visibility as an organization. Now developers have sort of an enterprise architecture dashboard. Oh, are we experimenting with this? Let's go see if it's on our internal Radar.

Really importantly, things that are on Hold. Things that are on Hold, like I said, are things we're trying to get away from. Don't start anything new in Hold. That's a really valuable tool for enterprise architects to publish internally. Hey, if you're starting a new project, don't start it with this. Use this thing that's in Adopt or Trial instead. I think it's a very effective way to make visible the work that enterprise architects are doing on a regular basis that's hard to make visible otherwise. Where's the enterprise architecture dashboard in most organizations? This is actually sort of a dashboard for that feedback loop.

Ken: I think it's also worth mentioning not to hesitate to put things on Hold if that's where they belong. What I mean by that is quite often there'll be a tool that, well, I'd like that thing. It works fine for me. Why is it on Hold? It's because we chose a different option. It's not saying that it's a bad thing necessarily. Some bad things and anti-patterns do show up there, but it shouldn't be assumed that something only goes in Hold if we have a problem with it. It's just that we think that if you're starting a new project, you should not start it with that.

Neal: In fact, you can be much more aggressive on Hold in a Build Your Own Radar because it is within a company context. In my opinion, we are way too afraid to put things in Hold at Thoughtworks and in Adopt. I think we've gotten way too conservative, in my opinion, as part of this group. I complain about this all the time, but particularly things in Hold, the current CTO has to answer for the opinion about that.

Prem: You both talked about Hold and you talked about Adopt, but there are two other rings as well. Now how do you go about deciding when something goes in Hold or Adopt? Because like you said, it's a pretty strong statement either way, right? If you're saying Adopt, it means that you're really endorsing a large population to actually take it up. If you're saying Hold, you're saying be very cautious about doing this or even stop doing it. How do you decide what goes where?

Neal: As a group, the Hold things come up because we have direct project experience. It's important to remember, as Ken was describing this, the people in the group don't originate the blips. Those are organically filtered up through projects. If something on a project comes up on Hold, that means that somebody has used it, it promised something, it did not deliver on that promise, and they're mad about it.

A lot of enthusiasm usually comes along with Hold items because they've been fussing with something that claimed it would do something, and then only to realize, no, they were just lying. No matter how much effort I put into this thing, it doesn't actually do that. It is not uncommon for us to get Radars where the same technology will show up in both Hold and Adopt. One team has been using it to spectacular success and another team has been fussing and fighting with it for some reason. In those cases, it usually ends up in Trial.

It's very much part of the conversation that we have. We look at how egregious is it. This is another one of those things that we try to avoid just kicking things for the sake of kicking things. There was a pretty strong contingent on the most recent Radar meeting to put Microsoft Teams on Hold. Because it's just objectively terrible compared to a lot of the better alternatives that are out there, and a lot of our teams really do not like using it.

We didn't put it on Hold because this is not a decision most teams get to make. This is part of a larger corporate suite. This is not made at the team, at the architect level. Us putting it there is just being ranty about something that is less than optimal, comes up in a lot of the software development ecosystem. We try to avoid putting things like that on Hold. The other thing that very often comes up and it ends up getting rejected, in fact Ken has heard this phrase many times, is stupidity on Hold. You can't put stupidity on Hold as much as you'd like to.

Things keep coming up that are nominated from teams where objectively when you look at it from a proper engineering standpoint, no, they're just being stupid. You shouldn't do that. We don't put those things on Hold either. That's part of the reason it's pretty nuanced as to Hold because we're not trying to kick things. Like I say, we're almost always trying to be useful and actionable and say this is on Hold because this is the alternative.

Ken: On the practical side, too, of your question, Prem, is how do you make the decision? Regardless of what ring or quadrant we're talking about. The person that comes in with the blip proposal is proposing a specific place on the Radar. They're saying, here is my thing, I'm proposing that it go into Trial in techniques. This is where strong moderation is important. They make their little pitch, which again probably came from somebody else, but they're the proxy. The moderator takes a vote right then.

If there's broad agreement, we're done. Move on. if there's a broad disagreement, it's also done. It's called. It's gone. If it's split, then you have the discussion about it, but it's very important that that moderator keeps things moving. We looked at well over 100 blips. I don't remember how many ended up on volume 31. I think it's 110, 120, something like that. From a practical perspective, that's the thing — you have to have a proposal. You vote about the proposal. You discuss it if required.

If there's broad agreement, there's no reason to waste time discussing. If there's broad disagreement, there's no reason to waste time discussing. Now, with that said, at the end of the meeting, we do have-- there's a concept called a lifeboat and others where if the person that proposed it, or even somebody else that then fell in love with it or whatever, really feels strongly, we'll go back and revisit.

There's this thing that Neal really loved. Everybody said, no, that's stupid. He feels strongly about it. We're not going to do that in the meeting all the time. At the end, we do give people-- It's not just gone forever, is I guess the point. It requires strong moderation to decide where it goes. You don't want to spend more than a few minutes on any one blip or you'll just rabbit hole.

Prem: Yes. It reminds me a lot of estimation exercises, which we do with teams, where a story comes up for estimation or whatever the unit of work is. Then now multiple team members work on it, or that at least put up an estimate. If everybody is in the ballpark, then you just move on. Agree. Then if you have a conversation, which I think is the more important part of this, then people do disagree. That's similar in this case as well. It looks like.

Neal: In fact, Rebecca Parsons came up with most of these moderation techniques over the course of years of moderating these things. We have some very useful semaphores that we use, particularly when we're in person. It's a group of 25 or 30 people in person. Everyone is issued during the meeting three index cards; a green one, a red one, and a yellow one. If a topic comes up and everybody agrees or you disagree, you hold up a card for the initial vote.

If it's all green, then it's on. If it's all red, it's off. Yellow means I want to discuss it. Yellow can come up at any time. A single yellow card means I want to discuss it more. We use a similar mechanism when we do it online using Zoom and a shared spreadsheet and a whole bunch of other stuff like that. To Ken's point, that greatly eases the friction of when we're all in agreement or all in disagreement.

We also have a category called too complex to blip. We realize, painfully realize, that we have a paragraph, a few sentences to capture something on our Radar. Some techniques are just nuanced. One of the inevitable destination of some of the very interesting things that get nominated on our Radar is the graveyard that we call too complex to blip because there's just too much nuance to be able to cram into a single blip.

A lot of discussion ends up, because the moderator doesn't want to spend the entire session talking about that, which we could, okay, let's move on, it's too complex to blip, let's move it on and move it to the next either an article or a podcast or some other destination. The Radar is not a universal place for ideas. There's a very specific context that it can go in. Lots of things get nominated that are just outside that context and cannot make it for that reason.

Prem: It looks like we don't see the honorable mentions list. That's unfortunately is private to the tab group that meets. It looks like this is a fairly elaborate process. Neal and Ken, any interesting stories that you have to share with the audience?

Neal: I did a conference talk on Building Your Own Radar for a while. What I realized was as much as we have this sort of scaffolding around this Radar idea, it's really just a way of organizing a disparate space of where something is. It's true to the Radar metaphor where something is moving towards you or something is moving away from you. That's the core idea of the Radar.

As we mentioned, I've seen this used as an enterprise architecture tool, as a way of visualizing a dashboard of what we're thinking strategically as a direction, but I've also, and this is actually part of the Build Your Own Technology Radar article that I wrote, I've seen some developers use this as a sort of personal career guidance tool. It's an open source framework. Things that are in Adopt are things that you should absolutely be doing. Trial are the things, the directions you should be going in. Things that are in Hold are things you should start spending less time on.

The recommendation here is that, so one of the things you should always do as a technologist is keep track of what's coming up in terms of technology. It's very easy to accidentally end up in technology bubbles. The problem with being inside a technology bubble is when the bubble starts collapsing, it's hard to tell from the inside because it still just looks like a dome from the inside. You can't tell the dome is getting smaller until it snaps and it goes away.

I understood this at a really bad level because one of my first jobs was a company that did consulting and training in this technology called Clipper. Nobody listening to this is going to be old enough to remember Clipper, I suspect, which is this DOS-based tool. We were great. We had consulting work and training work, and that was fantastic until the day it wasn't because it didn't move to Windows, and Windows came and took over the world. Then suddenly we had to scramble because we didn't see the bubble that we were within collapsing.

This is a danger for technologists. You're in a technology bubble, nobody inside the bubble is going to tell you that it's collapsing. You have to pay attention to that. That means you need to be strategic about your career, but you also need this other life, the family life and the life outside of career. You need to be as efficient as possible about that. The recommendation is take once a year, twice a year and sit down and actively think about what should I be moving more toward? What should I be moving more away from?

Which is some sort of beloved thing, but I need to broaden myself. I did this exercise when we first started talking about the Build Your Own Radar business. It made me realize that, so I was trying to move more into general architecture, and I was spending a lot of time on Java language stuff, Java forums and other places where I felt comfortable and had friends and not enough time on .NET and Python sites. I needed more perspective on those.

Doing this Radar exercise forced me to reallocate my time to broaden what I was looking at. It's a way of organizing your thoughts and your career directions in a loose scaffolding to make sure you don't get accidentally blindsided by collapsing bubbles.

Ken: This is probably a good time to-- We've hinted this throughout, but I do want to be explicit about it. In a case like what Neal just talked about, it's probably a living document, it's getting updated, et cetera. Ours, if you look at it online, is a spot in time or a point in time. Just understand that. If you're looking at ours and you look up a blip, and it says, hey, this went into Adopt in 2017, so they must still be using it. That's not the case. it might be, but that was the truth at that point in 2017.

If things haven't changed for a while, they'll fade from the Radar, they'll go away. Unless there's a compelling reason to re-blip it and move it, it probably isn't coming back. Understand that. When you look at ours and things, and you're like, wait, there's only five things in Adopt? There's only five things you work with? It's like, no, there's only five things that moved to Adopt in the last two issues or what have you. Just something to keep in mind.

Neal: Or you do an organic search for Angular, and it shows up in Adopt, and you don't realize it was in Adopt in 2018.

Ken: Exactly.

Neal: It maybe not being Adopt now. One of my longstanding requests, but that our digital team is too busy to work on, is to degrade the visual image of older blips and make them look like they're old typewritten images or something. The older it is, the more degraded the image is. It looks like it's written on old scroll or something. Just to let you know that, hey, this is a blip, but it's old. Some way of degrading it, some visual cue. Obviously, other things have been higher priority than that.

Prem: I want to be able to time travel. I want to be able to go from current edition to the previous one to the next and the previous, and so on and so forth, and see these blips fade away, become more prominent and that kind of animation. I guess I'll have to wait or maybe build my own version of the Radar.

Neal: If you look on the request list, the backlog of requests on Radar, I think what you just described is a number three on that backlog. We used to actually, many years ago, when it was a static publication before it became a website, we used to have a little visualization that showed where it moved from the last Radar to this one, this little ghost thing, but it got really cluttered. As soon as AJAX came out, I thought a perfect use of AJAX, if anybody remembers AJAX as a technology, would be to create a slider on the thing and it'll let you slide backwards and forwards and see the blips move. [Laughs]

Prem: Thank you very much, folks. Any parting thoughts before we call it a day?

Neal: I would recommend looking at using it. It's an open source tool. Our recommendation when we do it for clients, because it's not a complicated process, is even if we facilitate the first one, you don't need us for subsequent facilitations because you see how it works. The main thing you need is what Ken says, a strong facilitator. You can do this yourself. We really strongly recommend that you do this because, yes, you get a shiny artifact, but what you really get are the conversations that you never have. That's the thing that is really valuable. Like many things in software, a lot of things in agile software development, it's really just ways of tricking people into having actual conversations with each other and spreading information that way. That's exactly what this is.

Prem: Anything from you, Ken?

Ken: No. Neal summed it up. I guess just, spoiler alert, when this podcast comes out, watch for Volume 31. Follow in by a week or two and let us know what you think.

Prem: Absolutely. Yes, I just checked. AJAX has never featured in the Thoughtworks data, unfortunately, but maybe it might still do. All right, folks, that's all we have for this week. We will see you next time. Have a wonderful day.

Neal: Thanks, Prem.

Ken: Thank you.