Have you heard the joke “What do you get when you build a house the Agile way?
A pile of rubble.
Why? Because you start with the most important thing first, the roof. Then you need to figure out how to get the walls up…”

This was told to me a few weeks ago by a sceptical colleague.

Well, a couple of weeks after that, I watched Mary Poppendieck’s “The Tyranny Of The Plan“. A transcript can be found here.

In this video, she talks about how todays planning is the wrong way to do things. Why? because things change. So your plan will have to change.

Anyway, during the talk, one of her examples was the Empire State building.

This building, built in the early 1930’s remained the tallest building in the world for 42 years.

Contracts were signed for the block in September 1929.  At the time, there was no building plan. They just knew that the building was going to be over 80 stories tall.

It was designed in 2 weeks by William F Lamb of Shreve, Lamb Harmon. The building was designed based on the constraints of the site. Not the other way around where a building is designed and a site found to accommodate. Everyone was involved in the design. Material suppliers, fabricators and sub contractors.

Excavation of the site started January 22 1930 where it was cleared and construction started St Patricks day, March 17 1930.

Construction started at a phenomenal pace. The workers were building 4 and a half floors per week at its peak! This was a city construction site, so nothing could be stored. Trucks would pull up with the required materials be it a part of the steel frame or other. These pieces would be taken off the truck and placed into position there and then. At its peak, there was over 500 trucks per day feeding the site. This takes high precision. Remember, this was 1930 – no computers.   This is flow at its finest. To do this, detailed planning wasn’t done up front. It would have been done for the weeks work based on the progress made to date and changed accordingly.

8 months later, November 13th 1930, the exterior of the Empire State building was complete. That’s right, it was pretty much built in 8 months! The interior was completed on April 11th 1931 – 12 days ahead of schedule. 1 Year and 45 days later, and opened on the 1st of May as this is when New York starts it’s leases.

These workers had a problem solving attitude. Every day over time, would cost the builders $10,000 1930’s dollars. So, whatever could be done to do something sooner, it was generally employed because it was cheaper than going overtime. For example, a miniature train like track system was built in the interior to save time carting materials from one end of the building to another.

No other building since has matched this rate of construction.

This to me seems to be Lean and Agile at its best in the construction industry.  Even better is that this was standard practice for the time.

So what happened? Well, WWII. All these techniques were lost and only now are we starting to re-learn them.

So, getting back to the original joke. “What do you get when you build a house the Agile way?” well… The Empire State Building!

Scrum is like the foundation to a house. Remove some of the components and the house is compromised.

In Australia, we tend to build houses on a concrete slab. So, for example, if you don’t do something outlined in scrum, such as stopping g the daily standups, reviews, retrospectives, product owner dictates work to be done, quality is compromised etc, then it is not unlike leaving,out the rebar in the concrete slab.

You can still build the house on top of the slab. The house may even hold, but the chances of the house toppling over are increased significantly.

The same with scrum. You take away one of the few components, without knowing full well what you are doing and the consequences, you run the risk of your scrum implementation failing. You may be lucky in that it will not fail, but why lay on luck.

As a side note, it could be considered that other types of housing foundations, such as pillars that keep the house off e ground, are analogous to other agile methodologies such as Kanban.

As I mentioned in a previous blog post, I have next to no experience with Agile, but I have gone through the Certified Scrum Master course (at my own expense) and I have read quite a number of books, not specifically on Agile, but on lean in manufacturing and the Toyota Production System.

Since I have next to no experience, but a willingness to learn on my own, I have an idolized view of how Agile should work. This may be a good thing as my view isn’t disillusioned from a failed Agile implementation, nor have have I had Agile forced on me so I’m not trying to fight it.

