Show Notes
Andy and Mon-Chaio continue their journey into organizational models by discussing the Team Software Process (TSP). They touch briefly on the origins and history of TSP, its relationship with the Capability Maturity Model (CMM) from Carnegie Mellon, and how it helps teams organize their software development processes. The discussion takes a turn to the philisophical as they explore the empirical nature of TSP, its focus on measurement, and the importance of data-driven decisions. They also debate whether TSP qualifies as a true system of knowledge. By the end, listeners will gain insights into the practical applications of TSP and why it might prompt them to re-evaluate their own measurement practices.
References
- The Team Software Process – https://insights.sei.cmu.edu/documents/645/2000_005_001_13754.pdf
- Using TSP Data to Evaluate Your Project Performance – https://apps.dtic.mil/sti/tr/pdf/ADA537112.pdf
- Rationalism vs. Empiricism – https://plato.stanford.edu/entries/rationalism-empiricism/
Transcript
Andy: And we’re back for yet another episode of the Tactics for Tech Leadership Podcast. And this time we are continuing our meandering journey through. How you can understand an organization through models and diagnose it and come up with, uh, changes to make, to reach a better state. Last time, if I remember correctly, we spoke about the four areas of knowledge.
Is that right, poncho? Is that the one we were talking about last?
Mon-Chaio: Ooh, no. Last time we talked about alien
Andy: Oh, last time was alien chess. [00:01:00] Yes, but we, this one also came out of the four spheres of knowledge, just like the alien chess one kind of came out of it.
Mon-Chaio: right
Andy: and what we’re gonna talk about this time is something called the team software process.
So our question on alien chess was, is it a model? Does it help us define something? Hopefully what healthy means? Does it provide any way of explaining interactions between components of a system and all of that. This time, we’re gonna do a very similar thing with the team software process. How, how do you think we should start with this? We got the team software process. We, we should probably tell people what that is.
Mon-Chaio: Right. Um, yeah, I think we should tell people what that is and then we can decide which, if any of the four spheres of knowledge it fits into maybe a combination of some of them. And then just kind of talk through, just like we did with Alien Chess, is this helpful for how, helping us figure out, [00:02:00] uh, what.
What healthy is, what steps to take to do remediation, how to figure out symptoms to know that your team is unhealthy
Andy: Would, would this give us a way of diagnosing and treating?
Mon-Chaio: Right so it’s called the Team Software Process, TSP, and it’s been around since what, the early two thousands
Andy: Uh, late nineties is when they really started on it.
Mon-Chaio: Okay. And do you know anything else about the history of it? It seems like it may have come out of Carnegie Mellon.
Andy: It came out of, well, kind of car, Carnegie Mellon. It came out of research into the CMM, or I should say it came out of problems from the CMM or questions about the CMM. So the CMM is the capability maturity model. And it was a thing created by Carnegie Mellon and, and [00:03:00] others, I think, to describe what does, and, and this might even lead us to another episode, what does a healthy, high performing software engineering organization look like?
CMM defined multiple levels. You could have level one up to level five, I believe it was. And at each level, they had defined characteristics, what you would find at each one of those levels. And this model was created for, I believe, I might be mixing up my history here, but I believe it was created for the Department of Defense in the United States so that they could procure software and have a sense of they are giving this contract to an organization that is going to perform this, and they’re not just gonna waste all the money.
Mon-Chaio: Mm. Mm-hmm.
Andy: And the big question that came out of it was, okay, well this is all really interesting, all of these descriptions, but how do you do it? [00:04:00] And from that, Humphrey Watts, no, sorry. I always want to turn, turn his name around because it just seems like it’s the wrong way around. It’s Watts.
Mon-Chaio: right.
Andy: Watts Humphrey started defining the Personal Software Process, the PSP, and then because te, uh, because software isn’t created by individuals on their own, it’s created by teams, then they created the TSP on top of that, and so. What you can think of is that the way this fits all together, and I’ll hand this back to you Mon-Chaio in just a second to get into what the TSP is, but a way of thinking about how it all fits together is you’ve got this umbrella of CMM, which is how an organization should be operating.
And underneath CMM, you have the team software process, which defines [00:05:00] how a team organizes to get things done. And then underneath that you have the PSP, the per Personal Software Process, which defines how an individual on that team operates in order to create good software. So,
Mon-Chaio: Mm-hmm.
Andy: mhow, I’ll hand it back to you.
We’re kind of starting in the middle of this layer cake,
Mon-Chaio: A little bit. I think, I think the umbrella thing was, was important to connect it back towards CMM. I didn’t know that it spawned out of CMM. That’s interesting. I’ve definitely seen the CMM levels, but I’ve never dug into what’s in, in the, each individual level. Honestly, usually I kind of poo poo it and move on.
Andy: It, it, it, it is, it is a big, difficult thing, and in fact, we will, I think what we’ll understand is. Why a lot of people poo poo it and, and try to move on when we get into TSP and PSP, because I’m gonna say I don’t think they’re easy.
Mon-Chaio: [00:06:00] They absolutely are not. So I think this is a good time to just talk about what is TSP. TSP is a framework, as you mentioned, Andy, for creating software, and using creating software as a team. And the way that I would describe it is there are a set of pretty rigid processes. So I think the first part would be launching a TSP team.
And what they would say is, anytime you have a software project, you first have to launch a team, and there are, I think they note 10, nine or 10 different activities or meetings that you have to go through in order to launch a
Andy: Over about four days.
Mon-Chaio: Over about four days. Right. I’m not gonna go through all of them. I mean, we can touch on the interesting ones as we come back, but it’s stuff like establish product and business goals, or develop the quality plan or produce a development strategy or communicate it to management, that sort of a thing.
[00:07:00] There are a bunch of guidelines on each of these areas on how you might go about doing that. What you need to come out of each layer. And again, they divide it up into four days. So there’s three activities. Day one, three on day two, two on day three, and it looks like two on day four. So it’d be 3, 6, 7, 8, 10, and then.
Beyond that, they have an execution plan. And so they say once you have your TSP plan and you’ve launched, then it’s the execution. So there’s areas like how do you lead a team, communication, maintenance of the plan. They have this thing called earned value, which they talk about is how you decide whether you’re being successful or not, and how you communicate progress outward.
And then they have rebalancing the team workload. They say that in order to be most efficient, which I can already, if you’re a long time listener of the podcast, I’m sure that term grates on you [00:08:00] as it does on us. Um, you wanna make sure that all of your engineers are balanced, that they all have the same workload, and so they talk about how do you go about rebalancing the team?
And then they have a section for quality. How do you figure out quality problems? They have things like, uh, defect removal profiles and defects per KLOC as measurements of quality. So it really is a process document for how a team goes about producing quality software. And despite what the tone that we might have taken, there is some research, I believe Andy, that shows it quote unquote works
Andy: Yeah, they have implemented TSP with, with a fair number, like I, I. The documents I was looking at are from like 2014, and they, by that point implemented it with at least five or six very large organizations. And here’s the key part of TSP and [00:09:00] PSP. The key part is it’s all based on measurement. Like everything drives you back to measure something. Now, we may disagree with their measurements, but that is what their grounding principle is, is that we’re going to measure, you mentioned defect rate.
We’re gonna measure defect rate. We’re gonna measure we’re where those defects were found in the process. We’re gonna measure progress to plan. We’re gonna measure how much, uh, work is on each person. We’re gonna do all of this stuff very empirically. And from that, their claim is that because they have that information, they can now know the health of the, of the team and the health of the project and, correct.
Mon-Chaio: Yep. And I think we would agree, Andy, that measurement is important, right? I don’t think we would disagree with
Andy: Yeah. I, I, I think. I don’t go to the same extreme that this process goes for measurement when I think about it. [00:10:00] But it does make me question maybe I should be much more on the measurement side than this is, or than, than, than I am right now.
Mon-Chaio: Yeah, I, I would agree. I would say that, part of the agile movement, or at least the way that the industry is taking the agile movement has sort of become less and less bureaucratic, and I think a lot of people see detailed measurement is being very bureaucratic. Know that when PMOs organizations come to me and generally say, look, I want to track this and that I want to have these sorts of spreadsheets and, and dashboards, um, I kind of have a visceral reaction to that.
Andy: And, and, and I think that’s one of the things is. They’re doing measurement in this process, but one of the things they start with is training.
Mon-Chaio: Mm-hmm.
Andy: So part of this method, part of their model is that you can’t just take any old software engineer and say that you’re now working in TSP. You can’t just [00:11:00] take any old project manager and say you’re working in TSP.
Every single one of them needs to be trained. Because people normally do not have the experience to do what they’re gonna be asking them to do.
Mon-Chaio: I believe they even say that everybody on the TSP team must be trained before you can project kickoff the TSP process.
Andy: Yeah. So, so there we have, we’re we’re starting to see, uh, aspects of their model. One is that training is very important to them. Training sets the foundation for everything. This, this starts getting into the PSP part of it. The personal software process. The personal software process is kind of that inner loop.
So if you think about the software development process, if you’ve got these loops after loops after loops. You’ve got TSP looking at that, um, mid-size loop of what is the launch [00:12:00] of the project. And then they also do what, what they call relaunches. So as their metrics come in and as they see that things are changing around them or changing their knowledge, they relaunch the project.
So they might do a whole re rerun of that launch process based on figuring out that, hey, everything has turned out harder than they expected. And so all of their estimates are incorrect. Their estimates, though, are based on their PSP data. So the PSP system asks developers to produce personal databases of their own time to create software, their own defect rate, their own, all of this other information so that they can improve themselves, but also so that they can do these estimates of a larger project and fit within a team to be able to figure out what’s going on. And that’s where, once again, that rebalancing that you mentioned becomes really important to the [00:13:00] TSP because the reason they say that you need to do it is just naturally your highest performing people end up picking up more and more work and it, and it seems like it’s the right thing to do.
So the people who produce the fewest defects end up picking up more work because “hey, that you want the highest quality.” But that might cause the entire team to slow down because now you’ve got two people who are doing 90% of the work every time and everyone else is just sitting around. So, and you didn’t realize that, uh, in the initial plan and, and it just kind of happened over time.
So you might end up having to relaunch by rejigging everything. Now all of the estimates are gonna be based off of a different person, the different history of creating software. And so the entire project plan might change, but it’s all gonna change, not based on people [00:14:00] just saying like, oh, well, I don’t know, I’m probably a little slower. It changes off of their historical data of the, the plan for this thing was to be three and this, it might go down to this detail. I don’t think they’d go quite this far. Uh, three classes of a hundred lines each. And this one is gonna be a complicated IO system, and this one is going to be a complicated UI system. And I know that I’m, uh, uh, 50% slower on that than Mon-Chaio. So when Mon-Chaio hands that task to me, the time it takes to do it is going to change because of the history that I have of my own data.
Mon-Chaio: Mm-hmm. And as you can hear already, there is, there is a lot of detail in this. Um, and so this is not something, as Andy was saying, that you just pick up and you say, oh, well let me just measure defects per KLOC and that’s gonna make me better. It’s an entire system or [00:15:00] process that’s meant to, I guess work together or fail, I think is what they would say.
It’s if you don’t do everything, you’re doing nothing.
Andy: And, and there was a, there was an interesting thing as I was going through this, I, it struck me that TSP and PSP to a lesser extent, because it, it doesn’t have this aspect to it. TSP is very much about define a plan and work on it. Work to the plan. Your, your definition of success is how well to the plan you’re going.
And that just struck me as wrong until, until I thought about it and I realized except the thing that saves it. I think the thing that makes it a healthy system in some ways is that it’s not, holding to that plan no matter what. It’s holding to that [00:16:00] plan to use it as a, as a measurement point to get some data to reevaluate, to change the plan.
Mon-Chaio: Exactly. It’s the relaunches and they even say the constant relaunches that. I don’t want to say, I don’t wanna say it saves it, but at least in my eyes it gives it quite a bit more legitimacy in terms of actually working in the real world.
Andy: Yeah. So I guess going through our questions a little bit, where in the spheres of knowledge does this fit or does it give us information?
Mon-Chaio: I think you and I might disagree on this. Let, let, let’s find out. Um I have a difficult time calling this a system, and the reason that I have a difficult time calling this a system is because as I was reading through these detailed [00:17:00] papers about the process, I didn’t understand the why, right? And the system is all about the why.
Remember when we talk about it both last week as part of the Alien Chess episode and the week before in the four spheres of knowledge. The important thing about the system is an understanding of how things connect so that you know, why changing one thing affects something else. The classic user, you know, the body example is I know that if this muscle is sore, it will cause these muscles to overwork because I understand the connections here and I understand how the body compensates. I didn’t find very much of any of that in this paper. And so that makes it very difficult for me to say, well, it’s a system. To me this is a solution. I think, it tells you what to do. It doesn’t tell you why to do it. It doesn’t really tell [00:18:00] you what healthy is. I’ll use the earned value example. It doesn’t tell you what healthy is, whether a hundred things of earned value a week is good or not, or whether meeting 96% of your earned value goal is good or not.
It doesn’t really tell you that. It just tells you this is what you should be measuring and you should be aiming for a hundred percent.
Andy: But there, right there though, you just said what it considers good.
Mon-Chaio: that a hundred percent is
Andy: Yeah. Or earned value. So you like everything, everything. There needs to be a range, but you might give it as a point. So to them, the earned value and it’s actually earned value percentage or something like that where it’s, it’s the earned value compared to the plan.
Mm-hmm. Yep.
It’s, it’s a hundred percent earned value compared to plan is, is what they consider good. And so when it starts [00:19:00] deviating from that, that’s one of their strong indications that you need to reevaluate and make a change.
Mon-Chaio: I mean, I don’t think they explicitly state that, but I think you can. I think it seems pretty clear, um, that that’s what they consider successful. Now when you go into their quality guidelines, I think they have a much deeper measure of what healthy looks like. For example, they say like, the goal is greater than 50% defect-free unit tests.
And they specifically list that out. They do have standards that are especially documented in the quality guidelines. And if we use sort of reading between the lines and saying, look, the earned credit percentage has to be a hundred. I would say that yeah, they do provide standards and then I think they provide solutions, but the other parts of it.
Symptoms. Uh, I guess a little bit insofar as if you have standards, your symptoms can be, it’s not meeting [00:20:00] standards. But I don’t think systems is a, a part of this. What do you think, Andy?
Andy: I, I think I disagree. I think I, I, I agree with you. I think on symptoms, it’s a little weak. It doesn’t really call them out. I think it does actually set a lot of standards. I think that they have very clear. From their measurements, they have very clear things that they think you should be hitting, uh, as you said, on the quality.
As for the why, I think that they do like, I think there is a why, and the why is that the only way to get better, the only way to have an effective system, is through empirical data. I think that’s their why. And, and it’s not to say that there’s, there’s an overarching why of the particular structure that they have.
Other than that, their guiding principle is you have to have the data. If you don’t have the [00:21:00] data, you’re not gonna be able to do anything.
Mon-Chaio: But I think that doesn’t make it a system in my mind. So as an example,
Andy: So what, what would be a why then?
Mon-Chaio: so as an example. The human body temperature of 98.6 degrees is the healthy standard. We know the why behind that. We know the metabolism rate. We know how much energy we spend. We know the exothermic reactions, so we can point to, if it’s not 98.6 degrees, it’s because these systems are interacting in a way that prevents it from reaching that state
Andy: Uh, so it’s not, it’s the why of this structure. It’s the why of those of those standards.
Mon-Chaio: Exactly. And why, like why is it that we have to have these launch processes that have 10 things? How does, or 10 steps over four days? How does one step relate to another? What happens if we don’t have step four?
Andy: I see, I see. So there’s not [00:22:00] the, without the clear connection to why this particular health standard, that comes naturally from the model of the system that they’re using. Uh, it, it’s not a complete system. I can grant you that. I think that though it does cover a lot of that, it, it, it not, maybe not in the article that we were directly reading, because this is more of like the, the white paper version of everything.
Mon-Chaio: Mm-hmm.
Andy: But even in this, I think they do get to some of it. So on the one that they have the most clearly outlined here, which is the quality goals. The quality guidelines, uh, they have for instance, that the number of defects per KLOC. So, uh, a thousand lines of code is to be, to be healthy, should be less than 10 during compile.
And we will, I might talk about that for a second. ’cause I was like, [00:23:00] compile, why? What are we talking about? Defects in compile, um. Less than five in unit tests, less than 0.5 in integration tests and less than 0.2 in system test. Now, they’re not gonna say the exact, like, why those numbers, but I think they could justify them.
What they are gonna say though is that it’s more of the relationship between those numbers. They, they need to be decreasing to the point where you can have a fairly good, um, trust that by the time you’ve finished system test. Because basically the test after that is your users that you’re at near zero defects.
That that’s, that’s the why of that because they have this model of a process that you go compile unit integration system. And in fact, they have in their model, uh, stuff before that, that it has to decrease and it has to decrease at a fairly rapid rate [00:24:00] of what defects you’re gonna find in each one of these phases.
Mon-Chaio: No. Yeah, I mean, I get that they have. Sort of weaker relationships between that to say, look, it has to decrease at a specific rate. But I think the strength of a model or of a system is that it can help me understand what I can do to affect it. So as an example here, I might say, look, I don’t wanna write unit tests.
And so your stand or your why is that it has to just decrease. What if I don’t write unit tests, but I still get, you know, less than 70% defect rate at integration, less than 90% at system tests. Is that okay? Or if you look further down on their quality standards, they have this, uh, design versus coding time ratio, and they say, your design time must be greater than your coding time.
The ratio of design time must greater than [00:25:00] your coding time. Well, why? Like, what if it isn’t, how much greater, you know, like 10 x 20 x.
Andy: I, I think mantra what you’re hitting there is the, is the philosophical issue with empiricism. So in science you can, you can say I’m completely empirical
Mon-Chaio: Mm-hmm.
Andy: and basically what you mean is everything is driven just by what you can measure in the world. And in that case, a lot of the, “why is it that way?”
Almost doesn’t matter. As long as you can say, this is the measure, this is the number, this is what’s coming out. And and we can explain how to, how to come up with why that, why that might happen, but not why that’s what’s happening.
Mon-Chaio: But it’s important for your solution space, right? So. [00:26:00] If, if you don’t know the why, then your solution space becomes nearly infinite. I’ll use the requirements, the coding time ratio example. So you are at, you know, 2.0 ratio of design decoding time, and you’re still finding your defect rates are high.
And so what is your solution space? Three x four x, um, you know, more meetings, less meetings, like you don’t know, right?
Andy: Yep.
Mon-Chaio: Because you don’t know the why of, like, why is that important? Why is that ratio important?
Andy: Yep, yep. But, but I’m, I’m gonna say you’re not, you’re not escaping the, this fundamental issue, which is that TSP is taking an empiricism approach. They’re, they’re saying, look, we have measured projects. We have seen these ratios show up. We have seen on, on projects where people say that this went well. We saw these ratios. On projects that it didn’t go well.
We’ve seen these ratios so empirically, this is what a good process looks like or [00:27:00] a good outcome looks like in these measures. Now, they cannot from that justify that unit tests have to be done. They like you, you were saying like, well, why can’t I just stop the, uh, skip the whole unit test thing? And if I get the same numbers, won’t I be fine?
They would say, we don’t know. That empirically does not show up. Like, or maybe it does and, and, and this is just a thing missing in what we’re seeing, which is maybe it does show up in their data and they’re like, Hey, yeah, you’ll do poorly.
Mon-Chaio: Right.
Andy: But they don’t know why. They can’t, they can’t explain the mechanism other than to say, well, you could have caught those things earlier.
And then this is with it. They’d lean on things like Barry. I’ve always pronounced it Barry Boehm, which I think is how it is pronounced, but I always uncertain, like Barry Boehm’s cost of change. Like, yeah, if you find the thing [00:28:00] earlier. It will cost cost less to change, and we want to reduce the cost of change.
So unit tests help you do that. What they, what they don’t have is they don’t have that complete rational, purely cognitive explanation of the world in which these numbers come out. So,
Mon-Chaio: I can grant you that, and that doesn’t make it not useful. I just think that makes it less useful because in my mind then you. they would say the same thing. You follow this process. This is the process to follow with no deviations, because our empiricism shows that this is the process to
Andy: Exactly. And that that is, that is like you’re, you’re, you’re getting to the complete argument of rationalism versus imperialism. Which is rationalism gives you a complete model that you can use to manipulate things. Empiricism just kind of tells you, [00:29:00] this is what it is. You have a, you have a really good understanding of what it is, but you can’t, you can’t really kind of envision something that isn’t, and that’s, that’s the fundamental issue.
And I think actually this is what we’re getting to with diagnosis. I can understand why you’re saying like, without this I can’t do diagnosis effectively. To do diagnosis, you need to be able to say, well, for this particular thing that I’m diagnosing and the, uh, the symptoms that I’m seeing, I need to be able to envision a different world in which they’re not doing that and they’re doing this other thing, and I need to be able to understand if they did this other thing, what would happen.
A purely empirical approach, unless we’ve seen that other thing doesn’t give you any information.
Mon-Chaio: Right. And it’s rare to have seen this other thing, especially in organizations, right? [00:30:00] No organization is the same as another organization.
Andy: So I think what the, the, the, the thing I would say is I think on the small scale. TSP can probably be useful because one, I’m gonna make the, uh, assertion one software team is not hugely different from another software team. One organization can be hugely different from another organization, but I think one software team is not gonna be hugely different.
Mon-Chaio: Yeah, I, I, can generally agree with that. I think most software team, well,
Andy: Hmm.
Mon-Chaio: I guess I’ll have to think about that.
Andy: Okay.
Mon-Chaio: If I think about, for example, a backend team versus a team that’s doing, like the early days of iOS development, for example, what they’re tooling allows them to enable. So perhaps in the early days there wasn’t a great integration test [00:31:00] framework for iOS, so that team would be operating differently, right?
Andy: I, I would say P-S-P-T-S-P would grant that they wouldn’t be able to predict anything because, and this is, this is the whole PSP thing of it is based off of the empirical data, the history of those individuals. And, and the TSP would be based partly on the empirical data of others who have done something like that.
So if they’re doing something like the very early days of iOS development, which is different enough and in a, in a framework that no one has ever worked in before, they would say like, we have no data to say what good or what, what efficient looks like.
Mon-Chaio: Perhaps I, I mean, I don’t, I haven’t talked to the authors and I would be interested to hear their thoughts on that because I would say even when this was published, sure it wasn’t iOS, but they don’t mention that there’s different [00:32:00] types of teams and that, you know, this is particularly useful for defense and aerospace or, or whatever.
Andy: Yeah,
Mon-Chaio: published this as software.
Andy: They, they do in the PSP literature make a, uh, caveat, or maybe it was on TSP, I can’t remember. A caveat that if your team changes too much or if your aims of your project change too much they, they can’t predict anything and. Part of the reason being like when you take that group of people and you produce a new team, as we’ve talked about, it’s a whole different group.
They have no history together. They don’t know how it’s gonna work. Um, if you take a software developer and you put them on a new system they haven’t worked on before, they’ve got no history, they don’t know how to estimate how long it’s gonna take to do anything. They don’t know how many bugs they’re gonna produce because they don’t know what they don’t [00:33:00] understand about interactions within that system.
Mon-Chaio: I think that makes sense. What else we wanna discuss here?
Andy: Is there, well, are there any tactics from this? I guess that’s the next one. Is there anything that people can take away from this?
Mon-Chaio: I think so. I, I, I’ll tell you about the things that I particularly liked about TSP and PSP. I mentioned that they have iteration in there. It’s, it’s. It’s sort of mini waterfall in some ways, or iterative waterfall. But I like the fact that even in a document, which is so rigid in terms of what you measure and how you do things, there is an explicit acknowledgement that plans change and that we have to adapt to the changing plan. Longtime listeners, again, may just take this as a given, but I think that’s a tactic, right? Like even the most rigid processes are saying that we should adapt to the plan. So if you’re in a process or you believe in a [00:34:00] rigid process that doesn’t say that, you know, perhaps reexamine the process.
I really like that they include PSP in here. And so while I sometimes think that software development is too focused on the individual, and the idea is that if you add up all the individuals and um, then you’ll get the team output. And the better each individual performs, the better the team will perform because you’re just, it’s additive, right? I like the fact that TSP talks about it from a team level, even though in some ways TSP is really additive of the individual level,
Andy: It is kind of, yeah.
Mon-Chaio: but PSP isn’t just about metrics and tracking the individual level. They do talk about being trained and having a skill, and I think it is really important to think about. Constant improvement of the individual engineer and individual engineer skill. Um, so I think that’s weirdly, kinda loosely represented in here in a strange way, but I like [00:35:00] being able to take that nugget out and say, look, as an individual engineer, you should be improving your skills.
Now, whether your skill is fewer defects per kloc, we should analyze and say maybe, maybe not. But the fact is you should be tracking yourself and improving your skills. So those are the two things I think that stood out for me.
Andy: Yeah. And, and I want to add on to it. I think from our discussion, it sounds like TSP and PSP is entirely just about tracking these metrics. It’s not so, PSP, it, uh, it’s a big focus because I think they’re so empirically driven. But in TSP for instance, they have a number of roles that one of the early phases of a launch is to figure out who is playing which role.
And some of those roles are things like the team lead. And the team lead has specific things that they need to do. And I think they’re all good things to call out and, and also the idea that those [00:36:00] roles need to be handled by the team. They’re not individuals doing only that thing, but the team is handling all of this, all of the different activities that need to go on.
I really like that as a way of making it so that the outcome of the project is a thing discussed and organized by the team. I really like that TSP works through that.
Mon-Chaio: Hmm. See, I, I, I’m of two minds there. I like the fact that they call it out and I think it’s not called out enough to, so to say during planning you need to have a security lead, for I think that’s important. And yet they say later on about tracking, they’re like, when you report your security lead needs to report the security stuff. So to me that sounds like it’s owned at, at an individual level again, uh, which
Andy: Y Yeah, I, I, I, I, I think I understand where they’re going, which is that if [00:37:00] there’s not, they’re, they’re going from the belief if there’s not an individual. This could be the underlying system that they have there. If there’s not an individual responsible for it, it will, it will slide and possibly won’t get done.
But if you can say that you have a security lead, and the security lead needs to be producing this report, then you can go to the security lead and say, yeah, why haven’t I seen that report for five weeks?
Mon-Chaio: Mm-hmm. Right.
Andy: I think that there is a lot to TSP that we haven’t gone over. That I think people could really look into because I think it’s probably one of the most stringent and studied of the processes that has probably ever been defined.
Mon-Chaio: Mm-hmm.
Andy: and so I think it has a lot of basis to it. The other thing I like is there’s the emphasis on measurement. I think a lot of people in software could [00:38:00] actually enjoy. I think there’s a large number of people in the software industry that like doing the, like quantified self and PSP and TSP gives a way of doing that, that then also feeds into how to do your job better. And, and so it, it kind of gives that basis for, Hey, look, this is a, a may way of quantifying yourself that will help you improve in a way that has been shown to work for software engineering.
Mon-Chaio: I like that very much as well. And I think that’s an overarching thing for me, which is when you, if you take this paper and you start reading through it, it’s very easy in the first 10 pages to say, ah, this is a bureaucratic process that, uh, is measuring the wrong things and just completely dismiss it out of mind. [00:39:00] But I think it’s important to think about these things because there are nuggets of real goodness in here. And Andy, you measure that. You mentioned that measurement part, and we mentioned it earlier on, very early in this episode too, which is perhaps we should be measuring more like we have to measure the right things.
It doesn’t have to be measuring this, but maybe reading this paper tells you, yeah, you know, actually, let me try measuring more. Let me see what that does.
Andy: Cool.
So I think what we’d like to know at this point is, have you found TSP to work? Have you practiced PSP? If so, get in touch and let us know. We haven’t practiced it technically ourselves, and so we’re really interested in any experiences that you’ve had. If you are interested in exploring how you or your company could get better at this, this measurement or explore the ideas of TSP or PSP [00:40:00] or anything related to this to diagnose how your, how your organization could get better.
Please get in touch. Mon-Chaio and I are both here to help you on that. We are at hosts@thettlpodcast.com and we will be continuing this exploration of the four spheres of knowledge. Next time and for, well, probably a few more weeks after this. So until next time, Mon-Chaio. Be kind and stay curious.
Leave a Reply