A Concrete Example for Small Increments

[Guest Post: Paul Boos serves as the software maintenance lead for the Environmental Protection Agency’s Office of Pesticide Programs (OPP).  His team currently uses Kanban and Scrum to maintain the OPP legacy code base.  Prior to that he implemented Scrum as the Branch Chief for the National Development Branch within USDA/Rural Development. Follow him on twitter: @paul_boos]

I’ve been a believer in delivering small increments of working product for a long time, but I thought I would put out a warning on how easy it is to let yourself be seduced when you enter areas where others know more.  Before I get to my specific example, ask yourself the following questions:

  • Do I bow to other’s demands that the first time they want to see my (software) product is after it released?  Often customers don’t want to be involved in the development process, do I accommodate them and use proxies?
  • Am I getting advice on my applications from outside consultants?
  • Do I constrain myself in my schedule/plan in such a way that dependencies become tightly coupled and thus many things must occur almost simultaneously?
  • Do I allow myself to focus on optimistic timelines or cost savings if I take a particular course?

We encounter these types of issues constantly and all of them can become traps to taking the wrong path.  I will now provide you a concrete example; quite literally about concrete.

Piet Mondrian 1872-1944

I have a patio project I am working on; my design is sets of concrete rectangular slabs laid out similar to Piet Mondrian’s famous works.  In between the slabs, I am using small-pebbled gray gravel.  A majority of the rectangles would be tinted a simple tan, but a few were intended to be tinted differently, highly reflective of Piet Mondrian’s work.

Given the nice incremental lay out, my original intention was to form the rectangles up and using the mixer I had mix and pour each square one by one.  The hardest thing would be to be consistent with the tints from one rectangle to another, particular with the tan.  Each slab I pour would be a learning experience and I screwed up one, I only have that one to fix (refactor).  Sounds very Agile right?  It is…

My good friend built a huge portion of his home in Florida using poured concrete.  He had been advising me along the way (I had a retaining wall I had to do prior to the patio).  He knew I was sensitive to cost for my project (which was the primary reason I was doing it myself, not because I was a whiz with concrete).  He convinced me by working through the calculations that getting a concrete mixer and a pumper truck would be cheaper and make the job go much faster.  He had used this combination several times when building his house with great success.  He further convinced me that my Mondrian-inspired pattern was enough to look great, I didn’t need the additional colors.  That would allow me to get everything in one pour.  In fact, one truck would take care of the entire patio and I would have enough left to pour under my screened porch so I could use it for storage  What a deal!

A Piet Mondrian Art Design

I booked the truck and pumper when he could be there to help me and got another friend who had helped me on the retaining wall work.  When the pumper arrived, my friend was a bit surprised that there was only one guy; he was further surprised when we had the responsibility of set-up and tear down of his pipe and hoses, and completely caught off guard that we had to manipulate the hose fully ourselves.  He expected that we would have to help, but thought at least two of us would be able to be devoted to spreading the concrete out and doing finishing work.  It got worse from there; the pumper guy (who actually originally had worked in Florida and knew what my friend was talking about) had no idea how many ‘squirts’ of concrete it would take to fill each rectangle, he had to rely on us.  He also wouldn’t allow the mixer guy to add water to keep the mix running smooth for fear of negatively affecting the tint.  Lastly, communication between the mixer guy was very poor; when the mix started getting stiff, the mixer guy didn’t let him know and the last two rectangles that got poured were unworkable.  Because with only one guy running the pumper, we actually were one guy short, so the mix set-up before it could be finished.  One rectangle didn’t get poured and the area under the screen porch didn’t get done either.  A good 1/3 of the mixer didn’t get poured.  Big disaster; I am fixing the mess by grinding down high spots and having a stucco guy create a topping.  At least now I can have my different colors.  It is taking longer and costing more though.

(I also found out later from the concrete company that most people that get tinted concrete get two half trucks as the tint will make the concrete become stiff faster and yes you don’t want to add water as it dilutes the tint.)

I am going to discuss the two other paths I could have taken, but before I do that, let me cover some of the differences in context between my friend’s experience/advice and my project:

  1. This was tinted concrete, my friend had only ever worked with just plain concrete for walls and his slabs in his house.  None of these were the finished product, but really just well-formed rough structure of the house.
  2. He was used to having two guys running the pumper, which allowed smoother communication between the pumper and mixer teams.  Remember also, this put us a man short.
  3. His pumper guys had more experience (from running the actual hose end) of how many ‘squirts’ are required for a specific form.  They can eyeball and know exactly when to shut off.  Our pumper guy had to rely on us eyeballing it.  Even he didn’t have that great of experience doing this per se.
  4. He was used to doing one continuous pour while this was sets of slabs that were separated.

The Evidence for Small Increments

This difference in context made the world of difference in how the project turned out.  This was much more like a software project given the team than a typical concrete pour. The project is now more expensive and taking longer than it would have had I stuck with original of building slabs individually.

The two options I had was using he pumper and mixer as planned, but leaving out the squares I planned to do a different color.  I wouldn’t have faced the mix stiffening up on me (only because it would have been less of a pour; and I only know this in hindsight) and I would have achieved the look I would have wanted.  Though with the crew I ended up with (particularly absent  a pumper guy from my friend’s point of view), I am not confident it would have turned out well.  The project would have taken slightly longer and cost slightly more than the optimistic  estimate of pumping the whole thing.

I could have stuck to my guns and said I wanted to do my slabs myself with my own mixer.  It would have been pour, inspect, adapt to what I learned, and then repeat for the next rectangle.  This is the original Agile approach I was considering.  This would have taken longer, but probably would have given me the original results I wanted and I could have adapted to the changing conditions.

My lesson for you is watch out for being seduced to move away from incremental delivery when it appears the cost or time savings will be there; factor in the risk of failure and what that might mean to these elements.  Check out the full context of the person giving you advice; for this job, I probably would have not thought to check all the elements above as I am not a concrete expert, but it is definitely in my thought process now.  It reinforces why I hate the words ‘best practice’ as it is all about the context.  You can never ask too many questions.

As a side note, the design I had was merely a sketch, the actual formwork loosely followed it and we made adjustments to how it got constructed constantly as it was built. This was done in a true Agile fashion and handled the heavy hoses and people walking on it while we were doing the pour.  Basically, the form work couldn’t have been better. (No BUFD FTW!)

6 Replies to “A Concrete Example for Small Increments”

  1. I think Small Increments makes for big gains. This is because, one can see what is going to work and not work, make changes before too much of an investment is made. I think we really did believe that SWE is like Engineering, i.e. building bridges etc. But SWE is nothing like that. Building in small increments IMHO, is an life safer once you get past the Build all of it to my requirements then let me see it syndrome.

  2. Pingback: Project Management At Work » Blog Archive » Weekly project management news roundup: Agile outside of software development; Agile style teamwork in a non-software environment; Time to get Agile, and other interesting posts
  3. Pingback: Project Management At Work » Blog Archive » Weekly project … – wordpress project management
  4. Pingback: A Concrete Example for Small Increments | Agile | Syngu

Leave a Reply