Category Archives: Agile

Agile

Boek – Getting Teams Done – Spark

Getting Teams Done - SparkHet boek Getting Teams Done is een leuk introductie in Holacracy. Dit boek introduceert de methode waarmee leidinggevenden, teamleiders managers en zelfsturende professionals de teamproductiviteit naar een hoger niveau kunnen tillen. Holacracy wordt bijvoorbeeld ook gebruikt als organisatievorm bij Zappos (lees ook Delivering Happiness).

Getting Teams Done is geschreven in de stijl van Het Doel / The Goal en The Phoenix Project. De romanvorm wordt daarbij in dit geval afgewisseld met een non-fictie deel waarin wordt uitgelegd hoe Holacracy werkt en waar het een oplossing biedt. Daarnaast wordt in dat deel steeds het proces en de ondersteunende technieken uitgelegd.

Het boek Getting Teams Done is een aanrader voor iedereen die geinteresseerd is in Holacracy en zeker voor diegene die werkt voor een organisatie waar Holacracy of een variant als Spark ingevoerd wordt. Het invoeren van Holacracy of Spark vraag een zeer sterke discipline. Daarbij is het handig om hulp van buiten te hebben die buiten de inhoudelijke en andere discussies staat. Op die manier kan er sneller mee aan de slag gegaan worden en kunnen de resultaten eerder worden bereikt.

Velocity 2015 Amsterdam

Thursday was a very interesting day for me at Velocity 2015 Amsterdam, build resilient systems at scale. It is one of the best conferences I attended in the last years. Using some quote’s and bullets I’ll give a little insight.

On retro’s, post mortems, etc

Lindsay Holmwood showed that what goes wrong in retrospectives, post mortems and the like is mostly based on:

  • Confirmation bias – aka ignore alternatives
  • Hindsight bias – aka – alter memories to fit a narrative. Talk about events with the knowledge of the outcome.

To overcome these we could use techniques like: Take opposing viewpoints (on purpose, to investigate things), contrarian thinking, let people explain stuff in terms of foresight and all kinds of sharing information.
In short for this to work we need a safe environment where people can speak up. Starting from the believe that everyone did the best they could. And always keep in mind that there is a difference between work as imagined and works as done.

Optimizing teams in a distributed world – Conway’s 3 other laws

Conway’s Law stems fro the greater part from his 1967 paper: How do committees invent.
The slides and all references mentioned in the presentation.

  1. Whose structure is a copy of the organisation’s structures. To put it different: Communication dictates design. Also check The Mythical Man Month and Dunbar’s number. So manage communication between teams.
  2. – Doing it over – There is never enough time to do something right, but there is always enough time to do it over. Engineering and architecture are always about: Trade offs. Also check: Satisfying vs Sacrificing. So remember it is a continuous process.
  3. If you or your team cannot explain all the code in your release package your release is too large.

  4. Homomorphism – If you have 4 groups working on a compiler, you’ll get a 4-pass compiler. So organise teams in order to achieve what you want (around business capabilities).
  5. Disintegration – The bigger they are, the harder they fall. Time is against large projects and teams. Aim for a scope that supports a release cycle of two weeks or less. So keep your teams as small as necessary.

It is better to be too small than too big.

We are all DevOps

One of the best talks on DevOps in the Etsy world by Katherine Daniels.

On hiring:

It is easier to teach someone a new technology skill, than to teach someone not to be an asshole.

Continuous Delivery at bol.com

Last month two of our software engineers Mihaela Tunaru and Mary Gouseti were invited to give a presentation of how continuous delivery is done at bol.com. The presentation gives a good insight in the state of continuous delivery at bol.com from a software engineering perspective.

In case you want to know more from the operations perspective check Mayfly on GitHub and the presentation below. Maarten Dirkse gave a talk Docker your user stories using Mayfly.

Mayfly is a development platform built by bol.com. Mayfly speeds up your service development by wrapping your scrum user story code in containers, testing it in an isolated, production-like environment and automatically enforcing your Definition of Done.

Presentatie op LAC congres – De architect tussen 35 scrum teams in de 90e sprint…

Op woensdag 25 en donderdag 26 november is de 17e 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: De architect tussen 35 scrum teams in de 90e sprint…

