One of the big problems I see with a product orientation (as opposed to a project) is in preparing for ongoing work. You might not start the next project for this product after you complete this project. You might have to round-robin projects for various products because you don’t have enough people to do all the projects at the same time. However, if you want to develop a product orientation, you’ll need to consider the future. I like to consider the future not in design or architecture, but in technical excellence. If not, the team becomes hostage to the technical debt.
I often hear people say things like, “We can fix that later.” Or, “Our customers need us to solve problems, not gild the lily.” It’s possible the team is polishing already-existing work. My experience is that too often, managers of varieties (and product owners) push a team to stop thinking about the future and concentrate on the now. We call it technical debt. In reality, it’s unfinished work.
Technical excellence in a previous version allows us to move faster on a later release. (Regardless of whether that release is an iteration or an entire project.)
I wrote about the need for quality depending on where your product was in its product lifecycle way back in Quality Driven Project Management. (I also wrote about more about these ideas in Manage It!)
That need for quality is about what the customer sees. You might need a different definition of internal quality for what the product developers (developers, testers, UI, everyone who creates the product) see.
Here are some aspects of technical excellence for internal quality:
- Ease and speed of the build system
- Ease, coverage, and speed of unit test automation
- Ease, coverage, and speed of system test automation
- Readability of code and automated tests
- How much manual testing you need. This is not exploratory testing. This is manual testing because it’s not automated.
I’ll stop there. You might have other technical excellence needs for your product such as performance or reliability or footprint, etc.
The ease and speed of the build system and the various test automation is about the product developers being able to stay in flow and get feedback on their current work. Without ease, people don’t want to check in and kick off a build. Without speed, people don’t want to check the tests to see if they broke anything.
You can’t get to continuous integration (and at some point, continuous delivery) with build and test ease.
Why readability of code and tests? Because that’s what most product developers do all day. They read code that’s already there. They read tests already there. That’s how they decide how to add that small feature and which new tests they need. If the code and tests are not easy to read, people reinvent the wheel—often applying Conway’s Law—and increase complexity in the code and tests.
The more manual tests you need, the less ease you have in running the tests and the less support the product developers have in knowing whether they’ve made a mistake. We run spell check as a matter of course for much of our writing. That’s an automated test. Why wouldn’t we run most of the tests for our product as automated tests?
If we pay attention to these indicators of internal quality, we can create releases faster. Does it mean we “slow down?” Maybe.
You’ll slow down if your team doesn’t pair, swarm, or mob. That’s because you have to schedule code reviews and test reviews. That scheduling takes time and interrupts the work people are doing now.
You might slow down if you have no documentation. I like architecture descriptions and pictures of the architecture, so people can see their guideposts.
And, don’t tell me about self-documenting code. That fallacy has been around for as long as I’ve been alive. It was wrong then. It’s still wrong. We need to leave guideposts for the next person to touch this code. Even if we are the next person.
If you continue to build in technical excellence with every small change, you’ll discover you don’t need time to build it later. (I wrote about this in Create Your Successful Agile Project.)
Technical excellence helps each person consider the effects of what they do on the future product. The more you clean up after yourself right now, the less cognitive load you have when you return to read about this code or test later.
Keep technical excellence in mind if you want/need a product orientation.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Product Orientation Requires Technical Excellence Opinions expressed by Java Code Geeks contributors are their own. |
