There are 8 wastes of time and resources that you must avoid at all costs when developing software and web apps. Here we tell you what they are, as well as how to incorporate Lean and Agile to eliminate them and provide successful and efficient solutions.
Lean is a process improvement approach largely derived from Japanese auto manufacturing practices that focuses on the removal of wasteful activities. The overarching goal of Lean is to ensure that any activity during the production process adds value to the product.
In addition, Agile methodology goes hand-in-hand with Lean, as it aims to create software with emphasis on prioritizing customer satisfaction (which works because of the science behind Lean).
When incorporating Lean into your process, you need to maximize your investment in your software development by being as efficient as possible to produce results, validate those results, and then determine the next goal.
Lean identifies 8 types of waste that lead to inefficiencies, but they’re easily translated into the software development world.
Here’s how to remove these wastes from your development process.
Waste #1 - Unnecessary Features
In a traditional waterfall development approach, the requirements team is responsible for identifying all of the required features of the application. Since the requirements team will only have this one chance to identify all of the necessary features, they’ll most likely spend too much time trying to solve all of the problems.
This approach has led to not only inefficiencies in utilization of resources, but also to adding features that no one really needs or wants.
The Standish Group has some very widely accepted reports that 45% of implemented features are “never used” and that another “15%” are “rarely used”. This occurs because in a waterfall methodology, there’s too much speculation as to what the client will want.
What you need is more of an Agile, on-demand approach, which addresses the most needed features first. In Lean terms, this is a pull structure as opposed to waterfall’s push structure.
Waste #2 - Waiting (for requirements, testing, etc.)
The goal for Lean and Agile is to get a working product to the customer as efficiently as possible. The more time waiting for requirements or approval means wasted utilization for members of the development team.
To remove the cost of waiting, split up your development cycles. This allows the development team to perform overlapping efforts – the business owners can identify the next set of features while the development, and QA teams can implement the last requirements.
Breaking big projects into smaller cycles (Sprints) is a major tenet of Agile development.
Waste #3 - Decentralized Development Team
By centralizing your development team to one location, you remove the waste of having to make phone calls, send emails, make conference calls, etc., to work through a problem. While useful, email is not always the most efficient communication tool for trying to work through a problem.
Being able to turn around to the person behind you and get a question answered saves minutes if not hours of productivity.
Waste #4 - Gold Plating
In software development, there is not good enough, good enough, and too good. And yes, there is such a thing as too good.
The focus is to build a product that is as high quality as it is cost effective. Make sure that the quality of the application that you develop is within the range of good enough. This may seem like a bad thing (who strives for good enough?), but you must consider that most software efforts are not really ever done. So, whatever you create today may be discarded tomorrow.
If you overspend your time making a feature TOO perfect (aka Gold Plating), you might be just wasting more time and money on something that will not survive.
Waste #5 - Scope too big for resources/sprint
Too often, people try to identify all of the features an application should have at the outset of the development process. Instead, the goal should be to define a roadmap, which is a very loosely identified set of requirements.
From this roadmap, the requirements should be trimmed down to a list of requirements that the development team can accomplish within a few cycles. If the requirements team spends too much time working on the entire set of requirements, then the development team sits in a wait state.
Additionally, when the scope is too big for the development team, then the scope is too big for the requirements team. By reducing the focus to a small subset of features, the requirements team will usually provide a more accurately defined set of requirements.
Waste #6 - Underutilizing Available Tool Sets or Patterns
In recent years, patterns have developed to identify common problems. These patterns are incredibly useful to remove “unnecessary movement” without trying to recreate the wheel.
An example would be Telerik and Infragistics control libraries as well as code generation tools that assist in manufacturing your data access layer and business objects in the form of CSLA .Net (a software development framework that helps you build a reusable, maintainable object-oriented business layer for your web app). Take advantage of both tool sets.
Waste #7 - Defects
How do you reduce defects? It’s the million-dollar question in software development. Testing is usually the answer.
But the Lean philosophy teaches us that quality is the goal for defect reduction. And therefore, since quality cannot be inspected, we come to the conclusion that quality of code must be built in. You can address this through two means: code reviews and unit testing. This starts with the developer owning responsibility and not relying on a QA person to catch the problem.
QA starts in development, not after the developer thinks it is done and pushes it to QA.
Waste #8 - Unused Employee Creativity
This form of waste is the most prevalent in most waterfall methodologies. It is the identification of this waste that truly validates Agile as a complete solution. In waterfall methodologies, programmers are treated like a unit of work, a cog.
Programmers are given a specification, and are expected to code to that specification. But they are generally not given the context of the specification or how it relates to other features that are being asked of them.
It should be expected that at any time a programmer should be able “stop the line” and ask for clarification if the requirement is incongruent with others, or if there might be a more efficient solution.
In waterfall, this is an expensive activity, because of the overload of project management. In Agile, this is anticipated, expected and encouraged.
