juha riissanen's List: Key References

• knowledge work as work that is done in the workers’ head instead of with their hands. He concluded that knowledge work would be the most critical and the highest-valued form of labor.
• In knowledge work, success comes entirely from people and the system within which they work. Results are not the point. Developing the people and the system so that together they are capable of achieving successful results is the point.”
• how then does one measure the performance of agile-lean product development teams
• Dwight D Eisenhower said: “If you fail to plan, you plan to fail”. As you plan, if you do not know where you are it is very difficult to get to where you want to go. As you plan your steps, continuous improvement in self, team, enterprise, process and product should be part of your plan. Measurements and metrics help us determine where we are and guide us to where we want to go. It is important though to measure the things that matter and refrain from measuring things that don't matter.
• RTF or Running Tested Features
• How many customer-defined features are known, through independently-defined testing, to be working? Now there's a metric I could live with.
• Running Automated Tests are one measure
• “Within limits, the more running (i.e. passing) automated tests a team has in place is a positive measure of quality. Beyond a certain level, this will cease to be true, but we have not yet met a team that has reached this point. (We hope to!).”
• “Items (stories) in-progress is a productivity metric. It seeks to help a team track whether they are working collaboratively or not. The idea in an agile team is for the whole team, as far as is reasonably possible, to collaborate on a single work item until it is ‘done’.
• Any value higher than 2 is cause for action by the Scrum Maste
• Following are some standard measures, grouped by focus area, to assess your agile-lean product development and performance.
• Story Acceptance Criteria
• Concurrent Testing
• Managing Software Debt
• Iterative Planning
• Learning & Adapting
• Possible Answers to Use as Metric
• Fundamental to the adoption of agile-lean product development is delivering value early and often to the business and customer. Business and customer value can be measured in many different ways, here are just a few:
• The focus on using a value based metric is around one very simple idea: the primary objective of a project and the product is to deliver value. The more value we deliver the more successful the project or product. Therefore, velocity, story points, throughput, cycle time, capacity, code quality, etc, are useful only if they help us discover more effective ways of delivering commercial or operational value to the business and customer.

17 more annotations...

• How high is your Cost of Quality? The answer might surprise you. Yes, it includes reviews, the QA infrastructure, and preparing tests, those are your "Appraisal Costs". But how high are your "Failure Costs" the cost of defects?

   

  Your engineers spend time in diagnosis and rework, development schedules slip, support costs climb, and your company's and products' reputations sink. These Failure Costs, which are the more significant Cost of Quality, are beyond your direct control. But you can gain control over them indirectly, by investing in Appraisal Costs that minimise Failure Costs, reducing your total Cost of Quality and making it more predictable.

• Not to be taken as meaning "bug-free," Zero-Defect Software Development (ZDSD) is a practice of developing  software that is maintained in the highest quality state throughout the entire development process. "Defects"  are aspects of the evolving software that would not be suitable for the final product as-is.
• The basic tenet of ZDSD is this: Maintain your product in what you believe to be a defect-free state throughout  the development process.
• 
    By focusing on product quality throughout the development lifecycle, you will actually complete products faster  than if you didn't pay attention to quality until the end of the project.
• Extensive studies done at NASA,  IBM, and elsewhere have shown that better QA leads to shorter schedules. An IBM study concluded that software projects  that make quality a top priority typically have the shortest schedules, the highest productivity, and even the  best sales.
• 1. Test your product every day as you develop it, and fix defects as soon as you find them.
• 
    2. Review your code regularly.
• 3. Rewrite poor-quality modules.
• 4. Assume full responsibility for every bug.
• 5. Handle change effectively.
• 6. Rewrite all prototyping code from scratch.
• 7. Set QA objectives at the beginning of every project.
• 8. Don't rush debugging work.
• 9. Treat the quality of your code at the same level of importance as the quality of your product.
• 10. Learn from every bug; each one represents a mistake that you made.

12 more annotations...

• One debate (if it can be called that) which has gone on for too long without a satisfactory resolution concerns programmer productivity and the often quoted “observation” or “fact” that the best programmers are 10 times better than the worst. I will come back to the origins of this observation, but it isn’t quite the topic of this article.
• widely circulated “fact” of the software profession, according to which “programmer productivity varies by a factor of 10 (or 5, or 20) between the best and worst individuals”
• first study to mention this wide spread in productivity dates back to 1968
• aiming initially to compare, under two experimental conditions, the performance of programmers facing… a debugging task.
• Surprising as it may seem, forty years after the initial results, the statement still comes accompanied with its modalities. Nearly every time I’ve had occasion to come across this statement, it was under the form ”numerous studies have shown that programmer productivity varies by a factor of 10 (or 5, or 20)” or some variation.
• The verdict seems clear: this supposed “scientific” observation on individual programmer productivity variations only deserves the name of folklore, unsubstantiated bits of opinion which are transmitted and kept alive for reasons more cultural than rational. I am most emphatically not claiming that there aren’t variations in productivity of that order: I am only saying that this “fact” has not been demonstrated, and that as of today we do not know what to make of it even if it were true.

4 more annotations...