Trunk-Based Thierry de Pauw

In short, Conway’s Law says any organisation that designs a system will come up with a system design that copies the organisational communication structures.

Over the years, many many people paraphrased Conway’s Law in many different ways.

Every paraphrase brings new insights and non-negligible consequences. Sometimes giving the impression they contradict each other. However, in the end, they all come to the same conclusion. The organisation and the system keep each other in… Show more

In short, Conway’s Law says any organisation that designs a system will come up with a system design that copies the organisational communication structures.

Over the years, many many people paraphrased Conway’s Law in many different ways.

Every paraphrase brings new insights and non-negligible consequences. Sometimes giving the impression they contradict each other. However, in the end, they all come to the same conclusion. The organisation and the system keep each other in balance.

To be competitive, we’d better understand and take advantage of this.

Show less

Continuous Integration is by itself already a practice. It is one of the most critical to adopt to enable the fast flow of work through the value stream. However, many teams believe Continuous Integration is just a tooling problem, to then say they practice Continuous Integration.

Though they often do not and hence miss out on the benefits that come along with it. This session goes deeper into the practices that each on their own enables Continuous Integration. Learn how to gain fast… Show more

Continuous Integration is by itself already a practice. It is one of the most critical to adopt to enable the fast flow of work through the value stream. However, many teams believe Continuous Integration is just a tooling problem, to then say they practice Continuous Integration.

Though they often do not and hence miss out on the benefits that come along with it. This session goes deeper into the practices that each on their own enables Continuous Integration. Learn how to gain fast feedback, increased stability and higher throughput! Show less

Your IT organisation is surrounded by problems preventing it to satisfy market demand on time with the required quality. Where do you start?

The Belgian Federal Pension Service (SFPD) has a large IT department with more than a dozen teams working on the same application. Over the course of a few years, these teams developed an agile way of working at the team level but were struggling to work effectively on a larger scale.

Early 2018, a Scaling course and a LeSS course were organised to help tackle this problem. This inspired an experiment where part of the organisation started to prepare a LeSS flip. It also made it very… Show more

The Belgian Federal Pension Service (SFPD) has a large IT department with more than a dozen teams working on the same application. Over the course of a few years, these teams developed an agile way of working at the team level but were struggling to work effectively on a larger scale.

Early 2018, a Scaling course and a LeSS course were organised to help tackle this problem. This inspired an experiment where part of the organisation started to prepare a LeSS flip. It also made it very clear that there were a few technical obstacles to overcome before any organisational change could be successful.

First thing on the list: getting rid of bi-quarterly major releases, instead of releasing all functionalities in biweekly increments. This was something that had been talked about for a long time, but never really attempted. So a community of practice was kickstarted, with the ambitious goal of finally making this dream a reality in just a few months.

This is the story of the No More Majors community: from its kickstart, through the obstacles they encountered, to the successes and failures they achieved. And also: the surprisingly fast organisational changes they caused! Show less

This is the story of 15 teams and one monolithic application going from bi-annual releases to fortnightly releases in 4 months time achieving a state of Continuous Delivery.

The reason for that move: the cost and time for testing quality into the software product, stabilising and releasing the product during each bi-annual release were skyrocketing.

Continuous Delivery involves a long list of technology and organisational changes that you have to apply to the unique circumstances… Show more

This is the story of 15 teams and one monolithic application going from bi-annual releases to fortnightly releases in 4 months time achieving a state of Continuous Delivery.

The reason for that move: the cost and time for testing quality into the software product, stabilising and releasing the product during each bi-annual release were skyrocketing.

Continuous Delivery involves a long list of technology and organisational changes that you have to apply to the unique circumstances of your organisation. Where do you start?

This is where The Improvement Kata, Value Stream Mapping and Theory of Constraints will help in identifying which change to apply first. However, because of the short time frame, it soon became an example of fear conversations.

After this session, you’ll understand how The Improvement Kata, Value Stream Mapping and Theory of Constraints can kick-start a Continuous Delivery program and mitigate fear.

Folks who should attend are anyone involved near and far in designing, creating, testing, deploying and releasing a software product. Show less

Why is our software industry vastly adopting Feature Branching ? "To isolate the work of the developer so he can be more productive" I was told. But does it really make your team more productive ? Are the projected benefits worth the problems it introduces ?

Feature Branching became mainstream in most IT organisations because proponents of DVCSs mostly rely on Feature Branching to sell DVCS. And probably also because of the success of GitFlow ...
But like all powerful tools, there… Show more

