Agile Kitchen at In the Pocket: a session about real business agility

Agile Kitchen at In the Pocket: a session about real business agility

Agile Kitchen at In the Pocket: a session about real business agility

On December 6th we took our Agile Kitchen to beautiful Ghent, where we set up shop at the In The Pocket Headquarters for an evening with 2 inspirational speakers who shared many of their interesting insights.

Because we were so enthusiastic about the evening, we are eager to share a short summary of this session.

First off, our very own Kris Philippaerts kicked off the evening by introducing the 2 speakers, Christophe Rosseel and Sander Hoogendoorn. Both of which are very seasoned speakers, with very extensive experience in the field. So this session would definitely go beyond ‘mere’ methods, and very deeply into the daily reality of Agile working.

Christophe Rosseel for the first part of the evening

Christophe Rosseel took the stage for the first half of the session. Christophe, Managing Partner at In the Pocket (ITP), wanted to dig deeper into the question: “What is preventing companies from internalizing business agility?”

First of all he shortly introduced the audience to In The Pocket, a Digital Product Studio which is not your typical consultancy company. They are a service company that places teams instead of people. Their commitment to their customers is that these teams are Agile, stable and efficient. These customers are mostly scale-ups but also larger companies where Agile is ‘something that happens in the basement’. Christophe’s focus at ITP has been mainly on Operations, matching teams to the market.

And this Agile landscape is becoming broader and the term Agile is becoming more and more vague. As an answer to this ITP has defined an own way of working, a growing set of methods with the goal of real Agility (i.e., the ability to adapt in a rapidly changing environment).

Flow

In order to enable Agility, certain circumstances are indispensable and Flow is one of them, flow of the individual, flow of the team, flow of the organization. As Christophe has extensive experience with flow on the team level and is discovering flow on the organization level, he focused on the latter two during his talk.

For flow on the team level, he touched upon subjects like Kanban, Cycle Time, Throughput, Cumulative Flow Diagram and much much more.

Discovering flow on an organizational level can be challenging for companies, Agile in practice can be much more complicated than the theory.

A particular challenge brought up by Christophe is the Resource Utilization Trap that traps many large companies. The ratio between value added time and waiting time is very low and a strategy often used to tackle this is to maximise utilization, to make sure ‘everybody is busy’. But work creates work, the WIP (Work in Progress) rises, cycle times increase and the sensitivity of the system increases.

How to stay clear from the Resource Utilization Trap?

By means of Lean Thinking, Lean management on an organization level. The flow can only be as fast as the narrowest bottleneck allows for work to pass through. There is no point in optimizing non-bottlenecks!

Conway’s Law

Christophe also went deeper into Conway’s law that states that organizations will design systems that copy their communication structure. The output is directly related to the way an organization communicates internally. This principle has a greater influence on your work than you might think!

What does Conway’s law mean for your organization then? First think about the desired process and then think about how the organization needs to be structured to support this: which teams do we need? Stating Jan Bosch’s BAPO: “Business should lead to Architecture should lead to Process should lead to Organization”.

That is the theory, now the practical implementation. How to introduce value stream architecture into the organization?

By means of:

  • Domain driven design
  • Wardley Mapping
  • Team Topologies

Fishbowl session

Christophe concluded his part of this Agile Kitchen session with a Fishbowl session, with 4 chairs on the stage, whoever wanted to share something went to the stage. The purpose of this was to share the experiences of the audience with flow.

We want to share with you some of the many remarks and insights that came from this fishbowl session!

  • Successful change: focus on who is convinced, rather than trying to convince the skeptics, in order to create more ambassadors. Try to have ambassadors in all layers of the organization and appoint a dedicated change manager if possible. In case of smaller companies where a change manager seems to be overkill, focus on ‘What’s in it for me’
  • WIP limits: people need to know that WIP limits are hard and painful in the beginning. Do a simulation when the team is skeptical about WIP limits.
  • Simulate: stimulate people to learn so that they come to the necessary insights themselves, stimulate them to come out of their comfort zone. But only if the team has the necessary mental stretch for it. Take into account the cognitive flow (how much extra is possible at this moment). Stimulate teams to experiment. Even if experiments fail, they are a great learning opportunity. Remender that Agile is a toolbox not a higher purpose.

Sander Hoogendoorn for the second part of the session

Next up was Sander Hoogendoorn for the second part of the evening. Sander has no less than 25 years of experience and still is continuously learning to keep up with the fast changing Agile context. Sander loves to solve large problems and then moving on to the next big challenge, but not before teaching the team or organization how to continuously improve their own process.

Technical debt and technical death

In his current challenge, Sander is confronted with technical debt, a concept on which he enthusiastically elaborates during his talk. He indulged the audience with a story about paying off technical debt.

When the technical debt of an organization becomes so high that the company comes to a standstill, it becomes technical death. And that is often the moment when Sander is called in.

Technical debt is the cost of additional work caused by choosing an easy, short cut solution rather than going for a better approach that would take longer.

According to Ward Cunningham, a bit of technical debt is ok to make quick progress, as long as it’s paid back in time.

However, if technical debt increases, it becomes more expensive to develop features. This extra cost will eventually consume all your resources, putting innovation to a complete standstill.

Technical dept on the rise = stagnation = no more innovation = end of story

What is the cause of the biggest technical debt problems?

Dependencies! A proliferation of systems, misuse of systems, … it makes releasing impossible. The cause of dependencies lies in the organization (and its culture) itself and Sander also referred to Conway’s law in this context: business processes are malfunctioning (everything goes through systems, people do not talk to each other), there is hardly any automation of the core business, …

How to get rid of technical debt?

Unfortunately, there is no one size fits all solution. It will be trial and error and organizations will need to take it one step at a time, taking away some of the technical debt with each small step and setting priorities.

There is however 1 underlying guideline to take into consideration: everything needs to be smaller and shorter.

Sander gave some very practical examples, insights and tips on how he worked with iBood on their technical debt problem.

Microteams and collectives at iBood

A number of team members working on a specific piece of work until that piece is finished, from a microteam, whereas a collective is the bigger team, a group of people that are responsible together for a value stream.  Sander explained that software development is so complex that many different skills are needed, each task requires a specific set of skills (not people!). A collective should contain all those necessary skills! If you want to learn, you should join a microteam that tackles a problem in the area you want to develop yourself in further. But this will only work well if people get on very well.

The recipe for microteam work:

Pick work => Form the microteam => Discuss => Do the work => Report as done => Disband team => Repeat

Sander ended his session with some final thoughts to his audience to take with them:

  • Agility is not a process, but the opportunity to create your own process
  • Optimization of your process is a continuous journey
  • Small steps are the fastest way forward
  • Solve 1 small problem every day
  • You can’t read the next chapter if you keep re-reading chapter 1
  • It takes 1 person to ignite a change (you)
  • Never stop learning
  • Never forget to have fun

Conclusion

And we put those last thoughts of never stop learning and never forget to have fun to practice. That is why we will definitely set up shop at various locations with our future Agile Kitchen sessions again. Because taking our Agile Kitchen on the road in different locations in cooperation with different companies has proven to be very enriching for our sessions.

As it was such a rich evening, filled with countless insights, we’ve only given a short summary of this session!

But are you eager for more? Have a look at the Agile Kitchen calendar, we can’t wait to welcome you to one of our next sessions!

Do you want to know more about their endeavors? Have a look at Christophe Rosseels’ and Sander Hoogendoorn’s social pages to learn more!

See you there!

Menu Close