De realisatie van software gebeurt steeds vaker agile. Dit vraagt ook iets van de architect en de architectuur. Software wordt steeds sneller en frequenter naar productie gebracht. Wat betekent dit voor de architect? De hoeveelheid data die verwerkt moet worden door de IT systemen blijft groeien. En nu? Bij bol.com zijn we op weg naar de 100e sprint met inmiddels zo’n 35 scrum teams. Aan de hand van voorbeelden laten we zien hoe we hier bij bol.com mee omgaan en hoe de architect en de architectuur steeds meer volwassen worden.

Bij bol.com hebben we inmiddels heel wat ervaring opgedaan met scrum, Agile architectuur en het schalen van scrum en Agile. In de presentatie zal ik ervaringen delen uit de realisatie van een nieuwe voorraadservice, Logistiek via bol.com, Vandaag Ophalen en de lopende realisatie van ons nieuwe fulfillment center.

Business Intelligence en Big Data bij bol.com

Naast mijn presentatie over Agile architectuur, verzorgt mijn collega Wieneke Keller een presentatie over Business Intelligence en Big Data bij bol.com in de track data science voor architecten:

bol.com groeit stevig door. In onze (micro) service architectuur proberen we deze groei te faciliteren. Belangrijk is dat we inzicht houden in de kwaliteit van onze processen. Bij bol.com doen we dit door big data technologieën in te zetten binnen het BI domein. Zo kunnen we de groeiende hoeveelheden data en databronnen eenvoudig toegankelijk en beheersbaar houden. In deze presentatie wordt toegelicht hoe we dit doen. Ook zullen andere toepassingen van big data bij bol.com worden besproken.

VUCA – Volatility, uncertainty, complexity and ambiguity

Recognising that change is the only constant, shows us the path to VUCA. VUCA is the acronym for volatility, uncertainty, complexity and ambiguity. VUCA stems from military vocabulary and has been emerging in ideas on strategic leadership. The 4 elements of VUCA offer a context in which organisations view their current and future state. On a strategic level who isn’t interested in preparing for a volatile, uncertain, complex and ambiguous future?

There is an easy overview of VUCA on HBR.

Volatility

Volatility basically means that things tend to vary often and widely. The word comes from the Latin word volare, which means “to fly”. In a world were things seem to change faster and faster, stability can’t be attained. During the financial crises and economic turmoil of the last years people kept asking: “When will things be stable again?”. Could be that unstable and turbulence are here to stay.

Uncertainty

In past decades we build our lives on certainties and security. There were things that we could always count on. Nowadays, the uncertainties and the level of uncertainty keeps growing. Think of the economy, technology, whether companies will survive, how markets will evolve. In all these fields things are happening that very few of us have imagined only a decade ago.

What happens in our world and business gets harder and harder to predict. Known cause and effect relations need reevaluation and seem to have turned more complex and with a larger number of factors. We have to dig deeper to solve these unknown cause and effect relations.

Complexity

To properly understand the world we live in and perform our business we have to move beyond lineair models. Although models are getting better, they are based on an overwhelming number of interconnected parts and variables. This to such an extend that even though computers running these model have become better and faster, results and predictions haven’t. Think of the search for better medicines: the money invested is growing incredibly faster than the results we’re getting. Check eroom’s law (Moore’s law reversed) “the cost of developing a new drug doubles every nine years”.

Ambiguity

Ambiguity basically means that you can interpret a thing or situation in more than one way. The explanation and/or interpretation depends on context. This demands us to look at the whole picture to understand what lays in front of us. There is an unclear cause and effect. We can’t come up with a straight answer. There is a strong need for interpretation in context.

Theory of constraints

The Goal - Theory of ConstraintsThink it was back in 1993 I first read The Goal by Eliyahu Moshe Goldratt. The book was one of the first and most notable in the genre of business novels. The book – The Goal – introduces the theory of constraints (TOC) process for improving organisations. The book is set in a manufacturing company. However the book provides the context for a more generic approach to continuous improvement.

Theory of constraints

The theory of constraints is a paradigm that states that the output of a process is limited by a very small number of constraints. In a process there is always at least one constraint. TOC offers a process to determine the bottleneck/constraint and than restructure either the constraint or the work around it so the constraint can deliver it’s maximum output. Since the bottleneck’s output determines the output of the business process, other optimisation are local suboptimal interventions that do not generate any real business value.

