Tag Archives: Agile

Two interesting reads on team structure and focus

(Re)discovered two interesting reads on team structure and focus this week that I like to share.

Pioneers, Settlers and Town Planners

pioneer, settler and town planner The Pioneers, Settlers and Town Planners approach help structure organisations and teams. It takes into account how activities and practices move from chaotic (poorly understood, uncertain, constantly changing, rare, future source of worth) to more linear (well-defined, predictable, stable, common, cost of doing business) and how organisations contain a mass of these activities and practices. Understanding this and using the right methods and tactics is important to creating a balance between the unstable but potentially high margin activities (chaotic) and the stable and low margin (linear).

McKinsey’s Three Horizons of Growth

McKinsey’s Three Horizons of Growth are all about keeping you and your teams focused on growth and innovation. This strategy framework requires you to categorize your goals into 3 different ‘horizons’. You can also split the activities of your team to the three types of activities that are related to fulfilling the goals for the different horizons. In that case, a team could spend (as a rule of thumb):

  • 70% on activities that are most closely aligned to your current business.
  • 20% on taking what you already have, and extending it into new areas of revenue-driving activity.
  • 10% on introducing entirely new elements to your business that don’t exist today.

This helps ensure that you consistently balance your focus between the needs of today (horizon 1), the future state of your business (horizon 3) and the steps that you need to take to get there (horizon 2).

Presentation Applying “web scale” patterns in the bol.com back office

Codemotion web scale pattern presentationThis week at Codemotion I gave a presentation on web scale patterns and how we apply them in the bol.com back office services. Codemotion is the biggest tech conference in Italy and one of the most important in Europe.

The presentation shows how we go from business goals to software patterns. The following patterns were covered: CQRS, event sourcing, polyglot persistence and micro services.


Presenting at Codemotion next week on web scale patterns

Peter Paul van de Beek CodemotionNext week I’ll be presenting in Amsterdam at Codemotion on web scale patterns in bol.com back office services. Codemotion is the biggest tech conference in Italy and one of the most important in Europe, with a network of more than 30k developers.

The title of my presentation is: “Applying “web scale” patterns in the bol.com back office”. In the session, we show you how we use “web scale” patterns to achieve scalability and flexibility in our back office software. We will guide you through how we apply patterns like CQRS, event sourcing, polyglot persistence and micro services to solve puzzles in our back office services. Interesting is that in our experience we don’t need these just to solve a technical problem. It helps us to solve some of our business problems!

See you on May 16 and 17 in Amsterdam. There is a short interview with me on Codemotion world.

Presentatie Agile schalen op basis van best practices

Net als de afgelopen jaren heb ik afgelopen vrijdag een presentatie over Agile Architectuur gegeven. Kern van de presentatie dit jaar is dat bij het schalen van Agile vooral de problemen/uitdagingen die je onderweg tegenkomt aangepakt moeten worden en niet klakkeloos een framework gaat implementeren. Aan de hand van voorbeelden leg ik uit hoe we dit binnen bol.com aanpakken.


Book – Holacracy

HolacracyIk kwam een mooie samenvatting van het boek Holacracy van Brian J. Robertson tegen. Eerder schreef ik een review over Getting Teams Done. Waarin holacracy (en de variant Spark) beschreven wordt als een methode voor teamproductiviteit, net als GTD dat is voor individuele productiviteit. Mijn ervaringen met de holacracy variant Spark beschreef ik in deze post.

De case die vaak gegeven wordt als holacracy adoptie beschreven wordt is Zappos, maar er zijn veel meer cases beschreven.

Presentatie op LAC congres – Agile schalen op basis van best practices

lac-agile-schalen-op-basis-van-best-practicesOp donderdag 17 en vrijdag 18 november is de 18e editie Landelijk Architectuur Congres. Net als vorig jaar ga ik in de track Agile Architecting een presentatie geven over architectuur en architecten in een Agile omgeving. De titel van de presentatie dit jaar is: Agile schalen op basis van best practices.

Bij bol.com hebben we jarenlange ervaring met het werken met agile en scrum. Het aantal IT teams dat hiermee werkt is de laatste 2 jaar enorm sterk gegroeid. Daarnaast doen we diverse experimenten met holacracy. Voor het opschalen zijn we steeds op zoek gegaan naar best practices. Je zal dan ook veel elementen uit SAFe terug zien, maar nooit SAFe.

Agile schalen op basis van best practicesIn de meer dan 100 scrum sprints die we er bij bol.com inmiddels op hebben zitten hebben we een berg ervaring opgedaan met agile architectuur en het schalen van agile practices. Architectuur kan een belangrijke bijdrage leveren aan een snellere time-to-maket. In de presentatie zullen voorbeelden gebruikt worden uit bijvoorbeeld de realisatie van sneller en vaker leveren, de winkel langer open en Logistiek via bol.com.

Sneller en vaker leveren

Onze winkel gaat sneller en vaker leveren. Zoals je in de afbeelding kan zien is het maar een kleine aanpassing in de front-end/website. Zoals met veel fulfillment aanpassingen zit er een hele wereld van planning en operatie achter om dit ook daadwerkelijk voor elkaar te krijgen.
Sneller en vaker leveren

Sneller en vaker leveren maakt het met de al bestaande leveropties voor klanten mogelijk om de levering van bestellingen af te stemmen op hun behoefte.

Organizational Debt

Organizational DebtEveryone knows what debt is. If you are in or around the software development community you probably also know the term technical dept. For others:

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

Or as Ward Cunningham describes it:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite … The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation.”

But there is a third kind of debt: Organizational Debt. Here we pay interest on bad decisions of decisions that we put off. This, of course, has a strong impact on organisations.

Some definitions of Organizational Debt

In organizational debt is like technical debt but worse Steve Blank gives this definition:

Organizational debt is all the people/culture compromises made to “just get it done” in the early stages of a startup.

However, I think that organisational debt isn’t a startup thing. It is worse in other organisations since there is a large accumulation of bad decisions and decisions not taken. Besides that larger and/or older organisations tend to have more rules to work around.

That is why I like the shorter description offered by Scoot Belsky in Avoiding Organizational Debt:

Organisational debt is the accumulation of changes that leaders should have made but didn’t.

Another interesting description is given by Aaron Dignan in How to eliminate organizational debt

The interest companies pay when their structure and policies stay fixed and/or accumulate as the world changes.

This one really goes from the VUCA point. The ever changing world in which organizations have to adapt or are to be extinct.

Scrum guide is updated

Scrum Guide Scrum Values Just last week the latest update of the Scrum Guide was released. In this latest version of the Scrum Guide the five values of scrum play a more important role than in previous versions. In my 4 year old Scrum Guide Mind Map these values aren’t around.

These values amplify the power of Scrum by providing a compass for decision making. They help teams adopt Scrum and deliver amazing software for their customers. They also prove fundamental to create a great place to work.

Scrum values

The Scrum values are:

  • Courage – Being transparent, but willing to change even if that means accepting that you are wrong, or that your opinion is not the direction that the team is going.
  • Focus – focus on what’s most important now without being bothered by considerations of what at some point in time might stand a chance to become important.
  • Commitment – commitment is about dedication and applies to the actions, the effort, not the final result.
  • Openness – Highlighting when you have challenges and problems that are stopping you from success. The empiricism of Scrum requires transparency, openness. We want to inspect reality in order to make sensible adaptations.
  • Respect – Helping people to learn the things that you are good at and not judging the things that others aren’t good at.

There is an interesting post on these values by Gunther Verheyen.