Spot on Joe. Speed, quality and productivity should be outcomes of the system you are part of. Not measures of individual output. Productivity for a system’s (and/or team’s) purpose. Now I know what to read on my trip to Thailand in December :)
Great topic for 5 minute Friday. Nailed it. I am going to have to dust off the Peopleware book!
Not doing intentional quality over and over again is the new definition of "insanity".
I am going to use this quote next week: “The organization that is willing to budget only zero dollars and zero cents for quality will always get its money’s worth. A policy of “Quality - If Time Permits” will assure that no quality at all sneaks into the product.”
Some observations that inhibit quality.
1. As part of your company's SDLC, is doing unit testing/quality checks intentional? Is there a sprint where quality testing pass/fail actually occurs? Are there test scripts? Are there even requirements to write test scripts against?
2. If you have number 1, do you have a dedicated QA/Test Team? Now this is intentional, transparent testing, where other people/automations actually test the pipelines, mappings, metrics? It is amazing how much better code gets, when it is dependent on other people calling out defects ;).
3. If you don't have #1 or #2 - My finding is quality is based on the experience and "caliber" of the developer for delivering quality. Frankly, we are high paid individuals, quality should be included as part of our business and technical "value". Joe, I recall a podcast you had done a few months ago, can't recall which one, where that "caliber" word came up as a response from the guest of feeling that tech skills were declining, and developers/architects just are not as well rounded/knowledgeable as they were in the past, causing delivery/modeling/quality/architecture sloppiness. I see that more often.
The other famous statement that fits into delivery is "Fast, good or cheap — pick two". Want it fast and cheap? It won't be good.
Spot on Joe. Speed, quality and productivity should be outcomes of the system you are part of. Not measures of individual output. Productivity for a system’s (and/or team’s) purpose. Now I know what to read on my trip to Thailand in December :)
kap khun krap! (Thanks in Thai)
Great topic for 5 minute Friday. Nailed it. I am going to have to dust off the Peopleware book!
Not doing intentional quality over and over again is the new definition of "insanity".
I am going to use this quote next week: “The organization that is willing to budget only zero dollars and zero cents for quality will always get its money’s worth. A policy of “Quality - If Time Permits” will assure that no quality at all sneaks into the product.”
Some observations that inhibit quality.
1. As part of your company's SDLC, is doing unit testing/quality checks intentional? Is there a sprint where quality testing pass/fail actually occurs? Are there test scripts? Are there even requirements to write test scripts against?
2. If you have number 1, do you have a dedicated QA/Test Team? Now this is intentional, transparent testing, where other people/automations actually test the pipelines, mappings, metrics? It is amazing how much better code gets, when it is dependent on other people calling out defects ;).
3. If you don't have #1 or #2 - My finding is quality is based on the experience and "caliber" of the developer for delivering quality. Frankly, we are high paid individuals, quality should be included as part of our business and technical "value". Joe, I recall a podcast you had done a few months ago, can't recall which one, where that "caliber" word came up as a response from the guest of feeling that tech skills were declining, and developers/architects just are not as well rounded/knowledgeable as they were in the past, causing delivery/modeling/quality/architecture sloppiness. I see that more often.
The other famous statement that fits into delivery is "Fast, good or cheap — pick two". Want it fast and cheap? It won't be good.
Thanks again Joe!
Absolutely spot on. Move slow first before you move faster .. we have ignored this age old method in the troubled times of Agile.