Lean Software Development
The term “lean” is always welcome in any sort of production, and infers lightweight processes, low overhead, and quick turnaround. The principles of lean development have their origins in the Japanese auto manufacturing manufacturing industry. There are two primary takeaways, the first being that as waste is eliminated, whether in terms of inefficient processes, lost time, and vicariously, cost, the quality and volume of production will increase. This can be applied to the tools, techniques, and resources utilized in any workplace, from washing dishes to high capacity factories. It’s rather intuitive to assume that trimming cruft as it comes to light and focusing mainly on aspects of a process that advance the result will help to streamline the process and also allow time for refinement of the product itself. The second lesson is in regard to smoothing the overall process taken to reach the goal, which by no coincidence is one of the core tenets of agile software development, as it also draws inspiration from Japanese manufacturing. Specifically, smaller product iterations, closer team communication, and more continuous planning.
Further, waste typically refers to three things. The first is excess or unnecessary effort that adds little or no value to the result, whether due to legacy workflows that grow out of date as the state of the craft progresses, or struggling with materials or tools that require particular treatment by nature which could be alleviated via refocusing on engineering. Segue into the second, which is an overload on employees. Many times skilled technicians are aware of this and may complain of slowdowns or the availability of better, more efficient methods a business should be taking advantage of because they’re the ones in the trenches and see it first hand. These instances should be taken note of, as they may benefit both employer and worker alike, smoothing the experience for all involved, up to and including the end customer. The third therefore is unevenness, and not only concerns internal processes but lower level aspects such as materials, assembly, departmental duties, or interaction with management, quality control, and customer support. As to how each aspect of waste is defined, feedback and instruction should be sought from the lowest qualified level possible, in other words from the people closest to the work being done.
Some instances of waste include outright spec work with no clear roadmap, bloatware features that may look nice or add some kind of decoration but are not central to the main goal of the project, or bugs and defects that could have been circumvented through better planning or elimination of “feature creep” as above. Superfluous tasks, switching frequently between tasks, literal wasted time between steps as a result of poor planning and timing, and archaic management practices are frequently a factor as well. Additionally, overcomplexity, under-training, miscommunication, and poor aim on the whole may contribute to losses.
It’s one thing to be aware that such inefficiencies may and probably do exist in a system, but another to identify and expose them so that they can be addressed. Once technique to obviate these bottlenecks is called value stream mapping. In its simplest form, steps of a process are arranged on a flowchart or similar diagram according to their advancement potential. On one axis, say to the right, itemizes steps that lead smoothly to the next are sequenced one after the other. On the other axis are steps that may be necessary to the current process but are identified as tedious, inefficient, and or legacy. The map need not be absolutely detailed or correct at first, what matters is that pieces are evaluated as added and positioned accordingly such that waste identifies itself. When there’s a stack of sub-processes that hold things up from progressing to the right, waste becomes clear. Value stream mapping not only serves as a tool for trimming and simplifying, but also visually shows the way to transform those deficiencies into solutions that improve product value, speed, and satisfaction.
Another important factor in arguably any industry or culture, though particularly software engineering, is the encouragement and fostering of learning insofar as the resultant ability of developers to master concepts and produce code that does not only adhere to requirements or standards, but is smart, efficient, and well suited to the task at hand. Online learning resources, peer to peer instruction, intra-company challenges, and developer conferences geared at staying current with rapidly changing standards and best practices are all invaluable avenues. Agile development in general tends to champion the assignment of adept, driven team members to lead roles in which they’re free to learn, grow, and instruct as is fit to the circumstance so that their knowledge and experience may be shared and incorporated into the next vector. Shorter iterations add to this by allowing those tasked with a specific problem to explore it fully and completely grasp all possible solutions and select the appropriate one.
There are many complementary skills in what is often termed amplified learning. These include concepts such as egoless correction, wherein it is acknowledged that there may be many solutions to a given problem, and while developers are encouraged to “own” their part of a project in terms of responsibility and success, others may provide unique insight and more elegant solutions to it, sometimes even in spite or because of their distance from it, which should be evaluated in the absence of pride or prejudice in the interest of the objective.
Deliberacy of thinking when approaching a problem is of value as well, made possible largely by agile methodology. If people have some time to consider a theory and work out details without overbearing pressure, their solution will end up being much more articulate, well balanced, and maintainable than a “hack” contrived off the cuff in response to a deadline. Peer review and brainstorming sessions when one team member is stuck behind a hurdle have many effects, including illuminating possibilities they might not have seen, boosting their morale in times of perceived isolation and desperation, and making others aware of the problem in future endeavors so that it is solved more quickly the next time around.
While sidetracking is generally discouraged in the interest of trimming waste, it may be advantageous to encourage developers to proof out conceptually branched ideas, or to foster pet projects related to the bigger picture where time and resources allow. Indeed one may find this is very commonplace in larger houses that have solid agile strategies and can afford to keep long leashes within their scope.
An excellent example of side project success was created in 2004 by Google junior software engineer Kevin Gibbs, fairly new to the company at the time. He leveraged a technology called XMLHttpRequest, which surprisingly was incorporated into major browsers but hadn’t seen mainstream exposure for what it was, to fetch additional data as a user was searching contacts in an address book, showing real time suggestions based on what they had partially typed in after a small delay. Upon circulating the idea with coworkers, and seeing as how Google’s primary product at the time was a search engine, one proposed to him, “what if you did it for search?” The result was so functional, intuitive, and such a resounding success, that it was rolled into the product as “Google Suggest”. The notion of autocomplete or “type ahead” is so ubiquitous in all forms of applications these days that most people take it for granted and might feel lost if it were suddenly absent. In this case a small, non-time consuming proof-of-concept quickly and organically developed into a robust and indispensable yet nearly invisible feature that shaped web application design through the next decade.
Likewise, in a lean environment, a tendency of developers is to say “that’s good enough, it works”, however quality should never be undervalued. Consciousness of quality and best practices often saves countless hours of debugging, headaches, and loopbacks through quality assurance or customer support. Taking the time now to deliver an honestly complete feature that works correctly and intuitively the first time can be the difference between a successful product and one that requires constant revisiting, maintenance, and ongoing tension with the client. In other words, it may be more “lean” to a project manager that a feature be completed and shipped without spending more time than is absolutely necessary in their eyes, though in reality it may be much more lean in the end to take a little extra time to iron it out. Everyone likes a developer who can crank out a fix in a half an hour with a wink, but if the same issue crops up every week it’s no longer a trivial thing. All involved need to be aware of these situations, which is why communication once again is fundamental. As a bonus, once a feature is perfected, it becomes canon for the team, augmenting their bag of software tricks.
All of the above points are nuanced and require great care to allow flexibility while at the same time not straying too far toward the extremes of oversimplification and over-strictness, or the other way toward unbridled exploration or even obliviousness of procedures that go on. One should note as well that agile and lean cooperate well, however are not one in the same nor mutually exclusive. For further reading, you may be interested in Agile Vs. Lean: Yeah Yeah, What’s the Difference? for a look at how they differ and how lean development meshes with agile environments.
