Het Vakgebied

Het Vakgebied (8)

Constant Pace

Agile processes promote sustainable development. 
The sponsors, developers, and users should be able 
to maintain a constant pace indefinitely.

At regular intervals, the team reflects on how 
to become more effective, then tunes and adjusts 
its behavior accordingly.

These are two principles of the Agile Manifesto. In this blogpost, I’ll write about some of my experiences with aiming for a constant pace by using the empirical freedom of the agile mindset.

Have you ever been in a situation where the development team needs to rush to make the sprint? Maybe you were even a member of the team. Among heaps of reasons, this sprint could have been unintentionally underestimated or maybe impediments affected the development efforts.
Under pressure of different origin, the team will start cutting corners which introduces technical debt or bugs. They will also have a lot of stress in order to try to make the sprint. I even saw teams cancelling their reviews, simply because of the fact that they didn’t finish the sprint. Which in turn has a negative impact on the relationship with the stakeholders.

There might even be another negative consequence; overestimating the next sprint or manipulating the estimations. Team members might do so, so they could relax or even chill at the end of a sprint. This affects the teams pace and doesn’t support the continuous delivery process at all.

During retrospectives teams spend a lot of time figuring out why the sprint wasn’t completed, why the estimates were off, how to increase the velocity, sometimes even questioning their own ability of creating software. Based on these long discussions the team will tune its behavior and starts experimenting.

Common changes or experiments that many teams try are:

  • Spend more time on estimates
  • Spend more time on planning a sprint
  • Spend more time on refinements

And did those experiments pay off? Do the extra time and effort weigh up to any positive effect?

In our case, no. The results of the experiments only took up more valuable time.

When working with Scrum, we already have an agreement with the stakeholders about working agile. The stakeholders are happy with having the ability to adjust their plans and priorities.

Why not take the approach a step further and provide the stakeholders, the Product Owner and the development team even more agility? Get rid of the extensive planning sessions, rushing or relaxing at the end of sprint, using the retrospectives to solve this and creating tech debt?
Let’s aim for that constant pace! For the rhythm, we can endure forever.
Let me start with the fact that we operated in an organization with people who were advocates for the empirical process. So, we experimented a lot!
We learned from every step we took and every failure along the road. And yes, we failed many times, that’s the only way to really grasp the consequences of the experiments.
But in the end, we had something we were pretty proud of and I’ll write down our best practices.


The most important thing that we have introduced looks like an element from Kanban.

In a short planning session, the content of the sprint is determined. During the sprint, the team can pick up stories from the prioritized backlog when they finished the stories. There is no formal commitment on what is delivered in the upcoming sprint, but instead there is a continuous pace in delivering features. And there for a commitment to the end goal. Every sprint we delivered features and this is how we gained even more trust from the users and stakeholders.
This is a first step towards a more kanban-style environment, which in my opinion is a nice and appropriate approach for products built by mature teams. We even called it Scrumban.
We turned sprints in a marathon with the usual Scrum events and artifacts, but with that very important continuous pace.


In order to use this kanbanish method, the top of the backlog needs to be ready for development and prioritized at all times. That’s why we refined a lot. In fact, we refined constantly. We didn’t wait for the refinement or planning session. We kept our stakeholders, users and other teams very close and talked to them on a daily basis. Whenever necessary, they are part of our refinements. Even external companies we relied on for certain API’s, we kept really close and involved them on a regularly basis.

Similar size stories

As a Product Owner, I need to write small, clear user stories and discuss the priority of the stories with the stakeholders and change it accordingly. Therefor the top of the backlog is always up to date. Please have a look at one of my other blogposts about User Stories.

We stopped estimating stories. The reason people are estimating is trying to predict how long a certain story, epic or feature will take. Most of our estimations didn’t result in this goal. Estimating takes a lot of time and in all honesty, it causes hassle and disturbs the continuous development process.
A positive thing about estimation sessions, is the discussion when there are different views on how to create this piece of software. The discussion adds value to the story, because developers, designers and the PO are talking about the story and ventilating their opinion, view or experience. So the positive effect of the discussion is the fact that the user story becomes clearer to everyone.

There are a lot of blogposts about using different methods for gaining predictability and stopping the estimations. Look at the #NoEstimates discussion on the interwebs. I happily refer Neil Killick or Vasco Duarte.

So, no estimates, what then?

I wrote stories that were approximately of the same size, so we could use the story count mechanism. As a PO I really listened to my teams, in order for me to learn about development effort, challenges, architectural dependencies, etc. Everything that has to d

o with the amount of sweat and tears developers and designer put in their daily work. And of course, the team and stakeholders helped slicing the stories until they were fine-grained enough. With this precious knowledge and help I

could write same-sized stories.