The theory of constraints boils down to:

A chain is as strong as its weakest link.

More verbose: An organisation (especially a process or a business) is only as strong or powerful as its weakest activity or person. A group of associates is only as strong as its laziest member.

Constraint

A constraint is anything that prevents the system from achieving its goal. In TOC, the constraint is used as a focusing mechanism for management of the system. The concept of the constraint is analogue to the one in mathematical optimisation. In optimisation, the constraint is written into the mathematical expressions to limit the scope of the solution (X can be no greater than 5).

Types of (internal) constraints:

  • Equipment: The way equipment is currently used, is the limit to the ability of the system to produce more saleable goods/services.
  • People: Lack of skilled people limits the system. Mental models held by people can cause behaviour that becomes a constraint.
  • Policy: A written or unwritten policy prevents the system from creating more output.

Throughput

In general the throughput is seen as the movement of inputs and outputs through a production process. Bottomline it can described as the rate at which a system generates its products or services per unit of time.

In the theory of constraints throughput is the rate at which a system achieves its goal. Mostly this is a monetary revenue and not the items or volume created to be sold or kept as inventory.

Continuous improvement

Goldratt - on-going improvementAs said before the theory of constraints offers an approach for continuous improvement. Optimising the utilisation of the constraint is an important part of the process. Of course this could lead to the discovery that another resource became the constraint. So we continu the optimisation.

As Goldratt states in The Race:

In the midst of a competitive race we should not look for an improvement, we should look to implement a process of on-going improvement.

Beyond manufacturing

IT Operations

The Phoenix Project borrows both content and genre from The Goal. It is a business novel that explains how the theory of constraints can be applied to IT operations. The Phoenix Project describes the problems that almost every IT organisation faces, and then shows the practices (based on the Theory of Constraint, Lean and more) of how to solve these problems.

Design for outcome-oriented teams

While developing an organisation structure for an Agile or Lean business, there is a strong focus on teams being responsible for business outcomes (outcome-oriented teams). These teams are opposed by so called activity-oriented teams (teams responsible for an activity).

To understand the why of the focus on outcome-oriented teams, we need to understand what is a business outcome. Selling a product and generating revenue is an example of a business outcome. This outcome is the result of a chain of activities, like marketing, lead generation, product development, testing and support. To achieve an outcome we often need to break the chain and define suboutcomes. These suboutcomes aren’t that valuable on their own, only in context. If the division continuous, we end up with merely contributory activities. The difference between outcomes and activities is similar to that between user stories and tasks. Activities serve outcomes, like tasks serve the purpose of a user story.

Activities that are no longer directly bound to business outcomes are more likely to be trapped in the pitfall of local optimisation. Activity optimisation is a common cause of silos and of lengthening cycle times. This is because when we organise by activity, no single team can own the outcome (since it broke the being independable requirement).

Careful splitting a business outcome

So we need to be careful how and to what extend we split outcomes. We want to keep both meaning (sense of purpose) and value. How to determine whether a division leads to a suboutcome of an activity? Good business outcomes are:

  • Testable
  • Valuable
  • Independently achievable
  • Negotiable

While splitting into suboutcomes we keep asking whether these suboutcomes remains independent and valuable business outcomes.

Is there still room for activity-oriented teams?

Some support functions in an organisation don’t own independently valuable business outcomes. They are activity-oriented teams, think of departments like HR, admin, legal, finance, controlling. Does this mean that they automatically become silos and should be disbanded?

If the realisation of an outcome is dependent on repeated successful iterations through some core value stream, these activities should not be conducted in activity-oriented teams. Activities that aren’t an integral part of a business outcome’s core value stream could be placed into separate teams without much risk.

However we should remain cautious. Activity-oriented teams tend to “standardise” their operations over time. Their focus moves away from offering custom solutions. Complaints from other teams about rule books and bureaucracy will be your signal.

Definitions

