Process Isn’t a Four-Letter Word

David Tuma

Agile methods emerged as a direct rebellion against the heavyweight processes of the 1990s. And the Team Software Process (TSP) did too, by brilliantly reimagining process in a lightweight, agile way that empowers self-directed teams to achieve remarkable performance.

People who are familiar with both know how powerfully they work together. But those with only an agile background often see a process definition and reflexively think, “Waterfall!”

This session will explore ways we can reshape the conversation to clarify why good processes amplify agility, rather than constrain it. It will also share process modernization ideas that high-maturity teams can use to take performance to the next level.

https://softwareexcellencealliance.org/process-isnt-a-four-letter-word/

Your experience, ideas, and perspectives are too valuable not to share. Join the discussion by posting them here.

Attendee

Dave Webb: Remembering way back in Watts' original PSP book, he said, "Until we get to a point where the software engineering environment can capture most of the data automatically, this is probably going to be a difficult thing to implement." It was a long time ago that he wrote that, but I still think it's true. I think that there's some inherent humanisms that make it difficult to collect some of the data that are useful to us.

But then you and I have done some data analysis, and found out some of the things we thought were very important turned out to fall out of the data set.

So I think one of the key things we need to do as we push forward and try to integrate these two (which I think is a brilliant idea!) is to identify those things which are most important to collect before we say what's the easiest to collect.

David Tuma

Attendee Agreed. What's the most important to collect? And I would also say, what can we do with the data that we have?

Within the TSP community, our introduction strategy for the past 20 years has been, very literally, waterfall. We put everyone through at least a week of training before they start their first project, which is a lot of upfront investment.

But it stands to reason, many of the things that make up PSP and TSP existed before PSP and TSP came along; TSP just brought them all together. If they existed before, they should still usable as standalone ideas. So let's talk about how we can introduce those standalone ideas as gradual changes, and then allow them to have synergy as they snap together.

Bill Nichols

David Tuma Let me ask the difficult question. We can assume that the practices and the things we do are separable and each have value. But I could also frame it differently: which edge of the scissors cuts the paper? Or which piece of the watch is most important? Which of those gears? So, it comes to, how would we know?

David Tuma

Bill Nichols Absolutely. You know, one of the things that I love about our community, we're all engineers, and we're all racing in to solve the trickiest problem.

But I think the fact of the matter is that as a community, we've spent the past 20 years doing these integrations, coming up with ways to use PSP and TSP and agile methods together. It's just a shame that we've all done them one organization at a time. We haven't come together to create a shared, common integration, and as a result we don't have a shared target to continually improve as a community.

In the TSP community, I can say something like, "I have a CPI of 1.01," and everybody else knows exactly what I mean. They realize that's an amazing achievement and can applaud me for it. But for all the amazing things we've done in the area of TSP/agile integration, we can't share our successes with each other because we don't have a common framework, we don't have a common vocabulary. Let's rectify that and make that shared thing.

Alan Willett

In the bottom right corner of the diagram on slide 14, what I thought was missing was results.

Has anyone heard the latest news about Grand Theft Auto? It's already been delayed twice by over a year, and it was delayed again one more year. Grand Theft Auto is a $2 billion franchise, so a 2 year delay represents billions of dollars of revenue. Their official statement said they had to do more polish before it was ready for the public. To me, I would assume that's a polite way to describe severe quality issues.

Sometimes Agile helps people feel better: "look, I'm going so fast!" But to me, it's the results that are important. Dan Wall worked with video game engineers and artists at Vicarious Visions, and helped them crack defects and achieve remarkable results. People need to understand the power of results, and recognize their ownership over that power. And I think that has to be a rubric that's part of any manifesto.

Dave McKenna

To me, the bottom line is that Agile enables humans to be high-performing. Where I worked in the 90s, they would drive teams to exhaustion to get things out the door. Agile turned that on its head and said, "the teams are the experts, and they know how to build the software - so let them!"

I now work in the mainframe software division of Broadcom. We have to have discipline around the engineering practices and the quality, because every Fortune 1000 company in the world has a mainframe, and our software is running there. When our stuff has bugs, it's on CNN in the morning. The last time one of our products had a bad bug, all the ATMs went down in Europe.

That really forces a focus on quality. So what David is saying kind of resonates with me, because I would love to help you guys build a new manifesto that centers around agile practices mixed very tightly with good engineering practices.

I think that's what a lot of the agile guys miss. They'll look at code reviews, and say "that's waterfall." Well, it's not. It makes sense. Or they'll say, "that looks like a gate, and I don't like gates. I'm agile." But that's incorrect. Reviews and quality checks are still agile and they just make sense.

And guess what, kids? The world is changing. AI is turning everything on its head. It can make us do things faster: faster good, or faster bad. My take on AI: I think it would beat me in chess every time, but it would never beat me in poker - because it can't deal with my quirky humanness. So I don't think AI will replace us: it's the humans that are creative, that build things, and that deliver value in the end.

So I think an integration of agile and quality engineering is a great idea. I like it, I'd love to be involved in it, because I think this is the next step. If we put some discipline around both engineering practices and agile, and come up with a manifesto and a way to do it that makes sense in the modern world...it just makes sense to do something like this.