Benefits of our way of work:

  • Constant and sustainable development we could keep up indefinitely. My so-called marathon.
  • Short planning sessions; 30 minutes tops. More time left for refinement and development!
  • Estimating can be reduced drastically. Or in our case even discarded in total.
  • The retrospective is not only about failing a sprint or terrible estimates and how to solve that.
  • There will always be a review.
  • Constant communication with team, stakeholders, users and Product Owner, which a positive effect on transparency, expectations and the end result.
  • Fits in a scaled agile environment, because it is still using the standard scrum events and artifacts.

Together with the team we experimented a lot and it finally evolved into this approach. We used our method for 6 months and I’ve seen happier team members, being more productive and delivering product increments more often. And all of this has a positive effect on the stakeholders and the end users.
The take-away should be: experiment a lot and aim for that constant pace in everything. Your product, team members, stakeholders and you will benefit from it.

It is not easy, you will fail at first, but it is worth a shot. Or two. Or three. :)

Lees meer...

User Stories Aren’t One-liners

User stories… in the agile environment everybody is talking about them. And almost everybody is writing them, or at least trying to.
I’ve written hundreds, maybe thousands user stories. They weren’t all great, especially in the beginning of my career. But over time the stories became better and better, because I never stopped learning from colleagues, team members, blogposts and so on. The feedback I got from my teams made me write this post for people who want to read and learn a few tips and tricks for writing better user stories. Or if you are just starting your career as a Product Owner, Business Analyst or any other position in which you’re writing stories, this post could be helpful.

User stories are written for development teams in order to create a product.
The right product.
If you want the right product, you need the right user stories sorted by the correct priority.
I’ve seen many backlogs containing one-liner user stories. The PO let the team struggle with these stories and problems of various kind emerge very quickly. One line is just not sufficient for developers, designers and testers to start working on these items. Lacking information is in my opinion one of the biggest reason for slow progressing of projects, wrong interpretation, rework, unhappy stakeholders, etc.
You can avoid these problems by adding more information. And let me state this up front: adding more information is still agile!

So, what do I do to create good user stories? Stories that contain sufficient information for development teams to work on? Stories that reflect the correct business needs and are easy to understand by any involved person.

Let me start with the basics.
User story is just a notation for requirements. Period.
Is looks like this:

AS persona
I WANT functional wish
SO I CAN do something that has value
WHEN conditions for this story


Persona is the concerning user.
I will discuss the topic persona’s in another blogpost about UX/UI in Scrum.

The functional wish is the core of the story. I want to emphasise that it is a value adding functional wish. Not a solution!
The team will think of a solution for the functional wish or problem. If there is more than one solutions possible, you can help choose the best suitable one. The one that adds the most value in the shortest period of time, the one that has the best future proof characteristics, the one that required the minimum of dependencies, etc.

The last part of the story makes the feature applicable. When should the user be able to use this feature? After logging in? When there is an incoming call? If a certain skill is required? Don’t forget this last bit of important information.

The basics are pretty simple. What’s next?

I ask myself questions like:

  • What story type is this? Is it about a feature, which is part of an epic? Or is it a bug, or maybe part of some technical debt that needs to be solved?
  • When can I accept this feature and deliver it in production?
  • What are the requirements regarding performance, availability, responsiveness and documentation?
  • What exactly is the value we’re adding here? Business value? Yes, so what it is? What if we don’t deliver this feature? What’s the cost of delay?
  • Are there any dependencies related to this story? Do we need another team or an architectural change? Do we need an expert from the business at a certain moment?
  • What if the system goes down? How is the team alerted? Should we monitor the systems behaviour to avoid outages?
  • Any other requirements? Like time constraints, compliance or security, feature toggling, user training, handover to operations, etc?

By asking the business, yourself and the team many of these questions, the user story will be more complete over time, and in the end ready for a sprint. The user story is now to the point, small enough to be comprehended by everybody, easy to change and thus very agile.






Lees meer...

Voorkom een valse start van je project

Soft Systems Methodology (SSM) als ondersteuning bij het uitvoeren van business analyses.


Er worden vaak allerlei redenen aangevoerd waarom ICT-projecten falen.

Een reden die je weinig hoort, maar die heel vaak meespeelt is een valse start. De Soft Systems Methodology (SSM) is een methode die in complexe en onoverzichtelijke situaties helderheid kan verschaffen over problemen en mogelijke oplossingsrichtingen.


Rene van de Wiel - Consultant bij Entrador - Schreef het artikel wat hier te vinden is:

Voorkom een valse start van je project



Lees meer...

Van waterval naar agile….. what’s next?

Organisaties veranderen continu, dat is niets nieuws. De manier waarop organisaties veranderen verandert ook, dat is wel nieuw.

