Lion van Koppenhagen


About this site
This blog — sometimes known as my "Braindump" — is my platform for experimentation and community interaction. It is a way of offloading thoughts.

Unfortunately I’m not a WordPress Sensei yet. Many small issues are becoming a hindrance taking time away from my goal of sharing knowledge.

If you are that Sensei, willing to help me out, please send me a private message.

Individuals and interactions over processes and tools

Agile manifesto

Agile is all about mindset and culture yet still in many transitions applying this primary value is overlooked for the agile transition itself. In general, a transition strategy, including organisational changes and process definitions, is communicated after it has been decided on somewhere in the organisation. Now if we accept an agile transition is a project and we look at the following agile principle;

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Principles behind the Agile Manifesto

It isn’t that hard to understand that we missed a step. Unfortunately it’s a crucial step, it’s the difference between doing Agile and becoming Agile.
Lucky for us, that step was already defined long before the Agile Manifesto, it is the Community of Practice.

The Community of Practice

Communities of practice provide a model for connecting educators in the spirit of learning, knowledge sharing, and collaboration…

Cambridge, Kaplan & Suter

What is a community of practice?

  • A community of practice (CoP) is a group of people who share a common concern, a set of problems, or an interest in a topic and who come together to fulfill both individual and group goals.
  • Communities of practice often focus on sharing best practices and creating new knowledge to advance a domain of professional practice. Interaction on an ongoing basis is an important part of this.
  • Many communities of practice rely on face-to-face meetings as well as web-based collaborative environments to communicate, connect and conduct community activities.

Why communities of practice are important

According to Wenger (1998), communities of practice provide five critical functions. They:

  • Educate by collecting and sharing information related to questions and issues of practice
  • Support by organizing interactions and collaboration among members
  • Cultivate by assisting groups to start and sustain their learning
  • Encourage by promoting the work of members through discussion and sharing
  • Integrate by encouraging members to use their new knowledge for real change in their own work.

Communities of practice are important as a professional learning strategy, because they have the potential to:

  • Connect people who might not otherwise have the opportunity to interact, either as frequently or at all.
  • Provide a shared context for people to communicate and share information, stories and personal experiences in a way that builds understanding and insight.
  • Enable dialogue between people who come together to explore new possibilities, solve challenging problems, and create new, mutually beneficial opportunities.
  • Stimulate learning by serving as a vehicle for authentic communication, mentoring, coaching, and self-reflection.
  • Capture and share existing knowledge to help people improve their practice by providing a forum to identify solutions to common problems and a process to collect and evaluate best practices.
  • Introduce collaborative processes to groups and organizations to encourage the free flow of ideas and exchange of information.
  • Help people organize around purposeful actions that develop tangible results.
  • Generate new knowledge to help people transform their practice to accommodate changes in needs and technologies. (Adapted from Cambridge, Kaplan & Suter)

The professional learning needs of educators are changing. Communities of practice offer a robust strategy for professional learning. Here is why:

  • Complex problems require more implicit knowledge, which cannot be codified.
  • Implicit knowledge can only be shared through conversations and observation.
  • Collaborative and distributed work is becoming the norm.
  • Knowledge sharing and narration of work make implicit knowledge more visible.
  • New ideas come from diverse networks, often from outside the organization.
  • Learning is part of work, not separate from it. Communities of practice enable the integration of work and learning.

The value of communities of practice is in the depth of participants’ reflection and inquiry, and how they put co-created knowledge to action.

Success factors

Wenger has identified a number of factors that contribute to the success (and failure) of communities of practices. His ‘top three’ factors include:

  • Identification: Communities of practice thrive on social energy, which both derives from and creates identification. Passion for the domain is key. This makes the clear identification of the domain a critical success factor.
  • Leadership: A key success factor is the dedication and skill of people who take the initiative to nurture the community. Many communities fail, not because members have lost interest, but simply because nobody has the energy and time to take care of logistics and hold the space for the inquiry.
  • Time: Time is a challenge for most communities, whose members have to handle competing priorities. Theoretically, time should not be an issue if the interest is there, but practically it remains a constant challenge. Because time is at such a premium, a key principle of community cultivation is to ensure “high value for time” for all those who invest themselves.