Why is our software industry vastly adopting Feature Branching ? "To isolate the work of the developer so he can be more productive" I was told. But does it really make your team more productive ? Are the projected benefits worth the problems it introduces ?

Feature Branching became mainstream in most IT organisations because proponents of DVCSs mostly rely on Feature Branching to sell DVCS. And probably also because of the success of GitFlow ...
But like all powerful tools, there are many ways you can use DVCSs, and not all of them are good. Feature Branching is definitely not a good way to use them. Although branch creation is easy, this does not mean cheap in the long run. It comes with a certain cost, certainly in the context of Continuous Integration and Continuous Delivery.
Amongst others, one of the biggest problems, is that it breaks the early feedback cycle of Continuous Integration. As long as the Feature Branch is not merged back into main line, the feature is not integrated into the application.

The evilness lies not much in the problems introduced by Feature Branching, but rather in the reasons teams are using them.

During this session we will explore the reasons for using Feature Branches, what is wrong about Feature Branching and what techniques you can use to avoid them all together.

The target audience for this session are software engineers, technical team leaders, architects, and anyone using version control systems in a Continuous Integration and Delivery context. Show less

Some enterprise IT organisations are adopting Continuous Delivery thinking that tooling is enough to do the job, that all of a sudden they will go faster to market and build quality in because they are automating their existing delivery process. Just throwing tools at the problem is not enough; to be successful, organisations also need to adopt the right mindset and establish a culture of fast delivery, fast feedback, and continuous improvement.

To successfully implement Continuous… Show more

Some enterprise IT organisations are adopting Continuous Delivery thinking that tooling is enough to do the job, that all of a sudden they will go faster to market and build quality in because they are automating their existing delivery process. Just throwing tools at the problem is not enough; to be successful, organisations also need to adopt the right mindset and establish a culture of fast delivery, fast feedback, and continuous improvement.

To successfully implement Continuous Delivery an organisation should adopt a mindset focused around 3 topics:

How can we deliver faster with less risks ?
How can we get faster feedback and higher quality ?
How can we continuously improve our software delivery process ?

Using these topics the session outlines some of the principles and practices behind Continuous Delivery that help improve delivery speed and stability.

The target audience for this talk is anyone involved in the software delivery process and managers of IT organisations wanting to adopt Continuous Delivery. Show less

How do you go from a ragtag of people having no idea what it means to be Agile, stuck in eternal maintenance and operational work, applying none of the basic software engineering practices to a team of DevOps delivering value for their customers in sprints of 2 weeks ?

Imagine a very profitable company with hardly no competition that made waterfall an institution.

This is the story of one team within that company. Imagine a team that is not really a team, but a bunch of people… Show more

How do you go from a ragtag of people having no idea what it means to be Agile, stuck in eternal maintenance and operational work, applying none of the basic software engineering practices to a team of DevOps delivering value for their customers in sprints of 2 weeks ?

Imagine a very profitable company with hardly no competition that made waterfall an institution.

This is the story of one team within that company. Imagine a team that is not really a team, but a bunch of people that happened to have the same manager. No-one knew what the other was doing. Each one was managing his application, or worse part of an application. A bunch of technologies was used. Automated tests, version control and process were totally inexistent. Internal customers were trained to wait forever for new functionality or worse received functionality the developer thought was good for them.

I would like to share with you how this team became in 3 years one of the most Agile teams of that company. What were the problems this team encountered and why. Show less

Continuous Delivery brings a lot of value to your organisation. It will allow you to reduce your time to market for new features and bug fixes. It is a significant predictor of company performance.

Continuous Delivery is more than just tooling. It is also a mindset.

During this session we will not talk about how to implement Continuous Delivery. Although you will get a short introduction to it. The session will be more about the mindset you need to have in order to successfully… Show more

Continuous Delivery brings a lot of value to your organisation. It will allow you to reduce your time to market for new features and bug fixes. It is a significant predictor of company performance.

Continuous Delivery is more than just tooling. It is also a mindset.

During this session we will not talk about how to implement Continuous Delivery. Although you will get a short introduction to it. The session will be more about the mindset you need to have in order to successfully implement Continuous Delivery. And it'll highlight some facts … And a fallacy (or two) that exist in the minds of decision makers preventing them to take the leap forward. Show less

Presentation of the XOo°f development framework http://www.xooof.org at the annual ICT awards of Data News.