Of het nu gaat om een bedrijfsproces of om de informatiestroom door systemen, de klassieke benadering schrijft een projectmanager voor die de verantwoordelijkheid neemt voor het project en dit voor de hele projectduur volledig vast legt (of laat leggen).

Vandaag werken we Agile en realiseren we in teams stap voor stap wat op dit moment prioriteit heeft. De teams zijn daarbij zelf verantwoordelijk voor het resultaat en beschikken daarbij over faciliterende rollen (bijvoorbeeld Scrum Masters) en vertegenwoordigers van de business (Product Owners) om de juiste koers aan te houden.   

Deze manier van werken is ontstaan in ontwikkel-omgevingen maar dringt inmiddels elders in organisaties door en blijkt zeer succesvol.
Het succes van deze extreem flexibele manier van werken blijkt bij hightech-toppers als Google, Netflix en Spotify.

Verandering is geen project meer maar is een constante factor geworden waarbij sturing plaatsvindt vanuit de inhoud in plaats van uit een hiërarchisch aangestelde rol.

De basis daarin zijn kleine interdisciplinaire teams (squads) die allemaal een eigen deskundigheid inbrengen. Iedere squad werkt van begin tot eind aan een specifiek doel en is verantwoordelijk voor het behalen van dit doel.
De squads hebben veel contact met de opdrachtgevers maar zijn inhoudelijk zelfsturend (ze zijn immers ook zelf verantwoordelijk).

Een groep van squads die aan hetzelfde proces werken vormt samen een ’tribe’. De vorming van tribes zorgt ervoor dat doelen niet strijdig worden en dat er geen dubbel werk plaatsvindt.

Squad-leden door de organisatie heen die hetzelfde type werk doen (bijvoorbeeld Business Analyse) zijn aangesloten bij ‘chapters’. Binnen de chapters worden vakinhoudelijke vaardigheden ontwikkeld en gedeeld.

Deze manier van werken wordt ook wel ‘Scalable Agile’ genoemd en is gebaseerd op Scrum. Alle instrumenten van Scrum zijn echter optioneel in plaats van leidend.

Scalable Agile stelt wel eisen aan de mensen die het moeten doen. Er wordt veel verantwoordelijkheid, flexibiliteit en ondernemerschap gevraagd. Niet alle organisaties zijn hier vandaag klaar voor maar het succes van Google, Netflix en Spotify blijft niet onopgemerkt en veel organisaties nemen de eerste stappen om op deze manier te kunnen werken.

Lees meer...

Scrum Product Owner

Entrador ziet een groeiende klantvraag om te helpen bij de realisatie van veranderingen. Een trend hierbij is dat er een nieuw type gat ontstaat tussen de business en IT.

IT gaat (onder druk van de behoeften van de business m.b.t. snelheid, efficiëntie en resultaat) steeds meer over op Agile ontwikkeling. Ook het snijvlak van business en IT gaat mee in deze ontwikkeling.
De Scrum methodiek biedt een goede houvast om deze Agile ontwikkeling te faciliteren.

Parallel aan deze ontwikkeling verliest de business steeds meer grip op het proces. De vragen „wanneer is het af” en „wat kost het” kunnen niet meer beantwoord worden omdat dit samenhangt met de veranderende wensen, eisen en prioriteitstelling van de business. Een van de middelen voor de business om grip te krijgen op het Agile proces is de Product Owner rol. Deze rol wordt ingevuld door de persoon uit de business die verantwoordelijk is voor de veranderende of de te ontwikkelen dienst of proces. Deze persoon zal tijd moeten vrijmaken om bij het Agile / Scrum team aan te sluiten. Daarnaast zal deze persoon zich moeten verdiepen in de middelen die het Scrum proces hem ter beschikking stelt om grip te krijgen.

Meestal heeft deze business manager hier helemaal geen tijd voor / valt dit niet binnen zijn competentiegebied. Een aangestelde Product Owner kan uitkomst bieden, maar de competentieset van de persoon die deze rol gaat vervullen moet goed passen. In de praktijk blijkt dat een goede Business Analist precies over deze competentieset beschikt. Een officieel certificaat Scrum Product Owner versterkt het vertrouwen van de business in het succesvol vervullen van deze rol.
Om deze reden zijn bijna alle Entrador Business Analisten officieel Scrum Product Owner gecertificeerd.

De verandering in de aansturing van operationele afdelingen maakt dat ook de business projecten op een andere manier moet en wil aansturen. De generieke projectmanager die alle soorten projecten kan managen is aan het uitsterven. De focust komt steeds meer te liggen op de inhoud en het proces. Hiermee neemt de vraag naar experts op het snijvlak van business en IT verder toe. 

Lees meer...

Stappen om Scrum in een organisatie te introduceren

