Using a deployment process that prevents code from being submitted that has an error follows a nearly identical process. It blocks the mistake from being made. I guess you can say that the connection doesn’t mistake proof the prevent me from trying to put it in the wrong way. But I think the general notion of mistake proofing is that the process blocks an error from being made. It seems to me a process that blocks code with a bug from being deployed with an error is the basically the same as a USB connection that will not accept the device being put in upside down.

I completely agree you want to focus on improving the process. The mistake-proofing that process both improves it (many poka-yoke solution make it easier to use) and prevents an error in case you still try something wrong. So I would see the automated tests as a way to serve as a backstop, in case the process improvement you made to the software development process failed in some form. Then the automated testing required to deploy would prevent the introduction of that error to the production environment.

Can I add to this discussion by posting what I wrote a friend in January of this year (in Dutch)?

Quote: Wat ik heb meegemaakt in e-mailcontacten met de twee uitvinders van scrum: Jeff is meer van: laten we doen wat werkt en Ken is: alles wat niet precies scrum/agile is, is per definitie ‘züm kotzen’. De laatste is echt recht in de leer…En in de praktijk zijn er even zo vele mensen die ‘recht in de leer’ zijn v.w.b. Prince2, SDM, XP, TWG, PP, Crystal, DSDM enz. enz. zijn. Het is zo exclusief.

Elke methode, denkwijze en werkwijze heeft zijn voor’s en tegen’s en zijn het meest toepasbaar op een bepaald gebied en in bepaalde organisaties. Scrum is, laten we eerlijk zijn, specifiek bedoeld voor het proces van ontwikkelen en bouwen van software. Maar veel van de mooie dingen van scrum zijn met enige lenigheid van geest ook toepasbaar op andere terreinen. Net zoals lean niet alleen toepasbaar is in de productie maar ook op –andere- logistieke processen en op software…..En dat geldt voor de andere methoden ook.

Ik zou nu zo graag de verbinding tussen de methoden, denkwijzen en werkwijzen willen vinden. En ‘interdisciplinair’ kijken; dat is een soort geïntegreerde vorm van multidisciplinair.

Om dit beeldend te maken: multidisciplinair vind ik er als een assenstelsel uitzien (daar staan de dingen naast elkaar / ieder vanuit het eigen paradigma daar krijg je 1+1= 1,5 effect) en interdisciplinair als een vendiagram (met overlappingen, daar krijg je dan het 1+1= 3 effect) Meer inclusief….Maak ik mijzelf nu helder? (en probeer dat maar eens fatsoenlijk te vertalen in ENG!)

Mensen die welke methode dan ook – vooral de jongens en meisjes die de werkelijkheid geheel reduceren tot een spreadsheet en niet wijzigbare planningen of IT jongens die alleen denken in termen van 1 soort scrumboard en burndown charts en deze vervolgens- heilig verklaren zijn in mijn idee sektarisch. Ik noem de eerste soort wel “spreadsheet fundamentalisten” en de tweede soort “sterk bijziend”

En er zijn ook mensen, vooral software ontwikkelaars, die denken dat werken in een scrumteam, vrijheid / blijheid is, die zijn heel erg op het verkeerde spoor. Vrijheid impliceert niet vrijblijvendheid maar discipline. Een scrum master moet met welhaast militaire precisie zijn mede teamleden, de omgeving en de voortgang in de gaten houden en heeft daarbij, afhankelijk van de omgeving waar gewerkt moet worden, meer handvatten nodig dan in scrum beschikbaar is. Maar goed, ik kan zo nog wel even doorgaan.

Waarom weet eigenlijk niemand dat we ook een Nederlandse methode van projectmanagement hebben? Dat zegt dat een project een begin en een eind heeft, kortlopend is, en een unieke aanleiding en resultaat heeft. Alles wat langer dan een jaar loopt behoort tot de normale lijnactiviteiten en alles wat korter is dan een paar weken is gewoon een klus. Er zijn geen voorschriften maar dingen om te overwegen. Verder zal ik er niet over uitweiden want ik wil er geen reclame voor maken. End quote.

Let’s get off of our own islands en make this world more Agile.

Applying additional management practices to Scrum may actually mature it more quickly, provided that the resulting effort fits the organization.

This post was mentioned on Twitter by Machiel Groeneveld: Published: Fitting Scrum to project organizations http://bit.ly/8gAO1b...

Anderszijds zie je een aantal externen nu eieren voor het geld kiezen en gaan deze in op een aanbod van de klant om in dienst te komen. Dit gevoel van veiligheid zal meer en meer ZZP-ers aan gaan spreken om zo te overwinteren in de slechte tijden. Zodra de economie weer aantrekt is het maar de vraag wie er dan opnieuw het lef heeft om het ZZP bestaan weer op te pakken

Ik denk dan ook dat je een soort conjunctuur zal zien die meeveert op de trend van de economie waarbij detacheerders & zzp-ers ziet meeveren met wat de markt voorschrijft. Dit resulteert in wat Machiel ook schetst hierboven: De vijver van externen krimpt bij recessie en zal met vertraging weer groeien naar het eerdere niveau.