Attendee

Jeff Pulcini: A couple of things resonated with me. One was what Alan Willett said about results. And like Dave McKenna said, we're dealing with a bunch of human beings here. And also as David Tuma said, as a bunch of engineers, we always like to jump in and solve the toughest things first.

So whatever final product we deliver, I think we have to have a matrix of the results you want, and the tools you can employ. Because every time we walk into a new organization, they have their way of doing things. If I walked into your organization and said, "we're going to throw this TSP stuff away and try all this new stuff instead," it just wouldn't fly.

We're constantly dealing with cultural change. So I think we have to focus on the results we're looking for, and make the roadmap flexible enough that we can go into an organization, play to their strengths, and then improve as they go along. Because it's not going to be a big bang.

David Tuma

Attendee I agree. Different organizations have different priorities: some may value absolute customer flexibility, and others may have a real need for predictability. The tools that different teams use are going to be different, and so we need to ensure that the incremental approach doesn't assume just one path. You need to be able to pick and choose the things your team needs, and not be saddled with the ones you don't.

Barti Perini

I just wanted to share our organization's experience. We've been a high maturity CMMI level 5 company for the last 15 years. And we've embraced the challenge of moving to agile ways. Our high-maturity teams really are self-managed; and during retrospectives, they've come up with the best integrations of both worlds.

We're currently piloting one of the things that @David Tuma shared in this presentation. In the past, we've used pure TSP for peer reviews: tracking defects, returning it for rework, and waiting for that rework to be done. Management plots the data in SPC charts to see if the process is under control and whether we're getting good results.

We were very reluctant to let all of that go; but the teams convinced us they are not getting as much value as expected from tracking individual defects. So they've started using the continuous inspection approach David described. They give feedback via comments in Git, and are doing the rework there. Instead of tracking every single defect, we're looking at the number of review comments and the product size. We're still able to plot our SPC charts, and it's a big win for the developers because it fosters continuous development. It's reduced their wait times and their defect tracking overhead, and it's made reviews super fast.

It's transferred some responsibility from management to the developers to monitor the review process and make sure it's performing; but they are able to leverage metrics the tools are generating. It's been a big shift in mindset for us, at both the team and management levels, but it's been a big success so far.

Attendee

Dan Liedl: I think this is a great concept. There's a lot of different things that I've been thinking about. There's a lot of volatility and uncertainty from digital transformation and AI.

One of the important things, in both TSP and Agile, is communication. It's important to share challenges and innovations, break down the silos, and bring in other stakeholders. Our peers and end users have skin in the game too; is there a way we can get them engaged in whatever product we create?

Another challenge, is how can we make this tool agnostic? Data-driven decisions are important; but every company we go into (and sometimes every team) seems to be using different tools, different methodologies, and different ways of working. That's exactly what we want, as long as they are effective and efficient and have continuous improvement. But how do we capture metrics in that environment so we're all using the same language?

But ultimately I agree: I think this is a really good venture.

David Tuma

Attendee As a tool developer, I totally resonate with your tool questions. If it helps, I've spent the last 20 years thinking about them, and so I've got some great ideas on how we can address some of those challenges. But I could definitely use the help of the rest of the community to work on the pieces related to people and interactions, because my "marriage counseling" skills only go so far. 😄

Bill Nichols

We've been doing research on the data that comes out of mainstream Agile tool pipelines, and ways that we can interpret that data to support higher maturity. It's still a big challenge, and part of the lesson is you need to step back and get a bigger picture. You can't just take what's coming out of the pipeline and get much useful interpretation, because the interactions between systems are important.

For example, in a Git repository, what kind of code is coming in? What files have been touched? And in the meantime, what stories have been flowing through the system? How much of this is new work, and how many of these stories are bugs? It's a complicated problem, in the sense that it doesn't lend itself to being totally reductionist. You've got to take an overall view.

But you can still get a lot of insights from the tools. They're not going to be the same as what we get by taking our own notes; but even being able to count the number of defects can be enormously powerful. That's why it's research right now.

Michael J. Berry

I've been a big fan of Deming, and the systems thinking he introduced. One idea he shared was that bad management says, "we need results," but good management optimizes the process so it produces the maximum outputs. He said you can take any production process, abstract it to repeatable steps, and put a quality structure around each repeatable step, and that is the true definition of total quality management. This is extremely profound. When you create a structure of repeatable steps that we're all using, it creates a hook to hang additional information on.

But that's only part of the challenge. The other part is capturing institutional knowledge, so lessons learned are passed along to new people who begin using the process. That enables you to move from individuals operating at their best level, to a world-class environment where people can benefit from the mistakes and lessons and knowledgebase of the past. It helps people avoid omissive mistakes and have fewer fires to put out downstream, saving their capacity for productive work.

Attendee

Priscilla Becker: Software development methodology is like a bike provided to use to cross the street. If I know how to ride a bike I am going to be more likely to successfully use the bike to get across the street. If I don't know how to ride a bike I am likely going to fall a few times. Training seems to give people/teams/organization a false sense of knowing. Skill sets in terms of experience should also be a part of methodology. I often see omission of experience as a consideration when building teams.