Lean Development Methodology

 If you've decided to read this post then you probably recognize Lean Development Methodology as a development project methodology commonly practiced in IT organizations.  If you already know all about it then you might find this very boring and my feelings won't be hurt if you just skip to another article or go browse Amazon.

Assuming you're mildly interested, I'll tell you what I know about it.  The idea of the Lean Development Methodology is for a team to work feverishly on a project and bring it to market very quickly, often before it's completely finished.  This seems like a no brainer, but there's a little more to it than that.

Lean has a thing called Minimum Viable Product, or MVP.  Basically the idea of an MVP is that the system barely does what it is supposed to do in order to sell it, but not necessarily very well.  The idea if that if a company is producing a software product, then they want to start getting customers to pay for it as soon as possible.  If they can honestly say that it somehow performs the function it was designed for and they can get someone to buy it, then it is an MVP.

An MVP is almost certainly rough around the edges and may have a number of features that are not fully implemented yet.  It may have a ton of menu items that display "Not Yet Implemented" when you select them or maybe the whole system  needs to be restarted every 20 minutes.  It barely performs the function that it is being sold for but very little else.  The idea is that if the company can get customers to pay for it then they can use the money to finance finishing all the other parts that yet don't work and they can solicit feedback from the customers to help determine which features should be developed next.  Also, the theory is that if a customer invests money and time in buying an MVP, then they will be more likely to put up with some amount of deficiency and stick with it in order to protect their investment.

Let's look at an example.  This one doesn't involve developing software, but it illustrates the idea of Lean.  Suppose a company wants to add a rack of new servers to their data center.  There are a lot of things to consider, but let's focus on electrical power here.  A standard data center rack has a capacity of 42U in space for the servers.  This of a "U" as a slot in the rack.  You can fill 42 slots with servers and whatever else you need to put in there, but they all require electrical power and each one will have at least one power plug that needs to be plugged in.  Data center racks have these big surge strip things called Power Distribution Units, or PDUs.  It runs from top to bottom on both sides of the rack and has a bunch of electrical sockets on it.  Most PDUs can actually do much more than that, but we're just concerned about power capacity for this exercise.

Each rack probably has more than one electrical source running to its PDUs and there's a maximum capacity that those circuits will safely support.  Each device you put in the rack uses a chunk of this available capacity and it's really important not to exceed it.  For our example, the Data Center Manager has told us that the power capacity for the rack is 40,000 watts.  

So now we need to figure out how many watts each server consumes to get to how many servers we can safely put in the rack.  Those numbers are readily available from the manufacturers of each piece of equipment.  They are almost always in the products specs on the manufacturer's web site and it takes all of 2 minutes to click around and find them.  This is where we get to the Lean part.

Management, in it's vast collective wisdom, has decided that figuring out the total power requirement and determining how many servers can go in the rack should be a full-blown project rather than a 5 minute task involving adding up the numbers using the calculator built into someone's iPhone.  So next they assign a project manager, a system engineer, and four programmers to accomplish this seemingly monumental task.

After four weeks of meeting diligently on the project to develop a project mission statement, a charter, define deliverables, establish a schedule of status meetings and a reporting hierarchy to keep management informed of the team's progress, the programmers start coding the solution.  Immediately they discover that they have neglected to establish a SharePoint site and Microsoft Teams chat room for the project, so development stops for a couple of weeks and those pressing items are addressed.

The design that the team has chosen consists of a python program that reads an input file containing the wattages of each server, one per line, and adds those amounts together to produce a result.  The result is written as a single line to an output file where the user can go retrieve it.  The input file contains 42 lines, one for each slot in the rack.  If a slot is empty then there must be a zero on the line.  

After some minimal testing, the team decides that it has an MVP and decides to release it.  After a few more weeks it clears the Change Management process and a thorough review by Information Security and is moved onto a production system.  Users are notified that it is ready and where they can find it.

Now here is where the Lean Methodology MVP thing comes into play.  Despite the programmers' best efforts, they have only been able to get their creation to add up the first two numbers listed in the input file.  It simply ignores the rest of the rest of the file.  You might ask "Why did they release it?" and that would be a great question.  They released it because the project's requirements stated that it needed to add up some numbers and that requirement was met since it actually did successfully add the first two numbers.  They had an MVP.  

After a little feedback from the users they came up with a workaround for this obvious deficiency and this was it:

