More proof agile is not just for software delivery

So last week, we decided it would be an excellent time to take things down and replace the holidays for Canada and the U.S. a lot of people were taking a vacation, so the timing was right. Now, unfortunately, the only drawback was the weather. Very sunny and very hot. Another factor that made this a problematic demolition was the proximity to the fence and our neighbor’s cars. Regularly something this small would just need to take out some of the structure then push it over. This structure was strong in some parts and weak in others, so do to something like that could cause damage.

Being agile that I am, we broke this down in parts. Our sprints were a couple of hours at a time. Doing this would allow for breaks from the sun, get some water and food and discuss what happened in the past couple of hours and what we will do in the next. We went over what we could have done better. We found that due to the owner’s construction taking down the walls first (we were intending of pushing it down) was not the right move. We found a lot more sturdy parts in the structure than expected and were worried it would fall in a direction that was not good. So the next round, we put some added bracing in and started to take the roof panels off as they were making the structure very top-heavy and needed to go.

Once they were gone, and the sprint ended, we looked at how to take everything else down. We decided to go section by section from the back to the front. Now, this was the end of the day, so the next morning I would be working on that. The help that I had was unable to come in the following day. One of the other things we found was the bin for the waste was filling up faster than expected. The reason was that although we tried to keep the wood flat and not have a lot of space between them, it was still causing problems. Our solution was to take out some of the wood and cut it up into smaller pieces and any new wood they would be cut up as well. Doing so made it easier to fill in space.

So the following day, I was by myself and began to take section by section. After a couple of sprints, i took a closer look at what was left. I had taken down more than half of the frame. I noticed that if I kept going down the path that I took, the front end would topple over in the other direction because of the weight. I needed to make another plan to get to the result. After some review, I felt that if I took out a couple of the studs, tie a rope to the frame, take off the bracing, and tie a line to the frame, I would be able to pull the structure down, almost like taking a leg away from a table. It would fall in that direction. The weight factor was not there anymore, and the most substantial part of the base a non-factor. As you see in the picture to the right, it fell as planned, and there was no damage done. After a few more sprints of removal, it was time to get ready for the new shed. One sprint to prep the base was structurally sound; it was time to get the new shed up. The following day was building day. With some extra help, it went up without issue. Every couple of hours looking at the directions, and distributing the work, the final product was up and tested (sprayed it with a hose to make sure it wouldn’t leak). See below.

Organizations are starting to see that the agile mindset, initially developed for software development, can be used in a lot of other functions. My demolition project could have had some catastrophic situations if we continued on our initial plan. Being agile is not about being fast, that is a welcomed output; it is about finding value and dealing with risks sooner. It would have been just as easy to knock things over and go from there. Without us attacking it in components, the surprise would have made things too much to handle. I was still able to achieve the value I wanted and was able to finish it faster than planned.