Bij veel bedrijven wordt er gewerkt met Scrum. De een doet het beter dan de ander of is verder met de implementatie ervan. Ik heb de eer gehad binnen een erg professionele Scrum omgeving te werken. Maar niet op alle plekken waar je zult komen is de organisatie al zo ver dat het soepel loopt. Het juist interessant om te kijken naar de omgevingen waar het minder goed loopt of nog beter kan.

Wat zijn nu de stappen die je kunt zetten in een omgeving waar Scrum nog niet zo vanzelfsprekend is en wellicht nog erg in de weerstand zit. Hieronder een paar handige stappen die helpen de Scrum methode een zetje in de goede richting te geven:


 1. ‘just do it’.

Dit is een van de belangrijkste stappen binnen de opzet van Scrum wat mij betreft. Je kunt natuurlijk met iedereen in de organisatie proberen het eens te worden over de aanpak, maar je kunt ook proberen je eigen werk op een Scrum wijze in te richten en dit steeds verder naar buiten te verbreden. Je kunt mensen beter overtuigen met harde resultaten dan mooie verhalen.


 2. Stel een back log op.

In mijn ervaring is de back log vaak de meest cruciale plek om te beginnen. Een lijst met alle items die je gedaan wilt krijgen in je project. Het moet de plek zijn waar ideeën / werk items geplaatst worden die ervoor gaan zorgen dat je project afgemaakt wordt. Het liefst wil je dit meteen laten doen door een Product Owner of iemand die dat in potentie kan worden (business vertegenwoordiger).


 3. Plan Scrum meetings:

-               plan elke dag op het zelfde tijdstip een stand up om dagelijks te kunnen sturen;

-                business overleg om alle business wensen en eisen uit te werken;

-                review / poker sessies om werkomvang in te schatten;

-                retrospectives om continue het proces te verbeteren.

Voor deze overleggen heb je natuurlijk meerdere mensen nodig die hier aan meewerken, maar als je een rol hebt als projectleider of als teamlead heb je vaak de ruimte wel om dit door te voeren. Maak het eens bespreekbaar met je leidinggevende als er te veel weerstand komt. Wellicht is een pilot af te spreken, waarbinnen bepaalde resultaten moeten aantonen dat het werkt.


 4. Plan sprints en releases:

Zorg voor duidelijke werkperiodes, waarbinnen het werk telkens gedaan moet worden. Hoe korter de iteraties hoe makkelijker het proces te overzien is. Een tweewekelijkse sprint of wekelijkse sprint is in mijn ervaring het meest praktisch. De overleggen komen dan ook het beste tot zijn recht. Probeer ook de releases zo kort mogelijk te laten opvolgen. Denk aan eens per maand of werk daar naartoe.


 5. Werk aan Scrum awareness:

Zoek op Youtube filmpjes van H. Niberg of andere mooie voorbeelden, zodat mensen snappen wat Scrum is en wat het nut is ten opzichte van de werkwijze van nu.

Werken met en aan Scrum is niet eenvoudig en kost tijd. Als het eenmaal werkt brengt het vaak erg veel plezier en waarde voor het proces. Met de juiste inzet en faciliteiten krijg je olie tussen de raderen en zal je zien dat het meer gaat opleveren dan alleen een snelle realisatie.

Lees meer...

Agile in de praktijk

Agile en Scrum zijn populaire termen en er zijn ondertussen erg veel aanbieders die voorzien in allerlei vormen van kennis en opleiding. Entrador haar kernkwaliteit ligt al jaren op het gebied van Business Analyse en we hebben veel ervaring en kennis in hoe we de business sterk verenigen met IT. Vanuit onze expertise hebben we een heel concreet antwoord op de stappen die een organisatie moet zetten om meer Agile volwassen te worden en de zo gewenste aansluiting te vinden tussen business en IT in een Agile omgeving.

Onze missie luidt: Agile van theorie naar de dagelijkse praktijk.

Dat houdt in dat we organisaties en teams kunnen helpen om de juiste stappen in de sprint te laten zetten om eruit te gaan halen wat eigenlijk beoogd is met het starten van de Agile transitie.  We leiden niet op tot een certificaat, maar pakken het op waar mensen van de opleiding af komen en op zoek moeten naar hoe het nu echt in het dagelijkse werk moet gebeuren. We trainen on the job en participeren in de transitie.

Samen bepalen we welke volwassenheid de organisatie en de teams hebben op Agile en Scrum vlak en gaan we beslissen welke user stories we op de backlog kunnen plaatsen om dit naar het gewenste niveau te brengen. Dit proces ondersteunen we vanuit Agile (management) Coaching en ScrumMaster rollen, maar ook vanuit Business Analyse, waarin we met een antwoord komen hoe de analyse binnen Scrum een plek krijgt.

Lees meer...
Abonneer op deze RSS feed

Log In

Wachtwoord vergeten? / Gebruikersnaam vergeten?