I’m currently reading “Lean Thinking” by Womack and Jones and one of the common themes in implementing Lean is that it is hard. Very hard. Everything is against the implementation. Processes are challenged and broken, ways of doing things a completely changed. Problems within the manufacturing process are brought to light. It is the same thing with Agile and I think that is what is missed when companies decide to “go agile”. There is a period of time where productivity goes down, things slow down. Especially if you do not have a guide to get you through the process. This I am guessing is because people hold on to the old ways of doing things. Habits are hard to break. Problems are uncovered that were previously hidden and management doesn’t like it.  Basically, lean and agile are easy to fail at. 

At this point, it looks like Agile is a failure. My thoughts are, that if you do not fight through this period by addressing the problems that caused the failures and just give up or change the process to make it “easier”, then in the long run,you don’t get the full benefits. 

In other words, you need to get through Hell before you can get to heaven.

Also, if you think, being experienced programmers, you should be able to do better…

As I’m writing this, I’m watching Hell’s Kitchen. Here, you have a effectively a game show where chefs compete for a job with Gordon Ramsey and lead one of his restaurants.

These are experienced chefs (mostly) who are put through a high intense period over regular intervals. Not unlike a sprint in scrum. These are experienced chefs put under a situation they are not use to, and they initially fail. And they fail regularly. Quality is not there..they make a mess of themselves. Not unlike a first few agile implementations. Those that survive the process, get better. They learn. Those that don’t learn, don’t get better and are given their marching orders. 

At the end of the process, the chefs are much better, both skills wise and personally. 

This, I think is not unlike going agile. 

IT was only a few posts ago that I was saying that if you increase the scope, decrease the schedule or keep it fixed and then keep the resources and budget the same, quality suffers. Well, after taking my CSM course and learning a bit more, I don’t think that this can be always the case. It may be at first, but if you regularly learn from the experience, as you should be doing during retrospectives (that’s if you do retrospectives which I think are a great idea) then you should be getting better every iteration. You should be trying to improve every time, doing something different. Try to automate, try to determine what is important, improve the value stream and I think speed doesn’t become a problem.

I have the following analogy. Say you have a craftsman working on a sculpture. It can take months to finish. If you get them to hurry, say, do the sculpture in 3 days, the sculpture would get a lot more messy. But if you take the same sculpture, 3D render it, then put it through a 3D printer, then potentially you could make the same sculpture in a day. With the same or even better quality than a craftsman with months of work. Another analogy is a racing car driver. They may start with bad times around the track, but with every race, they learn more. How to handle the car better. Get a better car. Get more experience, get more practice and eventually with any luck start wining races.

In my ignorant opinion, the same can be said with Agile projects. The more practice you get, the better tools you get such as automated testing, automated deployment. Start cutting down your documentation to the bare essentials, or even change the way you do your documentation. The faster you can get. The only problem is the lead time and the willingness to keep trying to improve. Saying that, in the short term though, I still stand by my previous post.

My 4yo son loves the Magic Scool Bus tv show and books. There is once character, the teacher Miss Frizzle who has a great saying.

Take chances, get messy, make mistakes.

To me, that sums up the whole learning process.  I think corporate culture needs to learn a thing or two from Miss Frizzle and get away from the whole “mistakes are bad” mentality.  You never learn anything if you don’t try.

If you make the tools easy to use, the process easy to follow and it helps get things done, then people will follow the process, they will use the tools and so you have a defacto standard. You have a standard that actually helps promote work and productivity.

Even if the tool is slow and unresponsive, provided it helps get things done, people will accept it. I have had this happen first hand with my WebMethods tools that I developed for the company I work for. The tool takes a few minutes to do anything (yes I know I need to optimize, but I don’t have the time – and I was taken off the product so that other team members can can know e source code), but it is hailed by my team for the simple reason that it can save hours of work even in its crippled state.

On the other hand, if you have a process designed to slow things down. Has long lead times. Tools that are difficult to use and basically hinders productivity and feedback, then you will find people complaining about the tool or the process. People start to get disgruntled. You have to force the standard and overall you will end up with a compliant workforce rather than a productive workforce.