The research describes a number of factors for success including:

  • Identifying a domain that energizes a core group
  • Recruiting a skillful and reputable facilitator
  • Tapping into the expertise of local and international experts
  • Addressing details of practice
  • Establishing the right rhythm and mix of activities
  • Having visible support of organizational leaders, but without micro-management
  • Accessing adequate resources in order to reduce barriers to participation.

The research also identifies these additional factors that contribute to a successful community of practice:

  • self-governance
  • a sense of ownership
  • the level of trust
  • recognition for contributions
  • high expectations for value creation
  • organizational support
  • connection to a broader field
  • interactions with other communities

In conclusion

Looking at the elements of the Community of Practice and how they match the mindset of the core agile values I hope this can help you leading successful transformations.

If you would like to know more or need help, feel free to reach out.

In almost all industries designers use standard parts. These have been extensively tested and have proven in practice that they do not have hidden defects. This is still not the case when designing software. Design based on components is still stuck in its infancy. There are plenty of standards, but the blocks do not fit together well. This post explores an approach forward using the Lego Analogy.

The Lego Analogy

Lego is a great analogy for understanding the importance of standards. Lego have been making bricks (Lego calls them elements) since the late 40s. It took them a little while to perfect their designs. But since 1958 they’ve been manufacturing bricks in the same way, to the same basic standard. This means that you can take any brick that’s been manufactured over the last 62 years and they’ll fit together.

A commitment to standards maximises the utility of all of the bricks that the company has ever produced.

If you look across all of the different sets that Lego have produced, you can see that some basic pieces are used very frequently. If you ask a Master Lego Builder for a list of their favourite pieces, you’ll discover the same.

Now if we would do the same for software development, what would be the list of elements our Master Software Builder would always need? What do we have to design?

Design still happens

Moving away from Big Design Up Front (BDUF) to Agile does not mean letting go of design all together. We need context or guardrails as some might call them. When less is more, we need insights into definition, features and benefits of minimalism applied to basic elements.

In this post we embrace the new IT and take a generic microservices architecture as the starting point. APIs are an incredibly valuable tool – they unlock data, increase agility, encourage innovation and speed up time-to-value.

This brings us to our first element, the API Catalog. Even though we can develop and reuse without a catalog, developers might create the same or similar APIs multiple times because it was not known that there is already an implementation existing. And that’s just the inside perspective. What about somebody from outside your organization looking for a smart way to integrate and connect with your business? Who to call, where to search, where to ask a question? Usually, this leads to people going to different places in order to solve their requirements.

Our first element, The API Catalog, is the Master Builders list of basic elements.

Which are the basic elements?

This is a question I cannot answer for you. The collection of basic elements is defined by the needs of your organization. This is why a strategic approach to APIs is vitally important to your business. It’s not up to me to decide what should be in your toolbox.

Think about creating a pool of resources generic enough that they can be applied to different projects. Reusing capacity improves efficiency and effectiveness, all the while reducing costs and increasing the potential return from projects.

Principles that should lead you to the elements essential to be in the catalog are:

  • Security by design
  • Privacy by design
  • Telemetry by design
  • Testing by design
  • Scalability by design

Failing to take any of these principles into account will lead to high refactoring cost in the future. Using these principles you can land and expand. Always keeping the big picture in mind but build for immediate use. Build simple blocks and have the teams decide which next block would add the most value.

This article is part of a series of articles themed Legolizing software development. I will post more on my site, follow me on linkedin or facebook if you like to read more.

Isn’t it time to move from hindsight to insights?

In the era of the smartwatch we find it normal to know about ourselves with literally a flick of the wrist, we call it quantified self. Isn’t it time to really move towards the quantified organization, to Fitbit your organization?


We read about big data, data driven decision making and business intelligence everywhere, buzzwords enough, but when it comes to reality we only use it in hindsight.

These days, if I walk into an office, I get an immediate answer when I ask a manager about sleeping patterns or heart rate. However, if I ask about the performance of the main value streams or delays in those value streams, I’m usually directed to the BI-team. If I ask an SMB owner about cash flow, I’m directed to his accountant. Maybe you feel comfortable driving your car without a realtime dashboard but you shouldn’t and the same goes for managing your organization big or small.

Insights, the path to success

When driving you usually at least watch the speedometer on your dashboard, you don’t go to the garage to ask at what speed you have been driving. Why should managing an organization be any different?

While sometimes it’s okay to follow your instincts, the vast majority of your business-based decisions should be backed by metrics, facts, or figures related to your goals.
By leveraging the wealth of data available into insights, it’s possible to make more informed decisions that will lead to commercial growth, evolution, and an increased bottom line. Those insights should be available in now, not later. What’s holding us back?

Scattered data, high complexity

We have so much data but it’s scattered in silos, or using it is to complex, or our IT organization expects us to use BI-Tools when all we want is insights.

About 10 years ago I was asked to come and drink a cup of coffee at a multi-national sales organization. The sales people where send on a Microsoft training SQL Server Reporting Services so they could create the insights they needed themselves. Imagine the panic. I was asked if we could design a simple solution, we could and we did and it became the most used unofficial application in the company.

So how did we do it and how can you do it?

Land and expand

We followed a simple agile path. Think Big start Small. Always keep the big picture in mind but build for immediate use. We didn’t start off building a complete solution. We build simple blocks named in the language of the users that allowed them to correlate data from various sources into reports, without the need to know the source or how to get there. The salesforce decided which next block would add the most value. All reports were based on data in near real time.

You can do the same for/with your organization. By implementing the right reporting tools block by block, you will be able to make the kind of data driven decisions that will drive your organization forward. It isn’t hard and it should not be costly. Just do it!

This article is an introduction to a series of articles themed telemetry by design. I will post more on my site, follow me on linkedin or facebook if you like to read more.

“Software development is a serious business, but it is also seriously fun. To put it stronger: If it does not remind you of playing with LEGO when you were still a kid, you are doing it wrong.”

Maurits van der Schee

I have been involved in software development and organizational processes since I was 15 years old. Common sense and laziness have always been the most important guideline for me. Just think about what you want to achieve and do it so that you don’t have to do it again.

In my career, LEGO has always been a source of inspiration in solving issues. Probably because I played with it for hours as a child and learned to solve every challenge by doing it brick by brick.

As a fan of Lego, with a keen interest in science, the feature image is a creation from designer Andrew Carol Senior Engineer at Apple. In case you don’t recognise it, it is a rebuild of what is claimed to be the world’s oldest known computer.  The mechanism is known as the Antikythera Mechanism, part of an astronomical computer built around 150 BC to calculate the movements of celestial bodies.

The image and the quote seemed a good introduction to my article series legolizing software development.

This article is part of a series of articles themed Legolizing software development. I will post more on my site, follow me on linkedin or facebook if you like to read more.

“We had started to make fire trucks that look like spaceships, building systems that no customer could truly appreciate. We had to clean that up.”

Mads Nipper

For some reason I always look at Lego for inspiration when I need to give structure to what goes on in my mind. For me this quote summarises the perpetual tendency to deform simple, elegant solutions into useless monstrosities, spending millions along the way.

I started developing software on a ZX Spectrum and no matter the years of management and consulting, that mindset of a developer is how I look at the world. The list of frameworks I have endured over the years is endless and what they all have in common, is the hours spent by organizations and teams not delivering value. Even worse, the frameworks have become resource hogs, draining organizations of time and money in the attempt to improve. So what’s the problem?

Frameworks, the imposed approach

Regardless whether the framework is called SDM, Prince2 or one of the current frameworks such as SAFe or DAD, they are pitched to the organization and imposed on the teams. Leadership has had little training and consultants are brought in to achieve a lightning change into product and software development. And then there is the failure to achieve the goals of the change. Why?

The framework became the goal

In the rush to improve organizations to achieve their goals more efficiently, the frameworks tend to become the holy grail. Process and procedures are forced upon teams and control mechanisms are put in place to provide management with progress overviews. Failure to meet targets leads to changing the consultants, changing the framework or both and to no avail. Why?

Failure to address culture

Culture, the hardest component of an organization to change. It is not the framework or methodology that makes a team successful. It is the culture and mindset in the organization that leads to success. Change needs to come from culture and a mindset, not a framework. So where do frameworks fit?

The use(fulness) of frameworks

Changing culture and mindset takes time, it also needs tangible tools to help you on the way. Following the ShuHaRi concept, frameworks can be useful as a tool in the journey of change. The most valuable element in change, being lessons learned or retrospectives, can be found in any modern framework. Use frameworks wisely, use them to support the change you wish to achieve but beware, don’t let using the framework become the goal.

If you would like to know more or need help, feel free to reach out.

Read More

For those interested in flow, another oriental way of thinking might also be good to read up on.


Shu – In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.

Ha – At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.

Ri – Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

Applied to yourself it helps you recognise how Agile you are, applied to others, It helps you coach them in their maturity drive at the right level.

Freight transport and logistics are recognized to be large contributors to greenhouse gas emissions and to contribute to a set of specific problems (congestion, air and noise pollution), directly affecting climate change and pollution. Zero emission logistics is dedicated to address these problems, supporting both optimisation of the logistics movements as well as looking into the introduction of new technologies into the traditional logistics processes.

In 2007-2009, when I was working at TNT as part of the TNT Planet Me project, I developed a passion for this subject. More recently, in 2017-2020, I got the chance to dive deep into dynamic routing, optimisation of the logistics movements, at Bpost.

A pragmatic approach to zero emission logistics is required

Getting to zero emissions in logistics is an enormous challenge. In a cost-driven industry, a high-cost, high-risk focus on zero-emissions technology may position many players as part of the dirty past – not the clean future. We need a pragmatic approach that balances high-tech practices with practical ones that offer a role for everyone. We can reduce avoidable emissions through more efficient supply chains, but we need to shift mindsets. Reducing avoidable emissions alone won’t get us to zero. But this approach is open to everyone everywhere, starting now, and it can save fossil fuels in the present, and open the door to zero-carbon fuels in the future.

In 2007 I was hired as an external consultant in the role of project manager/solution architect, by Peter van Minderhout, Group Director Communications and Social Responsibility, to be part of the TNT Planet Me movement.

In my role I had the responsibility to bring all the elements together in a web platform.

The TNT Planet Me scope

Fighting climate change: Planet Me

It is our ambition to become the first zero emission transport company.

  • We will measure and manage our CO2 footprint in a transparent manner through our Count Carbon initiative
  • We will continuously increase the CO2 efficiency of our operations through our Code Orange initiative
    (aviation, buildings, lease fleet, customer collaboration, company cars, purchasing, investments)
  • Choose Orange will engage our employees to participate at work and at home with their families
    ( One of these initiatives is a global contest to reduce fuel consumption: the Drive Me challenge)

My Role within the scope

This is just a simple listing of the key tasks within my role.

  • Design the web architecture for the tnt planet me platform
  • Lead the development team building the platform
  • Align with the design agency on the UX
  • Align with the carbon accounting team on the way to display their reports on the platform
  • Align with all daughter companies on their contribution to the platform
  • Design the choose orange community platform
  • Lead the development team building the community platform
  • Coordinate the roll-out of the video conferencing solution
  • Stakeholder management of all parties required to fulfill the tasks above

My Takeaways

When I left the project in 2009, I left with two takeaways on top of my mind:

  • Working for Peter van Minderhout really made me grow fast. For me it was a person who gave you absolute trust. Allowing you to make the choices to “make things happen”.
    TNT Planet Me was my fast track to global stakeholder management.
    I still remember my first conference call where I had to explain the benefits of the beautiful new video conferencing solution to the CEOs of the 38 daughter companies across the globe (who did not really see a benefit in making less trips around the world) and get them to start using it. You learn to deal with hostility quickly. His advice was simple whether it was internal or external, keep haunting them until they give you what you want, sometimes you need to be a respectful “pain in the ass”.
  • It is here that I got infected with the passion Peter Baker has for sustainable development. It is the main reason that one of my pet subjects is Zero Emission Logistics.

This blog — sometimes known as my “Braindump” — is my platform for experimentation and community interaction. It is a way of offloading thoughts.

With each post, I try to delve deeper into the ever-expanding universe knowledge on any subject that interests me.
I understand that growing my skills not only takes time and an unquenchable thirst for knowledge, it also takes the support of others.
That’s why my blog tries to be just as much Question as it is Answer. I find that the feedback provided by my readers is just as helpful, if not more so, than the content itself. As such, I do my best to promote high-quality conversations from which everyone in the community can learn.

At the moment I closed the commenting options. I first need to research the privacy protection on this platform.