Skip to content

Using Scrum to build a house

November 10, 2010

I have thinking about the Agile method used for building software producst called Scrum.
There has been a lot of promotional material why Scrum is good when it comes to producing software. I was thinking, if this is a very good method for delivering a product in time and with budget, perhaps we can use it to deliver a house, built from scratch? I was wondering, I have some building contractor acquiantances, I might suggest this method of house construction for them.

I few questions came to my mind, while I was toying with this idea. Like, I mean, who will be product owner? Well, it seems, since I want my dream home built, it could be me. What about the Scrum master, who could that be? Say it is the contractor/builder. Now, here comes the interesting bit. In Scrum, there are no roles, all are responsible for a task. I am just wondering, how could a brick layer be responsible for the electric wiring? Or how could the plumber be responsible also for the plastering? These people have not been trained for these crafts.

Then, what about what happens when we list our product backlogs? Do we just decide on the spot, where we put the living room? Or perhaps, first of all, lay down the concrete slab, but we should have pre-decided already where the rooms are going to be apriori, right?

I have a feeling this isn’t going to work.

11 Comments leave one →
  1. November 12, 2010 12:35 pm

    Thanks for the comment but I was being sarcastic when I posted this. It is actually my parody of the hype surrounding scrum as a technique for constructing software.


  2. November 12, 2010 2:32 pm

    I agree you need to appreciate the context in which agile/scrum should be used and the history that made this possible in the first place as a full-fledged development methodology. Agile/Scrum is a direct product of the open source community where there are several iterations of development before any commercial project are engaged if ever.

    For agile/scrum to succeed you need the following:
    1) All libraries are built, tested and in production for at least a year.
    2) Requirements are similar to other completed work with the same code base.
    3) Development team, stake holders, management, testers, UAT .. are the same as pervious projects.
    … if you have all of this then in fact it does work.

    Many businesses today intentionally work on forcing the cost/risk of a project on the development phase of the project, agile/scrum is used to justify their decision so I agree to some degree with your well founded sarcasm. Agile/scrum is a methodology that should only be used by very experienced developers familiar with the problem domain and core technologies/code base. Businesses should always have strategies in place to address budget blow outs and major time delays to market. Finally a key component in agile/scrum that is sometimes over looked or not given the proper respect it merits is “collaboration”. All parties must work very closely and constantly communicate in order to ensure nothing is missed and what is being developed is truly the required product/service. There are many spectacular project failures by brilliant people simply because they could not talk or work with each other. “Collaboration” is fundamental requirement to the this methodology as the key reason why it is the greatest thing since sliced bread is because of the very aggressive time frames a company can deliver a commercial grade product to the client granted at great risk to the business.

    Ozzi Coder

    • November 12, 2010 4:21 pm

      Ozzi Coder,

      You identified the key stuff of Scrum which is collaboration. That key to success is also the key to failure because when personalities clash, that collaboration wagon won’t move. Another thing I saw is that Scrum won’t work when a client has hired a consultant to build him some software. Perhaps within the team of the consultant this might work but the problem is that what if the client wants a closed contract? In this case the requirements must be fixed and the consultant has to work on it. So what then?

      Well, there is a lot of down play on the waterfall method, but this method got its cue from the old engineering practice done by engineers which I think can be traced up to the time Moses was building the pyramids. It worked for the engineers then.


  3. November 12, 2010 5:42 pm


    Absolutely – I agree – all very valid points. At that end of the day nothing is free, the higher the risk the grater the return. Agile/Scrum favours the “brave” – very strong teams, that can comminute effectively, brilliant if not leaders at their respective disciplines and have clearly identified a key strategic gap in a emerging market thus the rush to deliver to market a commercial grade product/service at the fraction of the true cost. One company fresh in my mind (just watched the Social Network movie) that fits this description is Facebook, I’m sure all the great players IBM, Sun, Microsoft, Apple have gone through similar “write the code now ship it dame you, we know what we are doing!” mindset and can get away with it in small strong doses but it all comes at a price as things still need to be revisited at some stage. The correct formal processes need to be put in place as that is the real “asset” a company owns. Now the real question you are asking me is if this should be adopted as a standard development methodology? Absolutely no! but it has it’s place and the risk component should always be heavily emphasised to all concerned as I am sure is not the case in most situations. You will also find like all these fads many use the terminology without truly understanding it as to be up to date with latest idea thus many claim they are using agile/scrum when in fact they are really using a test driven development approach. Even in those environments where agile/scrum is used to develop a product/service at some stage the proper processes, documentation typical of a waterfall methodology will be adopted to some degree in order to safeguard the respective investors in critical areas like intellectual property, risk … etc and is paramount to any due-diligence excercise once a company is nearing an IPO. This brings us to the main reason why many great successful software houses go through a cycle of issuing many shares to all the key players .

    Let me leave you with one old school saying that puts all this into perspective
    “Make hay while the sun shines!”

    Ozzi Coder

    • November 12, 2010 9:42 pm

      Ozzi Coder

      I think there are scenarios where in Scrum is useful but it is hype to sell it as the greatest thing since slice bread and you are ancient if you do not use it. I worked for IBM and it is the most profitable company doing contractual development I worked for. IBM followed a waterfall model and when I was with them, they even went for CMM for that project. It was a very profitable project of 100% return.

      In IT it is all a matter of fad too and acronyms. A bit of fanaticism goes around much.


  4. November 13, 2010 12:33 am


    It’s very difficult to argue this without going into the exact details regarding each methodology but keep in mind the minute you revisit any phase in the SLC the Waterfall methodology has failed. All methodologies adopt the same key SLC phases – requirements, development and testing the main differences is the amount of work conducted in each phase and the relative time spent there getting it right. Key tools like UML, process diagrams, E-R, uses cases … etc should be used irrespective of the methodology adopted to get your product/service to market.

    Key guidelines:
    1) If you can get the requirements right the first time, the business model doesn’t change, you write the code once and get it 100% right, test the application get that 100% right, and finally place the product/service into production, and never require a bug fix or any patch update the business environment never changes since the project started and if it did it is already factored into the solution. We know this never ever will happen and many great books have been written purely dedicated to this one subject.
    2) The second methodology still requires you capture 70-90% of the critical requirements the first time round, time frames are agreed by both business and software solution providers, development of most of the code base (%70-90%) is expected, testing of critical functionality is still required, several iterations between requirements, development and testing (UAT) and then deployment of application/service into production with planned/managed iterations or monthly patch updates. You are now dealing with a test driven approach that is very common in the industry today and used by everyone including IBM.
    3) Finally you are happy capturing most of the requirements (%70-90%), purely dictated by the business on time frames/deliverables like software budgets … etc. don’t have a say in the matter, at least 90% of the code base is already developed in production, minimal testings and less iterations between testing(UAT)/development before software/services are deployed. Bug fixes, patch updates can be anywhere from a few or as many as it takes to get it right if the business survives. (We both agree it’s never sold this way!)

    The critical problem with the Waterfall methodology is the SLC is totally unforgiving, in that each phase is right, it also assumes the nature of the business never changes in the life of the project, design, code, testing all 100% right the first time which is impossible in the real world. With the same token not to document classes, process flows, user interface requirements …. Etc. is a guarantee for failure. In today’s world the clear choice of a sound software development methodology is a test driven approach not Waterfall. I always advice against agile/scrum but you will be very surprised what businesses are happy to write off if it means a chance to acquire more market share or enter a totally new market.

    Ozzi Coder

    • November 13, 2010 9:10 am


      I have indeed seen where the waterfall method went well and in my opinion, it is not the method, it is the management. Any project enterprise or venture that fails is a failure of management. Being a consultant, I have seen waterfall worked to the profit of the consultant and client. It shares equal responsibility. The client is forced to not be ad hoc about his requirements. I am arguing from the external consultant basis. At the end, the consultant is hired not only for his technical know how, but in the end, his ability to deliver. I am happy for the client to change his mind, so long as he pays for it, all is sweet to me. It may be boring but I won’t complain.

      I have witnessed first hand a 100% profitable operation using Waterfall, from a consultant perspective of course. IT has been going on for 50 years now and we cannot keep on repeating the same old same old process failure. It is not really the process because process is good, rather it is the management of the process that really counts. Scrum works for in house development or a consultant with an open contract, i.e. the consultant is hired as an employee, hence, not hired really to deliver his own designed product, Scrum will work in this case. If the consultant is just a warm body, yes, it will work but not if he is clearly hired to deliver a project on a fixed rate basis.

      The hype on Scrum borders on b*ll d*st if You Tube is the gauge. May be I am just old, and life has made me a sceptic.


      On Fri, 2010-11-12 at 13:33 +0000, wrote: > New comment on your post “Using Scrum to build a house” > Author : George Shafik (IP: , > E-mail : > URL : > Whois :

  5. November 13, 2010 6:53 pm


    From what you say we both agree on the processes required, the difference is in the name we actually give it. As far as your well founded response to the mythology “Scrum” generally accepted meaning is found here:

    Areas like budget, profit, good, bad, competent, incompetent, full time, part time, consultants … should not impact the methodology. The clear purpose of a given methodology is to deliver an acceptable product/service to the client. It is critical to avoid generalising purely based on one’s experience each project brings its own surprises, a balanced approach is very important. Software development is not an exact science one needs to be flexible and open minded to change. With each new technology the methods to solve problems changes, this in turn has an influence in dictating what aspects of a given methodology is adopted and what is dropped. A nice hardware analogy to this concept is the way chip makers use both RISC to CSIC architecture depending on the client’s requirements. CSIC is obviously what you refer to as the “Waterfall” methodology however with the ability to revisit requirements, development and testing granted in a very minimal manner the exception not the rule unlike my “Test driven” methodology.

    Finally you place a lot of responsibility on the management; technically you are right however I disagree with your actions. The success of any project reflects directly from the CEO of a company all the way down to the junior developer, I believe this is a very common philosophy shared by the many great companies of which I don’t want to single out here. As we agree management can be very heavy handed in its approach in getting results which is very destructive in areas of creativity, productivity and moral all key ingredients in any great project or company. From the way you write it is clear you speak from many years of experience and familiar with tired and tested traditional software methodologies even though I understand the points you make I don’t entirely agree in adopting them in my projects as at the end of the day there is always that magic “one degree separation” that every great developer or consultant … etc. brings to a project thus “we” are responsible for our project leaders, business analysts, managers, stake holders, investors … etc. Ignorance, as their failure to deliver is ultimately ours.

    Ozzi Coder

    • November 14, 2010 1:05 pm


      When a project fails, it is failure in the end that must be swallowed by management. Stabilising the requirement does not happen in Scrum in fact it allows one to move the post through the updating of the backlog list. The shared responsibility in Scrum is useful concept. I have adopted Xtreme pair programming where I once worked and it worked well for my team and project, that is probably what Agile method I would use within Waterfall. A Scrum evangelist I heard also said that it won’t work for complicated large projects, an admission I admire.

      What is your “Test Driven” methodology?


  6. November 15, 2010 7:42 pm


    Pair programming certainly has its advantages but like all things they still need to be managed properly. Carefully matching areas like communication, skillset, teamwork … etc between the paired developers is very important for a productive outcome. Now as far as what I refer to as “Test Driven” development is actually not that complicated in principle.

    The testing cycle when using a “Test driven” methodology serves two purposes not one:
    1) Usual test (UAT included) for expected functionality as per the deliverable requirements.
    2) Raise issues regarding new functionality in the form of “change” request, “enhancement”, “new functionality” … etc are identified.

    If we accept the fact that requirements will never be 100% then we should factor this change into our design/architecture.

    Business has full flexibility adding, changing functionality very late in the SLC. This ability to change enables the business the maximum time to lock down what it will take to the market.

    If enough core functionality is identified late in the project SLC it can have disastrous impact on the project depending on the chosen architecture. Since this methodology puts a lot of pressure on the development resource it is very important that the key decision makers are very experienced with the clients “problem domain” in order to minimise the exposure to the business by adopting the right architecture with no or little direction from the client. It is very common for a project to be deployed into production with 60%-80% of functionality late by several days,weeks if not months. Keep in mind that the deployed functionality may have not been included in the original scope of the work.

    Ozzi Coder


  1. Using Scrum to build a house « Un poco logico y un poco locoHow To Build A House | How To Build A House

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: