Op maandag 11 juli organiseerde AgileOverheid een open space, over het onderwerp "Agile en Kwaliteit". Dat je met agile in staat bent om kwaliteitssoftware te leveren is (voor mij) al bewezen. Maar hoe maak je dat zichtbaar voor de stakeholders van een agile project?
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.
Eindelijk is het dan zover. Na allerlei onderzoeken en rapporten, lobbyen, en vele vergaderingen is er een beslissing genomen dat we gaan veranderen. Er is steun en draagvlak in de organisatie voor de verandering, er is budget en er zijn mensen vrijgemaakt voor een veranderproject. Goed nieuws! Maar hoe pak je dat nu aan?
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.
Agile en Kwaliteit, twee van mijn favoriete onderwerpen gecombineerd in 1 event: Een open space op 11 juli, georganiseerd door Agile Overheid. Ik ben erbij!
Het spreekwoord "voorkomen is beter dan genezen" geld ook voor software. Veel software fouten zijn niet nodig; veel problemen kunnen voorkomen worden. Een techniek die helpt om te leren van fouten, en ze te voorkomen, is Root Cause Analysis.
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.
"Verandering is de enige constante." "Onze organisatie verandert continu, maar lost dat alle problemen op?" "Er lopen zoveel veranderingen, ik mis het overzicht!" Herken je deze uitspraken? Dan weet je vast hoe belangrijk verandering binnen de organisatie is, maar ook hoe moeilijk het is om veranderingen te managen.
Procesverbetering wordt vaak toegepast om problemen in een organisatie structureel aan te pakken en blijvend op te lossen. Ik heb succesvolle (proces)verbetertrajecten begeleid, maar ook trajecten gezien waar door de verbeteraanpak de problemen initieel juist groter werden. Door alert te zijn op de signalen, en tijdig actie te ondernemen werd het verbetertraject daarna alsnog succesvol.
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?
Als je blogt over “Sharing knowledge is power”, dan kun je vragen verwachten over hoe je kennis nog meer kunt delen. Gelukkig hoeft het allemaal niet zo ingewikkeld te zijn. Het gaat bijna vanzelf, mits je het wat organiseert, stimuleert, en waardeert.