Ik begrijp dat een scrum goed moet worden voorbereid. En ook dat er spelregels nodig zijn. En dat er enkele rollen nuttig zijn. Maar wat als het project niet echt projectmatig is? Ik zit er aan te denken om een soort van scrum-aanpak voor te stellen om bijvoorbeeld de nadelen van het nieuwe werken enigszins systematisch op te pakken. Of om periodiek na te gaan of de contacten met opdrachtgevers goed lopen. Of dat er voldoende ruimte en kwaliteit is om de hoofdtaken van een team goed te laten lopen en te zorgen voor minder storende bijkomende hectiek. Bij elkaar kan dat op een gegeven moment toch een soort "wijze van werken" worden. Maar welke spelregels zijn er dan basaal nodig dan wel onnodig?

SCRUM lijkt de laatste tijd steeds meer als een panacee ingezet te worden, terwijl afhankelijk van het soort project/werkzaamheden, grootte en samenstelling van de teams, soorten stakeholders, andere aanpakken mogelijk beter kunnen werken.

Alternatieven, zoals KANBAN, moeten altijd ook overwogen worden, bv bij kleine teams (minder overhead), bij teams die meerdere producten moeten servicen, bij onduidelijke research projecten (hoge mate van onzekerheden).

@ Vincent Vrooland
Dit artikel heeft naar mijn smaak te veel jargon voor mensen die niet al met scrum bezig zijn. Ik ben al 4 á 5 jaar bij scrum software-ontwikkelteams betrokken als tester/testcoördinator en deze lessen zijn we allemaal tegen gekomen.

