• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
www.eenblogjeom.nl
Goed ontwerp(en) volgens Dieter Rams
Gepubliceerd in Citaten: omdenken
E-mail Afdrukken

citaat

You cannot understand good design if you do not understand people; design is made for people.

Dieter Rams

Laatst aangepast op vrijdag, 16 juli 2021 08:39  
Michel Lamie over veranderkracht als kerncompententie
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

veranderen delta

Michel Lamie, Ceo De Goudse, spreekt in een artikel in Management Team veel wijze woorden over (nieuw) leiderschap, maar de onderstaande citaten over de rol van een leider bij verandering (lees: het organiseren van 'veranderkracht') sprongen er voor mij persoonlijk uit:

"We willen de beste zijn, wat betekent dat we dicht tegen de klant aan moeten kruipen. Klantcontact wordt doorslaggevend. Dat vraagt intern zowel een cultuur- als een gedragsverandering, die alleen met een nieuwe vorm van aansturen en bijbehorend ­leiderschap is te realiseren. Hoe moeilijk dat ook is. Er bestaat geen blauwdruk voor. (...) Van bovenaf kun je slechts de urgentie creëren, de richting ­aangeven. Het moet decentraal echt gebeuren. Hoe wordt een individuele klant benaderd? Dat moet ontstaan in de teams zelf. Het gaat om het ontwikkelen van zelfcorrigerend vermogen, van voorbeeldgedrag, van kruisbestuiving binnen de teams. Ik stel vooral vragen: hoe vind jij dat het zou moeten zijn? Dat is mijn rol als leider: vragen stellen, het proces ­aanjagen, tempo ­maken en soms ook onrust brengen als er onvoldoende beweging is. Blijven agenderen. Het ­wortelt in mijn overtuiging dat ­veranderkracht een kerncompetentie van de organisatie moet zijn.”

(...)

“We hebben bijvoorbeeld een tijdje geleden De Goudse-­ondernemersprijs in het leven geroepen. Die prijs, een paarse appel en een teamuitje, reiken we elk kwartaal uit aan het team dat het meest ­innovatieve idee heeft om ons bedrijf, of hun ­onderdeel, beter aan te laten sluiten op de wensen van de klant. Ik heb dat idee gekopieerd van een ander bedrijf en alleen de kleur van de ­appel veranderd. Maar wat een dynamiek zo’n ­relatief simpel ­initiatief veroorzaakt! De laatste keer waren 9 ­initiatieven genomineerd. Dat zijn dus 9 best practices waarover ik kan praten op onze ­kwartaalbijeenkomsten. Voorbeeldgedrag dat ik kan huldigen. De jury bestaat uit champions van de afdelingen. Zij beoordelen elk idee: is het vernieuwend? Is het ­ondernemend? De ­competitie leeft. En het levert echt concrete ­projecten op. Mede naar aanleiding van de ­callcenteractie van Youp van ’t Hek en een ­YouTubefilmpje over Mobistar heeft het team met het meeste klantcontact ­bijvoorbeeld alle ­momenten geïnventariseerd waar het fout kan gaan. En nu is er dus een ­database van best practices om zulke ­fouten te voorkomen. ­Ander voorbeeld: het schadeteam dat ­gericht probeert de klant te ­leren kennen vóór er schade is. Of nieuwe klantenquêtes, die door ­afdelingen zelf worden ­geïnitieerd. ­Ondernemersinitiatieven als deze worden ­behapbaar in kleine eenheden. Dan kun je ­mensen ook de ­vrijheid geven ­risico’s te nemen, zonder dat ­eventuele missers de gehele ­organisatie belasten. ­Decentraliseren is een manier om die ­vrijheid en dynamiek te vergroten.”

(...)

“Een goed geleide organisatie met veel aanpassingsvermogen en de ruimte voor initiatief kan niet zonder goede controls. Dat is een randvoorwaarde. Maar deze processen zijn niet volledig te vangen in businessplannen, managementrapportages of score cards. De transitie is ook zichtbaar in mijn eigen kernteam. Steeds vaker bespreken we individuele dossiers. Zo krijgen we een beter gevoel voor waar verbeteringen mogelijk zijn. Daarbij kom je ook allerlei dilemma’s tegen. Neem een brand in een leegstaand bedrijfspand. Die had gemeld moeten worden en ­extra preventie was nodig, ook volgens de polisvoorwaarden. De brand is echt, de schade is echt, maar de polis is ook echt. En de verzekering is ook echt bedoeld om de schade af te dekken. Hoe ga je daar dan mee om? Dan betreed je een grijs gebied. Als ­leider is het belangrijk de business ook op dossierniveau te ­kunnen doorgronden, als we onze klant­tevredenheid zo hoog willen krijgen en houden.”

Bron: http://www.mt.nl/157/28964/magazine/michel-lamie-ik-kan-slechts-urgentie-creeren.html

Laatst aangepast op zaterdag, 22 januari 2022 20:38  
Tijdelijk succesloos
Gepubliceerd in Citaten: constructief falen
E-mail Afdrukken

 citaat

