Business Reason for Root Cause Analysis
What is your most important Business Reason to do Root Cause Analysis for software development / maintenance? Please vote at http://linkd.in/nJchM8.
What is your most important Business Reason to do Root Cause Analysis for software development / maintenance? Please vote at http://linkd.in/nJchM8.
Het Nederlandse Netwerk voor Software Process Improvement "SPIder" organiseert op 28 september a.s een plenaire sessie over Lean software ontwikkeling. Sprekers zijn Olav Maassen en Mary Poppendieck.
In organization that are migrating to Agile, the question often come up what the role of project managers will be? Are they still needed? Yes they are, but their day to day work will change.
The serie on “What Drives Quality” has thusfar described technical activities that are part of software development. Next postings will cover supporting activities; this one describes how senior management drives quality. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
How do you collaboratively develop software when you have people working at different sites, countries or even continents? How do you get distributed teams to communicate effectively, and deliver working software in a agile way? The second book from Jutta Eckstein can help you to implement agile software development in a multisite environment. Below the book review that I wrote for Software Quality Professional, June 2011, published by the American Society for Quality.
The serie on “What Drives Quality” continues. Previously covering Requirements Quality, Architecture and Design Quality and Coding Quality, this post covers Testing. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
Agile retrospectives are a great way to continuously improve your way of working. Getting actions out of a retrospective that are doable, and getting them done helps teams to learn and improve. An overview of things that you can use to get value out of your retrospectives.
The 5th posting on on “What Drives Quality” covers review and inspection. Previously covering Requirements Quality, Architecture and Design Quality, and Coding Quality. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
This is already the 4th posting on “What Drives Quality”, focusing on coding. Previous posting covered the factors that drive requirements quality and that drive architecture and design quality. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
This third posting on “What Drives Quality” investigates factors that drive the quality of the architecture and design. A previous posting covered the factors that drive requirements quality. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
This second posting on "What Drives Quality" investigates factors that drive the quality of requirements. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
Many methods for product quality improvement start by investigating the problems, and then working their way back to the point where the problem started. For instance audits and Root Cause Analysis work this way. But what if you could prevent problems from happening, by building an understanding what drives quality, thus enabling to take action before problems actually occur?