Als je iets met Scrum wilt, zul je bij het begin moeten beginnen:
Het Agile manifest
(http://www.agilealliance.org/the-alliance/the-agile-manifesto/):
------
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

en de 12 principes ook op deze site te vinden
------

Dit gaat meer over attitude dan over methode. Als je met Scrum wilt gaan werken is het goed om tot je te laten doordringen wat Agile werken inhoudt voor je medewerkers en voor jezelf. En of Agile iets bij je oproept in de zin van: daar wil ik met mijn team naartoe.
Scrum is een methode om Agile werken beter te structureren, maar die attitude is in essentie belangrijker.

Dan je specifieke vragen.

1 het project is niet echt projectmatig.
Als met projectmatig bedoeld wordt: een planning en control aanpak zoals bv met Prince2, dan is het antwoord op deze vraag: dan zou Agile/Scrum een goede werkwijze kunnen zijn.

2 nadelen van het nieuwe werken systematisch te pakken
het nieuwe werken kan alles betekenen. Agile/Scrum is zelf zo'n vorm van het nieuwe werken.
Als je met het nieuwe werken bedoelt dat mensen niet meer op kantoorlokatie werken maar 'willekeurig' waar, dan is dat een probleem, omdat bij Scrum er van uitgegaan wordt dat de teamleden dicht bij elkaar zitten. Geen wet van Meden en Perzen: een stand-up kun je b.v. ook dagelijks via Skype wereldwijd organiseren.

3 periodiek nagaan of de contacten met opdrachtgevers goed lopen.
Contact met opdrachtgever/klant is essentieel in de Agile/Scrum methode: Opdrachtgever is een direct betrokkene en wordt meestal uitgenodigd bij de Demo aan het eind van elke sprint.

4 ruimte en kwaliteit om de hoofdtaken van een team goed te laten lopen.
Dit bepaalt het team zelf aan de hand van de keuze van op te lossen items uit de project backlog en die items in de sprint af te werken. Per sprint wordt dus telkens een nieuwe prioritering aangebracht in wat een team belangrijk vindt en in het tijdsbestek van de sprint ook daadwerkelijk kan oplossen.
Continue kwaliteit is 1 van de Agile basiselementen.

5 Soort van werkwijze en spelregels.
Met Agile/Scrum heb je niet een methode die van a tot z vast ligt en zo uitgevoerd moet worden als voorgeschreven. Je kunt beginnen met enkele eenvoudige punten op te pakken.
Begin eerst je er in te verdiepen door een paar boekjes te lezen of een basiscursus te doen. Dan krijg je al meer zicht op het waarom en het hoe.
En durf ruimte te bieden aan het experiment, zodat het team zelf kan bepalen hoe ver en hoe hard het gaat in het omarmen van de methode.

Tot slot: zit je in een strakke Angelsaksische organisatie, dan zou ik het met Scrum werken in eerste instantie tot een klein team en een klein domein beperken. Slaagt het dan kun je dat direct laten zien en je teamleden als ambassadeurs inzetten voor verdere uitrol van Scrum.

@Vincent, scrum is goed toepasbaar als je vooraf in staat bent een DOD te formuleren (definition of done ... wat is er klaar als het klaar is). Dit kan in projecten, maar ook in beleidsontwikkeling is scrum als instrument zeer bruikbaar, zo heb ik ervaren. Voor meer evaluatieve vragen (zoals jouw onderwerpen) zou ik een review-achtige aanpak kiezen.

Otto, Henk en Rob: grote dank.
De zaak zit zo:
1 - uit enige onvrede met de bestaande medewerkersonderzoeken heb ik een alternatief gemaakt en ingezet. Gevraagd naar de relatie tussen hun ambities en hun werkelijkheid geven medewerkers redelijk massaal aan dat ze meer zouden kunnen en willen presteren voor hun klanten/opdrachtgevers. Mooi. Maar sommige condities en onvoldoende "gehoord worden" zorgen voor minder energie en innovatief vermogen.
2 - Daarnaast hebben leidinggevenden vaak geen behoefte aan "extra projecten": ze hebben hun handen al vol. En over de condities en de organisatie van het werk hebben ze soms een andere visie dan de medewerkers. Dat is een beetje jammer, want uit mijn metingen blijkt dat prestatie en energie een stuk omhoog schieten als er sprake is van "attent leiderschap". Daarmee bedoel ik: doelgerichtheid in combinatie met aandacht voor de ideeën en problemen van hun medewerkers.
3 - Dienend of faciliterend leiderschap zie ik zelf niet zo zitten. Leidinggevenden hebben ook zelf doelstellingen en ambities.
De vraag is dan: hoe krijg ik de rol van leidinggevenden (beweging, richting en focus) samen met het potentieel "goed werknemerschap" van de medewerkers. En dan niet als project maar als miniprojectjes of zelfs als "werkwijze". En dan denk ik aan scrum. Het voordeel lijkt me zowel de klantgerichte verbetering als de face-to-face-werkwijze als het opdelen van grotere doelen in kleine stapjes en de bijeenkomst op de werkvloer zelf.
Een eenvoudig maar actueel voorbeeld is: beter omgaan en meer resultaat krijgen bij de digitalisering van loketten bij een infobalie (en dan bedoel ik even niet het ICT-gedeelte, al kan dat later ook). Er is dan denk ik inderdaad een DOD nodig (al zal die gaande weg veranderen) en een opbrengstverwachting. En iemand moet de spelregels toepassen en zorgen dat de ideeën opgedeeld en gericht worden op behapbare brokjes. Maar wat mis ik als ik denk dat dat voldoende is?
En kan zoiets niet - op den duur - dagelijks: wat gaat iedereen doen en welke hulp of ideetjes van anderen zijn dan behulpzaam? Of wekelijks: welke positieve of negatieve klantervaringen waren er, wat kan beter in het werk? Hoe pakken we dat op?
Of raak ik dan te ver van de scrum af?

Scrum begint met......open stellen voor een totaal andere aanpak van een project en met een andere kijk op proces en samenwerking. Verdiep je er eens in, lees een paar artikel en volg een introductieworkshop (kan ook in company rond een concreet, eigen project). Zie Bascommunicatie.com/scrum voor meer informatie!

To SCRUM or not to SCRUM: zul je per team, per soort werkzaamheden moeten afwegen.

Een info balie afdeling lijkt mij een situatie waarin snel actie moet worden ondernomen. De waan van de dag regeert, maar je wilt niet dat er dingen verloren gaan of over het hoofd gezien wordt. Korte schakel momenten en kennisdeling zijn dan relevant. Ik hoop dat ik hiermee de schets goed gemaakt heb.

SCRUM heeft een fixeer moment voor werkvoorraad voor het team voor een termijn van 2-4 weken (de sprintbacklog). Komen er nieuwe taken dan moeten die periode minimaal wachten. Tussentijds bijsturen van de inhoud van de sprintbacklog mag niet (heel incidenteel!). Lijkt mij niet van toepassing in deze situatie, maar er zouden andere redenen kunnen zijn om dit alsnog in te voeren, bv juist om het team RUST te geven en de waan van de dag dus buiten de deur te houden.

Waar mensen vooral van houden binnen SCRUM is het overzicht op de werkvoorraad (het bord) en continue evaluatie hoe het gaat, waar we staan etc (de daily scrum) en andere evaluatie methodes.

Praktijk voorbeeld: Ik zit op dit moment in een team dat beheer pleegt (Adhoc requests) en ook deels R&D (ook niet planbaar). We moeten, helaas, dagelijks kunnen reageren op support vragen. etc.
SCRUM is bij ons niet zinvol, helaas. Aan het einde van de sprint kom je iedere keer weer tot de conclusie dat je je doel niet gehaald hebt, want je hebt je tijd onverwachts meer aan beheer taken moeten besteden. Dat vindt Management niet erg, maar is voor het team erg frustrerend, zeker als er zoveel moeite gestoken is in het formuleren van een doelstelling etc.

We zijn dan ook overgestapt van SCRUM naar KANBAN, aangevuld met een aspecten van SCRUM die ons goed bevallen waren: dagelijkse evaluatie, retrospective, DOD etc. We bewaken onze werkvoorraad is en blijft een issue.

Welke methode jullie gaan gebruiken, je moet altijd open blijven staan voor verbetering. Blijf Agile, niet alleen op de inhoud van het werk, maar ook hoe je met het werk omgaat.

Overweeg idd om een (externe) ervaringsdeskundige (tijdelijk) in te zetten om de verandering door te voeren.

Van A naar B.
Ik blijf het verbazingwekkend vinden dat wij mensen zoveel tijd besteden aan het formuleren van een methode om simpelweg van A naar B te gaan. Boekenvol worden er over geschreven.
Tijdens een cursus projectmanagement hebben we de gehele morgen oeverloos gediscusseerd over alle andere vormen van management.
Nu schrijven we over SCRUM, KANBAN, AGILE,etc.. Om te leren hebben we boeken, instructeurs. Hoeveel geld geven we met zijn allen uit om simpelweg van A naar B te gaan.

Probeer alles nuchter te bekijken. En van alle reacties ben ik meer begaan met Otto zijn verhaal. Tussen de regels door lees je de praktijk. Zwoegen om een doel te bereiken. Dat spreekt mij aan. Dat zouden meer mensen moeten doen.

Waar of voor wie je ook werkt het gaat altijd om het verdienmodel. Maar wij mensen, stuk voor stuk zijn heel druk bezig met "IK". Positie, geld, status, etc.
Natuurlijk zijn er uitzonderingen.

Als je voor de overheid werkt dan is je bestaansrecht qua werk redelijk geborgd. Bij grotere multinationals wordt het al wat spannender.
Maar voor een klein bedrijf, 5 werknemers, is het elk uurtje factuurtje. En kost het moeite om boven het maaiveld te blijven. Zij gebruiken een planbord zodat je dagelijks kunt zien waar je staat. En natuurlijk is overleg belangrijk. Vastleggen en registreren ook.
Maar dat leer je op school/avonduren en dan pas je het toe in de praktijk.

Waar wil ik naar toe. Wees eerlijk kijk in de spiegel een ieder van ons heeft de luxe om over deze onderwerpen te filosoferen. Maar denk ook af en toe aan de wereld om ons heen en wees dankbaar voor je positie. Probeer nuchter te blijven.
Kostenbeheersing voor het bedrijf, overheid, instelling etc
Streef naar een betere wereld maar begin bij jezelf.

Dankuwel. Heb uw artikel als update toegevoegd onderaan http://flande.rs/jp ;-) Wij spellen het wel gewoon "scrum" want het is geen eigennaam of letterwoord.

(Het valt me overigens op hoe weinig mensen die reageren hun profiel hebben aangepast zodat je weet in welke organisatie ze werken. Misschien iets om te promoten, o Managementsite?)