Failure doesn't mean you are a failure... it just means you haven't succeeded yet.

Robert Schuller

Laatst aangepast op dinsdag, 15 november 2011 20:05  
Sterke verhalen: user stories als requirementstechniek
Gepubliceerd in Requirements
E-mail Afdrukken

user stories

Binnen de agile softwareontwikkeling vormen de zgn. user stories de aanbevolen requirementstechniek. User stories staan voor requirements verteld vanuit het gezichtspunt van de gebruikers. Belangrijk hierbij is dat de veranderbehoefte wordt weergegeven in de taal van taal van de business.

Volgens Nicode de Swart voldoen user stories bij voorkeur aan de syntax: "Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>" en geeft hierbij als voorbeeld: "Als student wil ik mijn cijfers online bekijken zodat ik sneller weet of ik het examen heb gehaald." Het gaat hierbij alleen om de korte omschrijving ter aanduiding van de user story. Het is niet de bedoeling om volledige functionaliteit al tot in detail te beschrijven. Hiervoor is een ander onderdeel de user stories bedoeld: mondelinge communicatie. 'Mondeling' omdat het veel effectiever is om detailinformatie mondeling over te dragen.

Zodra de ontwikkelaar een user story gaat implementeren is detailinformatie nodig over de gewenste werking van de user stories. De korte omschrijving is té globaal, zodat het ontwikkelteam de gebruiker (product owner) vragen moet gaan stellen. De antwoorden op de vragen worden - voor zover nodig voor de correcte werking van de te realiseren software - vastgelegd als acceptatiecriteria. Door de samenwerking tussen het ontwikkelteam en de product owner is dus ook geen analist nodig als brugfunctie tussen business en ICT.

Deze acceptatiecriteria vormen het derde onderdeel van user stories. De acceptatiecriteria hoeven - omdat er intensief wordt samengewerkt bij het implementeren van de user stories - niet volledig te zijn. De kracht van het werken met user stories is volgens De Swart dan ook dat het detailleren van requirements, het ontwikkelen van de software en het testen ervan hand in hand gaan: "De ontwikkelaar laat regelmatig aan de product owner zien wat hij gebouwd heeft. De product owner geeft feedback en samen bespreken ze wat er nog toegevoegd of gewijzigd moet worden. Aangezien een user stories in enkele dagen tot ruim een week tijd gerealiseerd wordt, is het niet nodig om naast de mondelinge afstemming nog veel te documenteren."

Onderdelen user story

  1. Korte beschrijving als aanduiding van de requirement (ivm planning)

  2. Mondelinge communicatie om de details te achterhalen (tijdens de realisatie)

  3. Acceptatiecriteria om juiste werking vast te stellen

De kracht van user stories zit in het feit dat door de intensieve samenwerking tussen het ontwikkelteam en de product owner en de nadruk op mondelinge communicatie drie voordelen optreden:

  1. Eenvoud:"Het is niet nodig (en niet wenselijk) om vooraf de gedetailleerde requirements te achterhalen en te beschrijven. Dat is maar goed ook want het is onmogelijk om de requirements (in use cases) voor 100% volledig en eenduidig te specificeren".

  2. Flexibiliteit: user stories kunnen beter omgaan met voortschrijdend inzicht: "Tot aan de start van de iteratie/sprint waarin de user story geïmplementeerd wordt, heeft voortschrijdend inzicht geen negatief effect op het project".

  3. Snelheid: een user story moet in maximaal 10 werkdagen geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, moeten worden opgesplitst. Kom daar maar eens om, bij een volledige use case. Het is niet langer een analist gedetailleerd requirements te laten specificeren. Verder gaat ook geen tijd verloren aan het lezen en begrijpen van gedetailleerde requirements door de ontwikkelaars en testers en is het - omdat detaillering van requirements later en mondeling plaatsvindt - niet nodig om wijzigingen door te voeren in de specificaties.

Bron: Nicole de Swart op http://www.reaco.nl/kenniscentrum/userStories.asp

Laatst aangepast op dinsdag, 02 januari 2018 08:29  
Wijze weerstand
Gepubliceerd in Citaten
E-mail Afdrukken

citaat

Wijsheid stroomt in organisaties van boven naar beneden en als wijsheid van beneden naar boven stroomt heet het weerstand.

Bart Stofberg

Laatst aangepast op donderdag, 20 oktober 2011 19:44  


JPAGE_CURRENT_OF_TOTAL

People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy. (…) Pretty simple to describe in theory. Some subtlety in practice. A kanban is a tool, and like any tool, it is meant to solve a problem. I think kanban solves this problem more efficiently than the known alternatives.

Corey Ladas

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 162 gasten online
Artikelen

constancy purpose benjamin disraeli secret success geheim succes doelen

Banner
Banner

isd instructional design chuck hodell

ISD From The Ground Up
A No-Nonsense Approach to Instructional Design
Chuck Hodell

Bij Bol.com

Lean boekentips

Banner