Consider The Downstream Effects - Mike Cohn

Consider The Downstream Effects - Mike Cohn

Have you ever looked at the pipes under a bathroom or kitchen sink?
If you do, you’ll notice that the pipe doesn’t run straight from the sink to the wall. Instead the pipe from the drain goes down farther than necessary, curves right back up and then heads into the wall.
This little extra bit of pipe that goes down farther than necessary and u-turns back up is called a P-trap. That’s because it looks like a P turned on this side.
Why do plumbers install P-traps? They must cost more to manufacture, so it increases their costs, which they may or may not be able to pass on to customers. They’re a little harder to install, so they cost the plumber time, too.
So, why?
 
Plumbers install P-traps because they prevent downstream problems. A P-trap under your sink traps gases that would otherwise rise back into the house. They also catch small items that fall down the drain.
And good plumbers care about this even though they know they may not be the plumber to return to fix the problem.
Good plumbers care because they’re good plumbers. Installing a P-trap under your sink is simply the right thing to do because it prevents downstream problems.
 
We want agile team members who behave the same way. Good agile team members care–not just about their own work but also about the work of everyone downstream of them.
 
OK. Back to the example. A while back, I helped a team incorporate more automated testing into their work. Some programmers, who viewed their job as nothing more than writing what they considered good code, balked at the idea of altering their code to make future testing easier. Code testability, they argued, was not their problem; it was the testers’ problem.
The situation came to a head during a sprint planning meeting, when the testers were giving some really large estimates for testing code that was going to take only a fraction of that amount of time to program.
The programmers were asked if they could do anything to make the code easier to test. And it turned out there were some things they could do, but some of the programmers didn’t want to do them because they felt it would make their code less elegant.
They had defined their jobs as merely writing good code. Who cared if that code was hard to test?

Why Do Something If It’s Harder?Act Like a Good PlumberI'm going to give you an example of why this matters, but first, I need a favor. Would you take this short AI survey?
We want to learn more about how Agile teams are using (or thinking about using) AI in their work. Your input will help us better understand current practices, opportunities, and challenges—and we’ll be sharing the results with the community.
Take the survey here: https://www.surveymonkey.com/r/ZJY2SXY

“They had defined their jobs as merely writing good code. Who cared if that code was hard to test?”If my plumber had done that, I would have had a fully functional sink, perhaps for years. But eventually enough debris would have made it past where a P-trap should have been installed and deep into my plumbing. This would have led to an expensive--and easily avoidable--repair.
When team members accept responsibility for issues caused downstream of their work, that team can begin to grow from good to great.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/