Vrijwel elk software team probeert tegenwoordig “Agile” te zijn, en houdt dus een dagelijkse meeting waarin de teamleden verantwoording afleggen voor hun daden. De werkelijk Agile teams zullen zich hierin niet herkennen, maar in veel gevallen is het niet meer dan een rondje verantwoording afleggen dat iedereen ook de afgelopen dag weer heel druk bezig […]
In de loop van de geschiedenis is de software waaraan we werken steeds groter en complexer geworden. Hierdoor is het voor stervelingen al lang niet meer mogelijk om de gevolgen van elke wijziging te overzien. Al snel groeien daardoor de implicaties van wijzigingen onze menselijke capaciteiten boven de pet, en wordt een geplande kleine aanpassing
(En waarom maar weinig teams zich dat beseffen.) De ware revolutie van de Agile manier van werken is dat de focus is verschoven van “werken vanuit een plan” naar het “leveren van werkende software aan gebruikers”. Het gaat er dus niet meer om dat er deadlines worden gehaald voor het management, maar dat het geïnvesteerde
Het blijft een pijnlijke constatering dat de transitie van een “waterval” manier van werken naar Agile manieren al ruim 20 jaar duurt, en nog steeds niet afgerond is. Het gevolg hiervan is dat er een nog steeds groeiend leger project managers naar betekenis zoekt, en dus een cursus volgt om zich tot Scrum Master om
Tot op de dag van vandaag zijn er nog altijd discussies over de zin en onzin van Agile manieren van werken in de software industrie, en blijven managers aanhalen dan “volgens Internet” Agile helemaal niet werkt. In plaats daarvan kiest men liever voor de gestructureerde controleerbaarheid en hiërarchische autoriteit van het vertrouwde “waterval” proces.
Sinds lange tijd ben ik gefascineerd door burn-down charts. Ze leveren een prachtig instrument om toch te ontdekken wat we eigenlijk niet willen weten. Het ideaal is een rechte lijn van de start tot de deadline, maar helaas is dat nooit wat er echt gebeurt.
Het (laten) maken van software is een kostbare activiteit, waarbij je zeker wilt stellen dat de waarde van het resultaat opweegt tegen de investering die ermee gemoeid is.
Voor opdrachtgevers van softwareontwikkeling is al vele jaren de grootste zorg of het doel wel op tijd (en dus binnen budget) bereikt zal worden. In een poging deze onzekerheid te bestrijden wordt telkens weer om gedetailleerde plannen gevraagd. Hoe begrijpelijk dit ook klinkt in de context van budgetbeheersing, is het helaas geen reële oplossing.
PK2 legt zich toe op het verbeteren van mentaal welzijn en talentontwikkeling. Op basis van deze ervaring was een idee ontstaan hoe het “welzijn” van mensen wellicht objectief gemeten zou kunnen worden. Dit idee leidde tot een spreadsheet met een vragenlijst en een idee voor een rekenmethode.
