Category Archives: Development

Resultaten mini enquete

Zilverline is vooral bekend van haar scrum trainingen en coaching. Zilverline doet echter meer en dit blijkt niet altijd iedereen te weten. Middels een mini enquete is hier inzicht in verkregen.

De enquete is nog steeds open en kost je maximaal 1 minuut. Klik op DEZE LINK om ook je input te geven.

Screen Shot 2016-07-13 at 16.18.35

Friday Playground

De foto geeft een deel van een toetsenbord weer, waarbij de originele ‘ESC’ toets is vervangen door een toets met het bedrijfslogo. Hoe? Heel simpel, met een 3d printer van Ultimaker. Vandaag was 3d printing een van de onderdelen van de Friday Playground. Graag neem ik je in dit artikel mee in de Friday Playground omdat ik persoonlijk van mening ben dat dit een uitstekende en zeer plezierige manier is van ‘een leven lang leren’.

Friday Playground 3D printing_1

Hoe werkt een Friday Playground?

Het idee is dat je als bedrijf 4 dagen voor klanten werkt en elke vrijdag is het playground. In de ochtend geeft een ieder aan waar hij/zij aan zou willen werken. Dit kan dus 3d printing zijn of bijvoorbeeld het ontdekken van nieuwe technieken zoals ‘js react’. Er worden teams gevormd die samen (pairen) aan de slag gaan, kennis delen en plezier hebben. Aan het einde van de dag om 16:45 uur starten de demo’s waarin het resultaat getoond wordt en de learnings. Uiteraard wordt er afgesloten met een borrel.

Wat zijn de voordelen

Voor de buitenwacht is niet altijd inzichtelijk wat het oplevert, sterker nog, vaak krijgen we de vraag:

dus jullie werken maar 4 dagen?

Het antwoord is NEE, ook de playground is werk. Het is werk wat zich indirect uitbetaald. Hieronder een drietal ‘geisoleerde’ voordelen:

  • Het is de perfecte opleiding. Omdat je in teams aan hetzelfde werkt is er  veel kennis uitwisseling. De een weet x, de ander y en weer een ander z. Vergelijk het met een quiz waarbij je mag kiezen om in het team ‘1 persoon’ te zitten of in het team ‘4 personen’.
  • Je leert heel goed samenwerken. Het is letterlijk vaak met 3 man achter 1 scherm en continue overleg en afstemming.
  • Het is vreselijk uitdagend en leuk om te doen.

Het lange termijn resultaat is dat je goede, slimme, samenwerkende en gelukkige collega’s hebt die zich continue ontwikkelen. En het is een mooie vorm van ‘duurzame bedrijfsvoering’: minder ziekte, minder personeelsverloop, hogere productiviteit, gelukkige collega’s en blije klanten.

Een leven lang leren

Dit is een term die veelvuldig voorbij komt en waar bijna iedereen het wel over eens is dat we dit willen/moeten doen. Feit is dat je na je studie nog ongeveer 50 jaar actief bent op de arbeidsmarkt. Laten we die tijd dan vooral op een nuttige en leuke manier invullen. De Friday Playground is in ieder geval een goed middel om hier aan bij te dragen.

Kom gerust een keer mee draaien!

Friday Playground 3D printing_2

Stakeholders niet op 1 lijn

Aan Mark Suurmond, een van de agile/scrum trainers bij Zilverline, vroegen we wat hem het meest opvalt bij klanten. In het kader van prioriteiten stellen mocht hij maar 1 item benoemen. Zijn duidelijke no. 1 is dat de stakeholders niet op 1 lijn zitten en dus het doel van het project niet duidelijk is.

“Onlangs stelde ik aan drie stakeholders dezelfde vraag: wat is het doel van het project? Hierop kreeg ik drie verschillende antwoorden. De een had het over het systeem stabieler maken, de ander over kostenbesparing en de derde had het over de kwaliteit verhogen. Dit werkt contraproductief. Is het doel niet eenduidig dan neemt het schuiven met  verantwoordelijkheden en beslissingen toe en zie je bijvoorbeeld het aantal meetings om ‘af te stemmen’ toenemen”. Als het doel helder is, is er een duidelijkere backlog en prioritering. Hiermee kan het team makkelijker zelfstandig beslissingen nemen en heeft het focus.