Definitions used in this post are found in Agile IT organisation design:

  • Outcome – An independently valuable and achievable business outcome.
  • Outcome-oriented team – A team that has autonomy and accountability for an outcome. For example a cross-functional product team.
  • Activity – Action that contributes to an outcome.
  • Activity-oriented team – A team that is responsible for a single activity. Usually a team of specialists (marketing, finance, testing, sales).
  • Cross-functional team – An interdisciplinary, outcome-oriented team. It may consist of hard-core specialists, generalising specialists, or generalists.
  • Value stream – A series of activities required to deliver a business outcome.
  • Silo – A unit (team, department) that tends to protect itself and doesn’t work well with other units.

Agile and lean reading list summer 2015

These are the books on agile and lean on my reading list for this summer:

Lean Enterprise

lean enterpriseThe book of the moment on innovation at scale. According to wikipedia (Lean Enterprise):

Lean enterprise is a practice focused on value creation for the end customer with minimal waste and processes. The term has historically been associated with lean manufacturing and Six Sigma due to lean principles being popularized by Toyota in the automobile manufacturing industry (TPS) and subsequently the electronics and internet software industries.

The publishers site on Lean Enterprise:

Through case studies, you’ll learn how successful enterprises have rethought everything from governance and financial management to systems architecture and organizational culture in the pursuit of radically improved performance. Adopting Lean will take time and commitment, but it’s vital for harnessing the cultural and technical forces that are accelerating the rate of innovation.

Agile IT Organization Design

Agile organisation designIn order to scale Agile, it is not enough to just replicate development practices and techniques across teams. We also need to review organization structure and management controls to see if they are in tune with what is needed for responsive IT. Unless we do so, overall IT performance is unlikely to improve. This highly recommended book provides a basis for reviewing and reshaping the IT organization to equip it better for the digital age.

Being Agile in Business

Agile in businessAgile and lean are fast and efficient methodologies you need to change the way you work. This book introduces you to the essential skills and mindsets of agile and lean and quickly encourage you to start thinking differently.

Presentaties februari 2015

Voor februari 2015 staan er diverse presentaties op de planning met name op het gebied van architectuur en agile:

Kennissesies agile architectuur bij Ordina

Op 5 februari organiseert Ordina een kennissessie over agile architectuur in de praktijk. Net als op het LAC zal ik een presentatie houden over de waarde van architectuur en time-to-market. Waarin ik laat zien dat juist architectuur waarde en snelheid kan bieden bij de time-to-market. Dit aan de hand van voorbeelden uit de praktijk bij bol.com .

Symposium Move IT – Logistieke optimalisaties mbv Big Data

Big Data machinesOp 11 februari organiseert studievereniging Inter-Actief Symposium Move IT. Een symposium waarop transport, logistiek en distributie centraal staan. Thema van de presentatie die ik samen met een collega van de afdeling logistiek geef is: Wat is de rol van IT en big data bij het optimaliseren van de performance in de logistieke keten?

Bol.com heeft ruim 5 miljoen klanten in Nederland en België. Met ruim 9 miljoen artikelen en 15 miljoen kliks per dag is bol.com het schoolvoorbeeld van een big data omgeving. Om alle klanten optimaal te kunnen bedienen, moeten onze IT-systemen optimaal werken. De IT-organisatie neemt daarom een cruciale rol in, met 31 scrumteams die worden ingezet op alle organisatieniveaus.

Door deze multidisciplinaire teams worden continue verbeteringen geanalyseerd, ontwikkeld en live gebracht. Dit allemaal in nauwe samenwerking met bijvoorbeeld de logistieke afdeling.

De afdeling Logistiek is verantwoordelijk voor het betrouwbaar en stabiel houden van de supply chain. Daarnaast worden logistieke oplossingen bedacht en uitgewerkt. Dit betekent dat voortdurend alle logistieke processen en systemen onder de loep genomen worden en vernieuwen. Samen zorgen IT en Logistiek dat systemen en applicaties van bijvoorbeeld het ordermanagement optimaal functioneren.


Architectuur in agile omgeving

Daarnaast zijn er twee presentaties / Q&A sessies gepland met bedrijven uit diverse sectoren waarin we laten zien aan de hand van praktijkvoorbeelden hoe binnen bol.com architectuur wordt ingevuld in een agile omgeving. Daarbij gaan we zeker in op hoe je scrum gebruikt in een software ontwikkelomgeving met meer dan 30 teams.