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?
Recently, I had the opportunity to interview William E. Perry, author of the book “iTeam: Putting the "I" Back into Team”. In the interview, William stressed how important it is to get people with the right skills into your team.
Wouldn’t it be nice if you could have more insight into the quality of a product, while it is developed, instead of afterwards? If you could measure the quality of your product, and take action when there is a risk that the quality would become lower than required by your customer?
Teams are more and more becoming the core of organizations. Whether project teams, agile teams or any other form of collaboration that is chosen in a company, the setting in which people collaborate is often teamwise. But establishing teams, and keeping them stable isn’t always that easy.
The old adagium “knowledge is power” has been replaced by a 2.0 version: “sharing knowledge is power”. I’m sharing my presentations, papers and all other things that I have published over the years with you, in my list of publications.
Communication is an important factor in improvement programs. Communication using visual management pictures the goals and approach. It motivates people to commit to change, by showing expected benefits and early results. But wrong or too much communication can also frustrate people, getting them to resist changing.
Software reviews and inspections significantly improve the quality of products, and provide major savings in cost and time. Sound logical, but where is the data to prove it? I’ve made an overview of data that has been published on the business benefits of reviews.