if only they used Agile in construction....


Hey Reader,

One of the topics that I wanted to make a video about is "Can I apply Agile to anything I do?". And I've been thinking about what approach to take with this video. I don't promise I'll actually make it, but I wanted to share some thoughts I had about how Agile can be applied to anything.

The main question we have here - is it applicable in any situation ever?

When I talk to my students, I usually say that Agile is not a universal solution. It has been created with complex work in mind, such as software development. Hence it may not be appropriate to use when it comes to simple work.

I usually give an example of construction where waterfall approach works and probably is a better approach to use.

However, as I look at the foundational Agile values and principles, I don't see why they wouldn't apply... It's like this meme:

And so when we were traveling across the country last week, I realized that Agile can totally be applied to construction. And it probably should be applied anywhere else with enough understanding of the mindset behind it.

And one specific thing that pops into my mind is small batches!

Whenever I read any literature about Agile the concept of small batches just keeps coming back (I'm reading the DevOps Handbook right now, by the way, for an upcoming video).

This one isn't even necessarily something that comes directly from the Agile Manifesto. It's mentioned indirectly by encouraging frequent delivery of value. Which in turn requires delivering small batches and not waiting for a huge chunk of features to be completed before giving something into the customers' hands.

For example, say you decided to bake cookies with a new recipe. Would you immediately say "I'm gonna bake 500 cookies at once" even if I've never tried this recipe before? (let's imagine you have an industrial oven)

I don't know about you, but I wouldn't. I'd prefer to get a batch of 6 cookies first to see if the recipe works and I like it.

When we take a simple example like that, it makes sense. But somehow, I see this simple "rule" being broken all of the time everywhere. Even by me personally. And by most of you too.

So let's get back to construction and why this whole thought process started.

We've been traveling across the country by car. And the amount of construction work happening all at once EVERYWHERE was absilutely incredible! Sections of 50+ kilometers would be blocked for repairs, significantly slowing traffic for months.

I think the most infuriating thing when it comes to this is that when you pass these sections, you see only a handful of places where some kind of work is being done. In a 50 km stretch, we only saw about 5 workers.

If your capacity can only allow you to have 1 km of road being actively worked on at once, why close the other 49 kilometers?

Take the Agile approach to small batches of work: close 1 kilometer, fully complete it, and close the next 1 kilometer.

Ok, maybe just 1 km is too short. That's fine. What batch would make sense to allow more frequent delivery? Delivery in weeks, instead of months.

This reminds me of a metaphor that was provided by Mike Cohn (if I'm not mistaken) about buying eggs. It might have been someone else - if you know who, send me a message.

So the metaphor takes an example of buying eggs for breakfast. Say you have 4 people in the family who eat an omelet every day for breakfast. With the traditional approach to batching, we could get great economies of scale by buying 1000 eggs. I'm sure you can get a crazy discount on an order like this.

But it doesn't make sense. You only have 4 people to feed once a day. If each eats 3 eggs for breakfast, you would have to throw some of what you bought away because it would spoil anyway.

So we can say "Let's create small batches. What would be the smallest batch?"
4 people, 3 eggs per person. So 12 eggs is the smallest batch to have.

But, that would mean that you must go buy more eggs every single day. This doesn't make sense again.

A good question to ask is "What is the most optimal batch size?". In this case, you need to evaluate the economies of scale you may get versus the effort required to get the task done (the task of buying eggs in this case).

So when we go back to the construction example, it would be the same - a good evaluation of the effort required, what smallest batch is possible, what other constraints need to be taken into account, and other factors, can help define the most optimal batch size. Maybe it's 5 km. Maybe it's 10 km. But is it really 50 km? Is it really all roads from the suburbs to the city center?

And at this point, you might be thinking "This totally makes sense. Why would anyone do it any differently?"

I think there is one specific example of something many of us did where we didn't even blink before choosing the biggest batch possible... home renovation.

For whatever reason, when it comes to home renovation many choose the path of "destroy everything first, then build component by component". Where component means one type of work that doesn't give you fully livable space on its own.

For example, removing the old flooring in the whole house, while also removing the paint, and making holes in the walls to change the cable placement. Then only putting in the floors everywhere. Since the walls are still not completed, the space is still not livable.

And that takes months. And everybody living in the house starts to hate being there. Because it's ALWAYS under construction.

A small batch approach in this example would be taking one room at a time and not starting any work on the other rooms before the previous one is completed. Your work-in-progress limit is 1.

And if you are not living in the house because you're waiting for the whole thing to be completed, if you take a small batch approach you could be moving in much sooner!

That's just one example.

I keep thinking about this mindset shift and looking at other things I do in life. Where else am I making the same mistakes? Where else can I apply this simple Agile "rule" to achieve optimal results?

I'm sure there are many ways in which Agile values and principles can be applied to daily life to create more improvement opportunities. And I'll keep looking for them.

Anyway, I hope you got some new insights from this email. Let me know if you find other examples that could benefit from small batching.

Daria Bagina

I help professionals and organizations build awesome teams with the help of Agile and Scrum practices. I provide highly actionable tools and systems that bring you results. Professional Scrum Trainer | Experienced Agile Coach

Read more from Daria Bagina

21-12-2024 Hey Reader, I've got a new video for you. Yes, I sent you an email last week about this topic already since I posted it in a blog post. BUT... I updated the text and included so much more information in it to give you even more actionable steps to take to improve your meetings. And I also have filmed a video for you 🎥. Writing an attendee story One of the things that I added a ton about is the attendee story, or really, how to write a better more useless agenda for your meetings. I...

21-12-2024 Hey Reader, "The are too many meetings is Scrum". Or so many people say. But in reality, whether you use Scrum or not, you probably have too many meetings. There are a few things that you can implement to immediately free up your calendar and focus on what's really important. To help you with that, I wrote up a blog post. In summary, I bring you 5 rules to follow to avoid useless meetings: A meeting can only happen if it has a clear purpose. No preparation means no meeting. The...

21-12-2024 Hey Reader, Today I wanted to talk to you about a topic that has been on my radar for the last several months. And the more I look into it, the more I want to discuss it. Luckily, I got a chance to deep-dive into this topic with Mark Metze during the recording of a podcast episode for Agile Within. The topic is "how much technical knowledge do you need to be a successful Scrum Master (or Agile Leader in general)". I'm sharing a part of that podcast with my answers to Mark's...