The user was to populate all 42 lines of the input file with either wattages of each device or a zero if the slot was empty.  When the program ran it would add the first two numbers and produce the output file.  The user was to take the result from the output file and copy it to the first line of the input file.  Then they would take the third line of the input file and move it to the second line and run the program again.  They would repeat this process for the fourth line, fifth line, and so forth until they had completed all 42 lines.  A future release of the program would address this issue if funding was approved for more development work, but for now it achieved it's intended purpose using a combination of less than clever coding and a lot of user intervention.  There you have it.  An MVP.

Sounds ridiculous, doesn't it?  Well that's because it is.  Software developed today using Lean often lacks the key features that would make it valuable to the customer.  The thought is to get customers to pay for it by selling them a rough draft of what the product will eventually become.  It's great for startups at first because it starts bringing income into the company sooner.  Using traditional development methodologies a company might have to lay out a year's worth of staff salaries before they ever see a single cent from selling a solid finished product.  By the time the customer realizes that they've been duped the software company is working hard to add the missing features or fix the stuff that doesn't work.  If they can get the customer to stick with them through that process then they will retain paying (but now not-so-trusting) customers and keep generating income.

I got to see this whole process in play when I worked briefly for a restaurant point of sale company.  They had a solid product but it was dated and didn't have the features of newer point of sale systems, so they decided to create a whole new one that kept customer data in the cloud and had a much friendlier color touch screen interface.  Some of the senior engineers figured out what it should look like and produced a mostly non-functional mock-up that the executives could show to our investors in order to get them to fund development of the new system.  The investors liked it and poured money into the company like crazy.

Next came the Lean part.  Some of the senior engineers decided that the mock-up, which was for show only and never intended to actually function, was a good enough starting place and they could get the new POS to market much sooner if they used it as the foundation and just added some features to it.  It was developed for presentation purposes only and consisted of random, half-functional chunks of javascript code cobbled together to run inside the user's Google Chrome browser.  They decided that it would be good enough to use as a foundation for building a new product.

As you can imagine, the developers struggled with this for months.  They discovered the limits of javascript running in a browser and found ways to work around most of them by adding yet another freeware code module or simply putting various point of sale features in their "parking lot" to be considered at some future date.  The final result was a house of cards built on a very shaky foundation.

Those of you who have ever developed anything in javascript probably know that javascript programs in a browser are usually run briefly just once or twice before the user moves along to something else, so efficient memory management / reclamation and variable scoping are not strengths of javascript.  You might also know that restaurant point of sale systems sometimes run for days, weeks, and even months before they are restarted.  You probably see where I'm going with this, but just in case you don't, I'll tell you that javascript programs can become less and less stable the longer you run them.  Javascript is not a good choice as the environment for a restaurant point of sale system.

With this in mind, our programmers forged ahead and developed the new POS in javascript anyway so they could get it to market sooner.  They released the new version in a few months and the reviews from customers were less than stellar.  If you've ever worked in the dining room of a restaurant as a server, bartender, or manager, you know that the ability to split checks is critical to the restaurant's workflow.  Unfortunately, this capability was one of the many "parking lot" items identified early in the development of the POS and it was not available in the initial release.  To make matters worse, the Split Ticket button was displayed, but when the user pressed it they would be presented with a small pop-up message advising them that this feature was not yet implemented.  The workaround that the developers advised was to void the ticket and then ring it in as separate  tickets.  As you can imagine, this was not well-received, especially by restaurants that had already replaced an exiting POS system with this one before noticing this deficiency.

Over the next nine months we lost a lot of customers and it became apparent that developing and selling a system way before it was completely finished was a bad idea.  I was happy the day my phone rang and found my manager and a Human Resources person on the line waiting to tell me that, due to an effort to streamline operations, they had decided to abandon doing business in the territory I covered and I had two weeks to wrap up any unfinished items before my last day of work.  This wasn't unexpected and I was glad to get out gracefully before the whole house of cards finished its inevitable collapse.

So, to sum up the Lean development methodology, it basically consists of building just enough functionality into a product to start getting people to pay you for it and then, once you are generating some sales, go back and finish the development tasks that should have been done in the first place.  As you have probably guessed by now, I'm not a fan.  I think it generates an element of distrust between the customer and the vendor.  Once that trust is lost it takes an extraordinary effort from the vendor to repair it and the relationship will never be as robust and collaborative as if the vendor had never broken that trust in the first place.