Category Archives: Lean

Why Building Software Is Not Like Building A House

Ok, I have had this conversation too many times to count. And depending on the social setting, I have argued it from both directions. (stick with me for a minute….) I truly believe that you can build software like you do construction. It can work. BUT I firmly believe that you should not do that. Not because its hard, but because we have an awesome opportunity with software to build something together with the business and not for the business. And that is the key difference.

Now, if I could build the house the way I build software, it would look something like this. I would put up four walls and a door and have the user come stand in the house. I would then ask “What else do you need?” They would give me feed back like “Its dark in here… maybe some lights?” I would go build the lights and windows, and the rest of their “needs” list and call that their “mvh” minimum viable house. Once I was done with that, I would walk them through the house and say, “Here is your house, move in today.” but I wouldn’t stop there” I would go on to say “now tell me everything you want in order of priority and I will add them one by one until you feel like we are done.” All the while, they can live in the house. Wouldn’t that be cool? Except, you can’t do that with a house. You can’t cheaply and affordably add lighting and windows and extra rooms on to a house after construction is complete. Or change the color of the cabinets or carpet. You can however do that in software.

The conversation always seems to go “you should be able to build software like construction” and the reality is you can. But, for me, the question is “Why would you conform yourself to a process that is restrictive and painful when there is a MUCH better way?” Building software gives us the opportunity to truly create something in a collaborative environment with everyone involved. Yes, you CAN do big up front design and estimation, and contract negotiation, or I can use that same time to build something usable that we can use to get test with actual real paying customers.

The paridime is different. Don’t conform to something just because it “seems” to work in other unrelated fields.

The Elevator Pitch

Could you clearly and concisely explain to someone what the project you are working on does? Not technically, but from a business perspective? Could you, if asked, explain what the main features are and why your project is a good alternative to the status quo? In other words, can you give a business justification for the project?

If you can, fantastic. You are making good strides in setting your project up for success. If you said no however, you are unfortunately in the vast majority of development teams out there. As developers we tend to separate our teams into the “business units” and the “technical” groups. We figure that we can deal with the tech decisions and they can make the business decisions and everyone will be happy. Unfortunately for us, we forget that every decision we make, impacts the business. We are all on the business side of the project. As developers, we make hundreds of small decisions every day and it is very easy for us to get caught up in the tech, and lose sight of what the real purpose of the project is. In my Why are we here post, I talked about the importance of understanding why we are doing a project and to keep the customer in mind as we do it. The next logical step in that process is to formulate a clear and concise explanation of the “why” so we can both keep ourselves focused, but also to aid us as we engage our neighbors. I call this, “The Elevator Pitch”

Now, this concept is not new. If you stepped onto an elevator with someone and you had to explain something to them before you got to your floor, could you? Some elevators are slower than others, and in my building I could read them a 30 page document by the time I hit the 3rd floor, but you get the basic idea… And besides that, you should be taking the stairs anyway… But I digress…

In order to formulate an elevator pitch you need a few important pieces of information. If you are already working, you should have them. However, if you dont, call together the “A Team” (thats a different blog post) and the Product Owner ( Yet another post) and ask these simple questions.

    Who will be using this product?
    What is the basic thing they are trying to accomplish?
    What is the key benefit of this product?
    What is different between the current state and the new state?

Ok, now that you have all of that, you need to put it together in a clear and concise format. This seems to work well for me.

For [Customer]
Who needs to [Need]
The [Product Name]
Is a [Category]
That will [Key Benefit]
Unlike [Primary Alternative]
The new system will [Differentiator]


For The Accounts Payable Team
Who needs to effectively process invoices
the paytastic 1000
is an online payment system
that will allow AP to process invoices quickly and efficiently.
Unlike the current paper based system
The New System will ensure that invoices are not lost and kept in proper workflow.

Now, with that simple explanation, you can clearly explain to anyone what it is you are trying to do and what the most important things are.

Kanban, Writing Code is Like Building a Car

The first step in improving your environment and taking steps to become more agile is understanding what is going on in your pipeline. Many shops today have no concept of where all their various changes are, what state they are in, and when they can expect to get stuff out the door. Dev churns out code as fast as they can and then they lob it over the wall to QA. QA is almost always understaffed and can’t keep up with the mass of code that keeps being flung at them from the developers. When you throw in architecture and user acceptance testing, you can end up with a real logistics issue. The question is, how do you fix it?

Back in the 1940’s Toyota had similar issue with their manufacturing plants. They had inefficiencies all throughout their pipeline but had real trouble sorting them out. They found a solution in an unlikely place, Supermarkets. They began to study the way the supermarket pipeline worked. First, a customer buys items off the shelf, then the items are restocked from the back, then that inventory is ordered from the vendor. It would seem ridiculous for the stock guy to randomly deliver more cans of beans to the front of the store. He only delivers enough to replenish what had been sold.

Toyota applied that same concept to cars. When a certain amount of doors had been put onto cars, a request is put in to build more doors. Those doors are delivered just in time to be used on the next group of cars. This is referred to as “Pulling the demand.” Starting at the end of the process, each step pulls what they need from the process upstream.

All too often in software development, we “Push” instead of pull. We get stuff done as fast as we can and push it up to the next level with no concept of what that means downstream. Our developer stockers keep wheeling out cans of beans to the front of the store, even though there is no room on the shelf for it to sit. We do this, mostly because we don’t understand where our limits are and how to streamline.

This is where the Kanban board comes in. The Kanban board is a way to track all the moving parts in your pipeline. Take a big piece of paper and mark 5 columns on it. Label the columns something like “Architecture”, “Development”, “QA”, “UAT”, and “Deploy”. Take that board and publish it in a public place. Now write down everything that is currently in process. Put each item on a card and stick it up on the board in the proper sections. That exercise alone can be eye opening. In many shops, you will have 4 items in “Development” and 27 items in “QA” or past. In this case, Dev is pushing out code as fast as they can, but nothing is getting done because it gets stuck downstream.

That is the simple beauty of the Kanban board. It gives you a very visual indication of what is going on in your process. It is very simple to see where the bottle necks are and gives you some tools to start fixing that problem.

Now, what do you do with that information? It really depends on where your issues are. Do you stop development and have you developers start automating test plans? That could work. Maybe help out UAT by sitting down with the business partner and doing working sessions. Fix defects proactively instead of waiting for QA to find them. All are reasonable options, but whatever you do, don’t perpetuate the problem. Once you see an area over worked, stop adding to it.