Tag Archives: Lean

Lean

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.

Boek – De Bijenherder

De BijenherderDe Bijenherder is een management novel. Het boek is dus geschreven in de stijl van The Goal, The Phoenix Project, De Kracht van Scrum en bijvoorbeeld Getting Teams Done. Waarbij de laatste twee ook het aandachtsgebied delen met De Bijenherder.

Leiding geven aan zelfsturende teams

De zoektocht in het boek is die naar hoe leiding te geven aan zelfsturende teams. Door de toenemende omslag naar zelfsturende teams wordt ook deze vraag steeds vaker gesteld. En terecht want daarnaast blijkt dat een van de fricties bij het werken met zelfsturende teams is dat deze op een traditionele manier gemanaged worden. En dat blijkt niet goed te werken.

Het blijkt in de praktijk helemaal niet eenvoudig om zelfsturende teams aan te sturen. Wat kan en mag er nog gestuurd worden? Het is heel anders dan de aansturing van een team door een traditionele manager. Deze omslag wordt bijvoorbeeld ook in reinventing organizations goed beschreven.

Waar de meeste aanhangers van zelfsturende teams een sterke voorkeur hebben om te doen en uit te proberen, gaat De Bijenherder nauwelijks verder dan het denkproces dat de hoofdpersoon doorloopt om te komen tot een aanpak. Deze is weliswaar gebaseerd op de praktijkervaring van zijn opa, maar dat blijft iets anders dan zelf ervaren. Iets wat de hoofdpersonen in The Goal, The Phoenix Project en Getting Teams Done wel ondergaan.

De presentatie van Mark van den Burg

De hoofdpersoon maakt van de lessen die hij leert en die zijn opa hem leert een presentatie. Deze presentatie ziet er ongeveer zo uit:

Het boek en de presentatie daarin gaan een slag dieper dan hierboven weergegeven. Dat biedt voldoende aanknopingspunten om een (flinke) stap te maken in het leiden van zelfsturende teams. Naast het boek en de aangereikte handvatten daarin, moet je als leidinggevende natuurlijk zelf aan de slag, zelf doen en ervaren. De ervaring en feedback kun je dan weer ijken aan de aandachtspunten die in het boek worden meegegeven.

En?

De Bijenherder is een aanrader. Het leest makkelijk en de basis van het aansturen van zelfsturende teams wordt zeker goed duidelijk. Er worden praktische tips aangereikt.
Daarna is het doen. Zorgen voor feedback en toetsen aan de handreikingen die de hoofdpersoon voor je heeft opgesteld.

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.

Innovation – Horizontal and Vertical Progress

In the book Zero to One Peter Thiel (member of the PayPal mafia) distinguishes between two types of progress:

  • Horizontal or extensive progress
  • Vertical or intensive progress

Horizontal or extensive progress

Horizontal or extensive progress means copying things that work. It is going from 1 to N. It isn’t to hard to imagine horizontal progress. We already know what the base looks like.

From another level horizontal progress is globalisation. It is taking things that work somewhere and making them work everywhere.

Vertical or intensive progress

Vertical or intensive progress means doing new things. It is going from 0 to 1. Vertical progress is harder to imagine because it requires doing something that nobody else has ever done.

The single word for vertical progress is technology. However there is no reason that technology is limited to computers! Any new of better way to do things is considered technology.

Technology matters more that globalisation

Thiel states that if the future would be just about globalisation it would be catastrophic. If without any technological advancement just China and India would copy the way we live in Europe and North America, we would need to scale energy production and utility of scarce resources to such an extend that would devastate our planet. Spreading (copying) old or even current ways to create wealth are not sustainable. We need technology to advance our ways to create wealth in a sustainable way.

The thing is that although since the invention of the steam engine around 1760 up to around the 1970 there has been a tremendous technological progress. Creating more wealth and well-being for each generation. And we expected this to continue. But did it? But a better future doesn’t come automatic. Since the late 1960’s only computers and communications have improved dramatically.

Just think of Eroom’s Law: the observation that drug discovery is becoming slower and more expensive over time. This isn’t a new trend. It was first discovered in the 1980’s.

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.

Finding billion dollar startups in Europe

The WSJ billion dollar startup club

The Wall Street Journal and Dow Jones VentureSource are tracking venture-backed private companies valued at $1 billion or more. This group of companies is called the billion dollar club.

The infographic created by the WSJ can be used to track how the membership of this club evolves and what the valuation of these companies individual and as a group is. In line with the findings in the Digital Evolution Index there is a limited number of European companies in the club and their number and valuation aren’t growing as fast as Asia and USA ones.

In January 2014 only 2 of the 42 companies in the billion dollar club are from Europe. In September 2015 just 10 of the 118 are European based companies. Here is the list of billion dollar startups in Europe:

  • Spotify
  • Global Fashion Group
  • Delivery Hero
  • Powa
  • Adyen – Read: The unicorn of Amsterdam
  • BlaBlaCar
  • Klarna
  • Home24
  • Shazam
  • Farfetch
  • Funding Circle

Rocket Internet and Zalando exited the list in October 2014 because of their IPOs. All are located in the countries with the best internet infrastructure: United Kingdom (London), Sweden, Germany, The Netherlands, Luxembourg and France.

The TechCrunch billion dollar startup club

Besides WSJ and Dow Jones VentureSource TechCrunch also curates a list of Unicorns. A Unicorn being a private company with a post-money valuations of $1 billion or more. The TechCrunch Unicorn Leaderboard features one European company that isn’t listed at the WSJ’s list: Auto1 Group from Berlin, Germany.

The picture in both leader boards is the same: there is a relative low number of billion dollar European startups. It is the same in the emerging Unicorns list.

Does Europe fall behind?

Looking at both the WSJ and TechCrunch list of unicorns and the findings in the Digital Evolution Index it certainly looks like Europe is falling behind. If the EU wouldn’t agree why would they have bothered to start a digital agenda (a Europe 2020 initiative)?

Thomas Petersen has written Why is Europe failing to create more unicorns? Mainly stating that there is no true single European market, the EU doesn’t make it better for entrepreneurs (yet worse because of legislation and political sub optimisations), and there is geolocation where both money and technical knowledge gravitate to.

Besides those, there is a reason that al European unicorns are situated in the countries with the best internet infrastructure. Larger parts of Europe aren’t in that position yet.
Some of the European countries with unicorns are in the stall out group in the DESI index. Meaning that measures should be taken to get their momentum back because they run the risk of falling behind.
Again Europe should work really hard on creating a true single digital European market. Reducing the number of laws and trade barriers is key.

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.