Category Archives: Lean

Lean

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.

Another interesting week for studying organisational culture

As expected reactions, stories and initiatives didn’t halt just a week after the NY Times published: Inside Amazon: Wrestling Big Ideas in a Bruising Workplace. This was just the beginning of an interesting study of the culture of high demanding organisations.

Julia Cheiffetz - studying organisational cultureLast days I was moved and impressed by Julia Cheiffetz story. The Executive Editor at HarperCollins Publishers wrote about here experience at Amazon: I Had a Baby and Cancer When I Worked at Amazon. This Is My Story. If you don’t have a Medium account and don’t want to get one check the coverage and quotes on GeekWire. Julia’s story shows both upsides and downsides from the culture she experienced at Amazon. It offers a strong perspective.

Given her experience at Amazon I think she gives great feedback to Jeff Bezos in a very strong way. Feedback he asked in a reaction on the NY Times article. Julia Cheiffetz:

You asked for direct feedback. Women power your retail engine. They buy diapers. They buy books. They buy socks for their husbands on Prime. On behalf of all the people who want to speak up but can’t: Please, make Amazon a more hospitable place for women and parents. Reevaluate your parental leave policies.

And on hiding behind numbers:

You can’t claim to be a data-driven company and not release more specific numbers on how many women and people of color apply, get hired and promoted, and stay on as employees. In the absence of meaningful public data — especially retention data — all we have are stories. This is mine.

The thing here is that culture is reflected in the way you act on a daily basis. If it doesn’t show there, it is just words…

Alternative leadership principles will change the culture

Another way of providing feedback requested by Jeff Bezos, was the launch of a blog called Amazonian Manifesto. The post were published by “A Concerned Amazonian“. The text suggests that there is some collective behind this avatar.

The blog publishes alternative leadership principles for Amazon. In short they are:

  1. Obsess about the Customer
  2. Obsess about the Employee
  3. Obsess about the Partner
  4. Hire and Develop the Best
  5. Own and Fix
  6. Invent and Simplify
  7. Deliver Results

It is clear that these principles are inspired by and based on Amazon’s current leadership principles. However new dimensions are added (focus on the employee, the partner, own and fix) that are ment to heal the flaws that could lead to an unhealthy work environment. It is clear that different guidelines and measurement will lead to different results…

What if Amazon studied culture at Zappos (it owns)

Delivering Happiness - studying organisational cultureAnd what would happen if Amazon started studying organisational culture at zappos.com, a shoe and clothing shop it acquired in 2009? Zappos was founded in 1999 by among others Tony Hsieh, who wrote Delivering Happiness: A Path to Profits, Passion, and Purpose . A book that is described as:

The visionary CEO of Zappos explains how an emphasis on corporate culture can lead to unprecedented success

and features quotes like

I made a note to myself to make sure I never lost sight of the value of a tribe where people truly felt connected and cared about the well-being of one another. To me, connectedness—the number and depth of my relationships—was an important element of my happiness

Zappos culture is obsessed with customer happiness. And Tony Hsieh is for Zappos obsessed with creating a corporate culture based on connectedness and care. That creates different and great results. The book Delivering Happiness offers great insight on how to achieve this and what choices have to be made. It is a great read.

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.

Sometimes development is just work

No matter how cool your job is, no matter how many people are looking at you or your company for best practises, sometimes developing software is just work 😉 On this blog I’ve shared examples of companies that people nowadays see as successful, like Netflix, Twitter, Spotify, or the online retailer bol.com.

To prove my point I’ve checked the release notes of Netflix and Spotify apps. Here is what they show for recent updates:

Software development at Spotify is just work

You can find recent release notes for Spotify. For future reference here is a screenshot of how these looked today:
Software development at spotify is just work

As you can see it is mainly fixes and a new translation… Where did all the fun stuff go. Think the cat took it? So crafting software could be “just” improving and step by step creating a great product!?

Software development at Netflix is just work

Now lets look at Netflix. Just looked up the release notes of Netflix in the iTunes store. Here is how they looked today:
Software development at Netflix is just work

Wow! Updates and bug fixes. That sounds really cool. That must be loads of fun. So could it be that even working on awesome apps for great companies is (at least for a part) just work?