In our news, I went and took a certified scrum master course and I am now certified. With my interest in DevOps, Lean etc, and given my experience in my first Agile project recently, it seemed like someone to do. I just hope that I can use my new found knowledge sooner rather than much later.

It’s been a couple of weeks since my last post. I’ve been finishing up a project which has m ant a few days of long hours and I have also gotten myself quite sick during the process which leads to this post. 
In this project, I was the only resource for the particular technology stack used for the integration layer. This meant,by hat despite being quite sick, I still had to work. This resulted in me getting much worse. 
So, my advice is always have someone with you, even part time so that they are across the project, but also too so they can take over from you when you need time off. I.e. When you are extremely ill. 

 I’m currently at the tail end of my first agile project (specifically scrum) and it has been an interesting experience. It’s had its problems, one being that it has been incredibly fast.  A total of 4 x 2 week sprints. The scope has done nothing but grow and we have been committed to complete the whole scope. My company is generally a waterfall company, so when something like agile comes along, any problems with the project are pointed to the agile process. I think that this isn’t the case, I have seen similar situations in my career under waterfall.

I’m reminded of a video I watched of Uncle Bob (Robert C. Martin) give.

Basically you have 4 dials on any project you can play with. If any one or more of them are out of whack, they start to affect the other dials.

For example, increase the scope. Keep the budget fixed or keep the same number of resources and keep the same schedule, the quality of work is going to be compromised. If you want to keep the quality, then something else has got to give. You may need to increase the schedule. Alternatively, decrease the scope, or get more resources to do the implementation or a combination. 

I don’t thing that there is any way around this. Compromises will always need to be made. Just don’t blame the process or methodology because it’s new. 

As for those who think that it is Agiles fault, agile has been around officially for around 15+ years. Since at least the manifesto was first written in 2001. If it didn’t have some traction, it would not have survived this long. If your agile project fails, try to understand why.  You may just find that you are implementing it wrong. Similarly with Waterfall. My guess is, if a project fails, two or more of the dials have been cranked up too high causing a blow out of the other dials. 

A few years ago, my team started doing Knowledge sharing sessions. We would get together for an hour and a member of the team would share something. It didn’t have to be related to work. It could be anything. Anyway, one team member did one on psychology testing. I can’t remember he details of what the test was, but I remember a few things about the results of the team. The first was that the individual that brought up the test was leaning towards the practical side. I remember him saying that for him to consider something new, you had to show him proof that it was a benefit. The second was that most all of my team scored similarly, except for one person. Me. I scored more on the creative side. I’m more willing to try new ideas, and find creative ways to do things.

I feel that this might explain why I’m more inclined to accept and try different ways of doing things an my colleagues at the time. It may also explain why it’s hard for some people to change their ways and accept lean principles even if it stares them in the face.

I also think, that with Taylorist type management where conformance reigns, that this mindset tends to be rewarded and those that do not conform, are either told to conform, or are controlled to the point that they conform anyway or worse of all, considered trouble makers and punished.

Although I have never worked for a Lean style organization, I would like to think that the more creative types are given a chance to shine and those that are more prone to be cautious are given a chance to let out their creative side.

If anyone out there reading this works for a lean organization, are you able to confirm my thoughts? If so, please let me know in the comments below.

I was reading my son the Berenstain Bears, The Bear Scouts the other night and at one point in the book, the father bear decides to take the short way to the scout camp, where as the bear scouts decide to follow their scout guide and take the long way. The father bear very quickly runs into alligators and almost gets bitten. It got me thinking that with Agile, DevOps, basically every modern methodology that I have come across, we always try to do it the short way. We try to find the shortcut. We try to do things without fully understanding, just enough to get us into trouble. Sometimes we get somewhere, but usually in the long run taking the short way comes and bites us.

I feel that if it matters, that only by doing the hard work, can you get the full benefit. Shortcuts get you incremental benefits at best, but without understanding.