Lean Principle

FIRST SOME BACKGROUND



This is the first in a series of posts that I mentioned I would be doing in this .The observations for this move towards Lean Software Development are taken from a project where we were rejuvenating an online system. The system had been neglected for a considerable period of time and, prior to this project, we had tried unsuccessfully to replace it with a packaged solution. The organisation is currently moving away from a truly waterfall SDLC with very bloated analysis and design phases and no automation.




WASTE ELIMINATION



Waste is often one of those low hanging fruits. As you have less confidence in the quality of the delivery, more time is added up front for analysis and design. With each failed release, more analysis and design is done as a stop gap.And the result is that you become really good at doing analysis and design. Not delivering software to the client.



This quote by really sums it up for me - "There is nothing so useless as doing efficiently that which should not be done at all".



So what is waste? Bugs are waste. Inefficient use of time is waste. And ultimately anything that does not add value to the client is waste.



To define waste, waste is anything that does not add value to the customer, this includes items such as unnecessary code or functionality, unclear requirements and slow communication or processes.



Below are my observations around how eliminating waste, as a Lean principle, assisted in turning our delivery around.



THE IMPORTANCE OFA CHANGE LEADER



Eric Ries who authored the , notes that organisations have "muscle memory". I have personally experienced this where habit is hard to break and it is just too easy to fall back to the old way of doing things.



I feel it is imperative that when embarking on a journey like this, that someone in the team has the mandate and is empowered to bring about changes. This person should then be constantly reminding the members of the team of the need to change. It might be best to bring in an outsider, or move someone from another team, because the "muscle memory" of the team will keep leading the team back to the well trodden path. Change is not easy and for the first portion of the journey the reminding might need to be more often than not. But as the habits to embrace change form, the reminding will be required less often.



And without someone or something constantly challenging you to change,why should you change?



AUTOMATE, AUTOMATE, AUTOMATE.



When we started we had build server that required multiple clicks to do a build and deployment to an environment. This resulted in someone having to wait for each step to complete before initiating the next step. Waste. Our build and deployment is now a one click affair and is deployed automatically to our test environments in the early morning. This has had a couple of benefits:



* A developer is not required for the deployment.

* Those individuals who are dependent on test environments and who arrive at work early in the morning are immediately productive.

* With a developer not being required for deployments, BA's and testers were now doing the deployment into the QA environments. This allowed for whoever was doing functional testing to pull work whenever they were ready. And developers had one less context switch because they did not have to stop what they were doing to babysit a deployment.



Another area to automate deployments is the database component. This is where the usage of a tool such asassists with automating and versioning your database changes. I wrote about how we have started using Liquibase , and we are still in the process of bedding this down into our environments.



PROXIMITY



Having the team members in close proximity to each other is a must. BA's, testers and developers being able to quickly communicate around the status of changes is invaluable.Rapid feedback eliminates much of the context switching that happens when team members are distributed. I am always astounded at how even a different floor in the same building can affect communication.



It is difficult to put a value to the conversations had over the top of a monitor or simply being able to turn around and have a quick discussion with a colleague.



DOCUMENTATION



At the end of the day, documentation adds very little value to clients. Working software is what counts. That does not mean that there should be no documentation, but rather the documentation should simply be good enough to transfer an understanding.



I believe that documentation should be the lowest fidelity possible to effectively transfer meaning and understanding. Photos of whiteboards, annotated screen print outs or the paper you used to workout a flow are more than adequate. Once coding is complete the code becomes the best form of documentation.



I will caveat this though, if developers, testers and BA's are not working hand in hand and sitting with each other, then I would not advocate this and would rather recommend an alternate method of communicating understanding and requirements.



CLEAN CODE



Our code base is anything but pristine. So to make the smallest change is not only risky, but also consumes far more time than it should. This particular task I don't think will ever be 100% complete, but with each change we make we ensure we clean and refactor the code, and create unit tests allowing us to confidently start making changes. Following principles such asandare guiding us in this journey to deliver better quality code.



DEVELOPER TOOLS



From a developers point of view we all want to be as efficient as possible and this means that our tools need to be the best. A developer should be able to build the entire source code and run the unit tests multiple times an hour. This means the machines we work on must have more than enough processing power and memory. If the developers are working on underpowered machines, they are most likely wasting massive amounts of time a day. Especially if there is an expectation that unit tests are to be run with every build.



FEATURE BRANCHING



I mentioned in another post how we moved from . Prior to this move waste was created every time we created a new branch to start development for a release. Firstly other branches were not getting the benefits of enhancements to our frameworks, secondly massive amounts of time were spent creating and merging branches. Time spent merging code is a real waste of time and effort, and is risky.



By toggling changes, we have the ability to deliver change quicker. Small changes and big change happen side by side, with big changes moving into production in a "OFF" state and not being visible to clients or affecting clients in any way. With this approach it is important to always be committing production quality code, so that you can deploy as and when is needed.



A benefit of this is that if a defect is unfortunately picked up in production, it can be toggled off. Thereby minimising the impact on the client and allowing the developers a grace period to correct the defect.



So I have touched on a few areas where organisations would benefit from moving to a LSD approach. And as I noted in the beginning of this post, this is the first in a series of posts and I will coming back to refine, add to and update my thoughts over time, while adding posts on Lean Software Development.
Full Post