Success needs work

So sometimes software development is just work. Just don’t forget:
The only time success comes before work is in the dictionary.
Could have said it better Harvey: The only time success comes before work is in the dictionary.
Fun and play are a part of you as a person. Work is just a way to make it flow…

Book – The Phoenix Project

Book The Phoenix ProjectThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is written the by Gene Kim in the tradition of The Goal (1984, by Dr. Eliyahu M. Goldratt). The Goal is a management novel explaining the Theory of Constraints. This book, The Phoenix Project shows how the theory in The Goal works in an IT environment.

The Goal – Theory of Constraints

In simple terms the Theory of Constraints is about:

A chain is as strong as its weakest link.

In this theory the first step is to identify the constraint. Step 2 is to exploit the constraint. In other words, make sure that the constraint is not allowed to waste any time. Only by increasing flow through the constraint can overall throughput be increased. This to the extend that improving something anywhere not at the constraint is an illusion.

Because of the need for flow, work in process (WIP) is the silent killer. Therefore, one of the most critical mechanisms in the management of any plant is job and materials release. Without it, you can’t control WIP.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

The Phoenix Project describes the problems that almost every IT organization faces, and then shows the practices (based on the Theory of Constraint, Lean and more) of how to solve the problems. The main character Bill, is thought how to deal with these problems using the Socratic Method. Each dialogue a question is posed to which in turn causes Bill to think and to talk to his colleagues to come up with a solution to their problem.

Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. Leading to the application of the Theory of Constraints in terms like:

The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that’s what’s between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery.

Work in process in IT perspective

Until code is in production, no value is actually being generated. It’s merely WIP stuck in the system. By reducing the batch size, you enable a faster feature flow. In part this is done by ensuring the proper environments are always available when they are needed. Another part is automating the build and deployment process. Here we recognize that infrastructure can be treated as code, just like the application that Development ships. This can enabled to create a one-step deploy procedure.

Besides the parts mentioned before this requires removing a unneeded (since no value is created) hand off between Development and Operations. For this to work the two have to be integrated, not separated.

Like in a manufacturing plant, in IT, it is crucial to manage the release of work to the shop floor / development and to track the work in process. There are a lot of visual aids available to support this, like Kanban or scrum boards. All have their origin in lean or agile ways of working.

No need to say that in the novel this all works out pretty well 😉 In real life we see that these principles work, however more iterations are needed to really improve things. These iterations at first look like failures because of the acceleration of entropy. They are needed in the learning process of people and organization. Reduce the feedback cycle and learn fast!

On the relation between business and IT

There are some interesting statements in the book, that are heard more often in the industry.

IT is not just a department. IT is a competency that we need to gain as an entire company.
We expect everyone we hire to have some mastery of IT. Understanding what technology can and can’t do has become a core competency that every part of this business must have. If any of my business managers are leading a team or a project without that skill, they will fail.

And:

In ten years, I’m certain every COO worth their salt will have come from IT. Any COO who doesn’t intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job.

Personally i think they hold at least some value. Please share your ideas in the comments.

Presentatie op LAC congres – Agile architectuur presentatie

verleiding - Agile architectuur presentatieWoensdag 26 november en donderdag 27 november is het jaarlijkse LAC congres. Dit congres voor architecten in de wereld van organisatie en IT heeft dit jaar als thema: “Architectuur in Actie“.

Presentatie Afweging waarde van architectuur en time-to-market

Op donderdag zal ik een Agile architectuur presentatie geven in de track architecuur in actie: “Afweging waarde van architectuur en time-to-market

Zo’n beetje iedere architect of ontwikkelaar komt op het minst in de verleiding: een snellere time to market realiseren ten koste van de architectuur of de kwaliteit van de implementatie. Het komt voor in software-aanpassingen, maar ook meteen bij de introductie van nieuwe technologie. Aan de hand van voorbeelden uit de afgelopen twee jaar, laten we zien hoe we hier bij Bol.com mee omgaan. Bij een bewuste keuze kan architectuur of de architect wel eens de factor zijn die de versnelling kan realiseren.


Het complete programma van het LAC congres.