Schneider’s Organisatie cultuur Model

Schneiders Cultuur Model

The Reengineering Alternative: A plan for making your current culture work -- William E. Scheider (2000)

The Reengineering Alternative A plan for making your current culture work — William E. Scheider (2000)

Schneiders Cultuur Model

Definitie van een cultuur: “de manier waarop we werken om succesvol te zijn”

Essentieel zijn er 4 basis organisatie culturen:

  1. Controle: “We zijn succesvol door het krijgen en behouden van controle”
  2. Competentie: “We zijn succesvol door de beste te zijn” (expertise)
  3. Cultivatie: “We zijn succesvol door mensen die onze visie uitvoeren”
  4. Samenwerking: “We zijn succesvol door samen te werken”

Over 2 assen

  • X as: mensen georiënteerd –> tot –> organisatie georiënteerd
  • Y as: mogelijkheden georiënteerd –> tot –> realiteit georiënteerd
Schneider Culture Model

Schneider Culture Model – http://agilitrix.com/wp-content/uploads/2011/03/Schneider-Culture-Model.jpg

  • Elke cultuur heeft zijn typische kenmerken, elke cultuur heeft zijn sterke en zwakke punten.
  • Er zijn geen goede of slechte culturen – elke organisatie heeft een bepaalde basis cultuur.
  • De basis cultuur kan verschillen per niveau: de organisatie, een departement, een team.
  • Om een organisatie cultuur te veranderen, moet men eerste de bestaande cultuur ten gronde begrijpen en vanuit die cultuur de veranderingen initiëren.
  • Forceer geen nieuwe cultuur.
  • Culturen die zich naast mekaar (in horizontale of verticale richtingen) positioneren zijn meer compatibel voor een overgang.
  • Vraag een groep mensen om hun cultuur te bepalen op basis van een vragenlijst. Vraag zowel interne als externe mensen hun oordeel over de cultuur. Bij externen vraag zowel naar hun eigen cultuur als de cultuur bij de klant / het project. Informeer naar de opinie over de sterken en zwakten van een bepaalde cultuur.

Hulpmiddelen:

In Scrum zijn er geen business analisten!

In Scrum zijn er geen business analisten!

Hmm. Toch wel.

In Scrum bestaat de “rol” business analist niet, en  ook geen andere typische IT project rollen zoals functioneel analist, technisch analist, architect, systeembeheerder, project manager, …

Het Scrum framework definieert 3 rollen:

  • Product eigenaar
  • Ontwikkelaars (het team)
  • Scrum master

Het “ontwikkel” team omvat alle individuen met alle vaardigheden en expertises om het product te “ontwikkelen”. In feite kunnen we dit ook het “product” team heten, de term “ontwikkelaar” neigt teveel om enkel (software) ontwikkelaars aan te spreken.

Het team oefent dus alle vaardigheden en expertises uit om tot een succesvolle ontwikkeling van het product te komen. Het team is in principe cross-functioneel en een teamlid hoeft zich niet te beperken tot een bepaalde rol of activiteit. Volgens de nood en planning kan elk teamlid een bepaalde activiteit uitoefenen… analyse, design, ontwikkeling, testing, planning, project administratie, … . We moedigen dit aan in een cross-functioneel team zodat teamleden van elkaar kunnen leren en kennis gedeeld / verrijkt wordt.

“Business analyse” omvat uiteraard meerdere vaardigheden en een analist is actief op vele terreinen: marketing & communicatie, business, functioneel, technisch, … . De business analist heeft typisch vaardigheden om de vertaalslag te maken tussen marketing en technische mensen.

Agile en analyse?

Als “business analist” vervullen we de facto meerdere taken. Een agile analist zou men kunnen omschrijven als:

Een agile analist combineert business, functionele, techische analyse en acceptatie testen. De agile analist streeft naar transparantie in communicatie en het gehele project, werkt in korte iteraties en is continue op zoek naar feedback. De agile analist creëert samen met de product eigenaar en de andere teamleden een visie en bouwt mee aan het product, iteratie na iteratie.

Bron: volledig artikel (scrumalliance.org)

Incrementele Persona’s

Incrementele Persona’s

[Definitie Wikipedia]

Een persona is een archetype van een gebruiker, ofwel een karakterisering van een bepaald type van gebruiker. Persona’s worden veel gebruikt bij het gebruiksvriendelijk maken van IT-oplossingen, en dan met name van de gebruikersinterface ervan.

[Oorsprong]

Alan Cooper, was de eerste die er over sprak in zijn boek The Inmates are Running the Asylum. In dat boek werd onder meer besproken hoe persona’s kunnen worden aangemaakt, gebruikt en toegepast.

[Inhoud van een user persona]

Inhoudelijk beschrijven we een persona met volgende gegevens:

  • Naam (en een gezicht, foto)
  • Demografie (bv. geslacht, leeftijd, relatie, gezinssituatie, locatie, financiële situatie)
  • Gedrag
  • Noden en doelstellingen

Voorbeeld van een uitgebreide user persona layout

User persona – 10 elementen http://www.ux-lady.com

[Set & forget persona]

Een “set & forget” persona is een persona die men aan het begin van het project of onderzoek definieert, maar daarna nooit meer actualiseert. Het gebeurt dat men veel effort (tijd en geld) spendeert aan het onderzoeken, analyseren en definiëren van verschillende persona’s, maar dat dit slechts éénmalig is. Het probleem hierin is dat de persona’s ook groeien naarmate het project (en het product) evolueert. Een set & forget persona wordt gedefinieerd, maar daarna niet effectief toegepast tijdens de ontwikkeling van het product om te testen of het voldoet aan de noden van de persona’s.

[Incrementele persona’s]

  1. Definieer een basis voor een persona (een interessante techniek hierbij is een empathie map)
  2. Verfijn de persona inhoudelijk naarmate het project vordert en we meer inzicht verkrijgen in noden
  3. Heraligneer zodat alle project participanten hetzelfde begrip hebben

Thanks to Adrian Howard for his talk regarding incremental personas at Lean UX