In de praktijk merk ik dat teams en ook stakeholders snel leren om duidelijk doelen en prioriteiten te stellen en het team steeds autonomer wordt. En in mijn ogen is dat uiteindelijk wat elk bedrijf zou moeten willen bereiken: zelfsturende en gelukkige teams. En vergeet vooral gelukkige teams niet. Een team van 20 man waar er na 2 jaar nog maar 4 van over zijn is een uiterst kostbare situatie en maakt je als bedrijf uiterst kwetsbaar.”

Wil je meer weten over agile/scrum training? Neem dan contact op met Mark Suurmond via msuurmond@zilverline.com of via 020 – 754 21 65

Simple event sourcing – users, authentication, authorization (part 6)

Previously we spend some time preparing the code to support multiple kinds of events and data, rather than just supporting blog posts. In this part we’ll add user accounts, together with the required authentication and authorization code. We’ll again use event sourcing and the memory image to keep track of all users and currently active sessions. But the biggest changes to the application are related to security, and authorization in particular. It turns out event sourcing allows for an additional layer of authorization which allows us to whitelist any change a particular user is allowed to make.
Continue reading Simple event sourcing – users, authentication, authorization (part 6)

How to use your happiness metric as a information radiator?

When I started recording the happiness of my team, I found it difficult to make this information transparent. I wanted to use it as a information radiator, so that everyone who looked at our Kanban or Scrum board could see (within 1 minute) how this particular team is doing, while on the other hand not all team members were confident enough to have their personal grade for all to see.
Continue reading How to use your happiness metric as a information radiator?

Flowmulator – A Kanban flow simulator

UPDATE: Now you can add workers to a column and see if it helps getting work done faster. Try experimenting with the numbers and get the best configuration!

While reading blogs about Agile games, I came across this link of Karl Scotland.
Because I always like combining programming with building something that gets across Agile principles (our Battleship game is also a good example) this seemed like a good new project for our Fridays at Zilverline HQ. Bob Forma and me started this and within a few days we came up with this (You can check the source code here)

Continue reading Flowmulator – A Kanban flow simulator

Simple event sourcing – refactoring and transactions (part 5)

In the previous part we added blog post comment functionality. In this part we’ll do some refactoring and change the memory image implementation to automatically retry domain logic on optimistic locking conflicts, giving us a simplified form of transactions. We’ll also change the event store to support multiple types of event streams in a single event store.

Continue reading Simple event sourcing – refactoring and transactions (part 5)

How to fill your happiness metric

Knowing how people think or feel about a certain subject can be very helpful in building trust, creating a team and to reveal impediments. Of course it can be very difficult to get team members to express their real opinions, especially when a team has just started. I think with patience and the right approach trust can (and will) be built and it will be easier to get real issues out in the open. The following practice can help you start this and make explicit what individual opinions in a team are.

I have used the following retrospective practice for several years now:

Continue reading How to fill your happiness metric

Simple Event Sourcing – conflict resolution (part 4)

After our deep dive into a Redis event store implementation we’re now getting back to actually adding functionality to the blogging application. Like the Getting started with Rails guide we’ll add the capability to add comments to blog posts. Adding this functionality is straightforward, but it will require us to look into resolving conflicts when multiple people make modifications to the same blog post or comment concurrently.

Continue reading Simple Event Sourcing – conflict resolution (part 4)

Simple event sourcing – Redis event store (part 3)

In the previous part we developed a fake event store for our blogging application. This event store just kept all events in-memory, making it unsuitable for production use. But it did allow us to adapt our application to using an event store, and let us work out the details of the event store interface without having to worry about an actual persistence mechanism.

In this part we’ll develop an event store implementation on top of Redis, a key-value store with support for additional data structures (such as lists and hashes), publish/subscribe, and transactions. If you’re more interested in adding new application functionality, you can safely skip this part and go to part 4 – conflict resolution.

Continue reading Simple event sourcing – Redis event store (part 3)