Open Space: Agile en ICT Beleid
Als lid van het kernteam werk ik mee aan Agile Overheid. Op maandag 26 september organiseren we, samen met de DICTU, een Open Space in Den Haag over het thema Agile en ICT Beleid Meld je aan via Agile Overheid.
Als lid van het kernteam werk ik mee aan Agile Overheid. Op maandag 26 september organiseren we, samen met de DICTU, een Open Space in Den Haag over het thema Agile en ICT Beleid Meld je aan via Agile Overheid.
Na een evaluatie of audit weten we wat onze zwakke punten zijn. "Die moeten we gaan veranderen" is de aanpak die dan vaak gevolgd wordt. Herkenbaar voor velen, maar we zien ook dat het niet altijd werkt. Kan dat niet anders? Ja, door te veranderen vanuit je sterktes. Een techniek die daarbij helpt is "Oplossingsgericht Werken".
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.
Zoals al eerder beschreven (op www.veranderproject,nl) is een veranderproject wezenlijk anders dan een "gewoon" project. Het is een "zacht" project, waar het doel niet het opleveren van producten is maar dat mensen ander werk doen of hetzelfde werk anders doen. Zo'n project wordt op een andere manier uitgevoerd dan een "gewoon" project, en dat vereist ook specifieke vaardigheden bij de projectleider. Laten we eens een eerste vaardigheid eruit lichten: Communicatie.
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?
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.
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.
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.
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.
The quality of software is often still insufficient. Pair programming is a proven technique that prevents defects from entering the code.