Lean and Agile – Doing more with less

Have you been in a similar situation as the above Dilbert?

Lean and Agile is about doing more with less.  Lean and Agile doesn’t focus primarily on cost reduction, but more on strategic alignment around enterprise agility – reducing waste and simplified processes which then could have an impact on cost reductions.  Furthermore, for comparable cost as traditional (waterfall) methods Lean and Agile can deliver higher quality product and a greater return on investment (ROI) by working on the most important and highest valuable features first – the business gets greater value for less.

Lean Software Development which has been popularised by Mary Poppendieck is derived from Toyota’s Production System.  Basically, lean is centered on adding value with less work.  Lean Software Development (Poppendieck) recognizes the following 7 types of waste:

• Partially done work
• Extra processes
• Extra features
• Task switching
• Waiting
• Motion
• Defects

Some of these wastes can have a large impact on the amount of value you can deliver.  Essentially, by having less of the above wastes we can deliver more.   Partially done work means you have unfinished development and resources are tied up on items that provide no business value.  Business value is only delivered when features are fully completed.  Partially finished features result in hidden costs to projects.  When it’s time to release, you have to complete an unpredictable amount of work.  This destabilises release planning efforts and prevents teams from meeting commitments, often resulting in more work.  Methods like Scrum deliver small increments of fully working software that are usable and tested.  Scrum teams agree on a definition of done to ensure they are delivering features that are truly done, not only in terms of functionality but in terms of quality as well.

One big waste often found in waterfall approaches is doing extra steps and tasks that add no value to the actual process of developing working software.  Doing extra process steps (such as necessary meetings, extra paper work, manual reports) ties up resources which can be better used on value-added tasks and on activities of producing working software.

Extra features or the overproduction of features is often a result of gold plating.  Gold plating as described in Wikipedia:

Gold plating in software engineering refers to continuing to work on a project or task well past the point where the extra effort is worth the value it adds (if any).  After having met the requirements, the developer works on further enhancing the product, thinking the customer would be delighted to see additional or more polished features, rather than what was asked for or expected.  The customer might be disappointed in the results, and the extra effort by the developer might be futile.

On one of my past projects we had an Architect who wanted the team to build a framework for the system to cater for future needs.  This future need may not be realized as things inadvertently change.  The framework is a typical example of YAGNI.  There was no real requirement (technical or business) for the framework and there was a simpler solution which still satisfied the immediate business needs.  The framework added complexity which in return increased maintenance overheads to support it.  Every extra piece of code produced will mean more time is needed to test, integrate, compile and maintain and thus increasing the overall cost of ownership.  The key to avoiding gold plating is to ensure you only build the bare minimal that is necessary to deliver the greatest business value.  If you don’t need it now, don’t build it.  Keeping things simple is one of the Agile Manifesto Principles – Simplicity–the art of maximizing the amount of work not done–is essential.

To help avoid extra features, it is important to identify the minimal marketable features (MMFs).  Minimal marketable features is the smallest set of functionality that must be realised in order for the customer to perceive value.  It is the minimum viable product that has just those features and no more that is fully functional and allows you to ship the product to users so they can start using it.  The goal is to build the features that are the highest priority and has the most business value and avoid building unnecessary extra features that are less useful.  Agile’s approach of iterative and incremental development and focusing on delivering the most valuable business capabilities takes advantage of Pareto’s Principle which says you will get 80% of the business value from 20% of the effort.  This will allow you to deliver more value with less waste.

To complete more work with less time, you should avoid multitasking or task switching.  Every time you switch between tasks, you have to completely shift your thinking and gather your thoughts before you can get into the flow of the new task.  Multitasking can make you lose focus as it takes you a while to get back and remember where you were.  As a result there is a cost each time you change tasks or shift from one project to another.  To complete more work, try single tasking.

Waiting is the result of time delays and idle time (time usually waiting for things to happen and where no value is being added).  This can be waiting on people, analysis paralysis, delays in approvals, long planning times, delays in testing, and delays in integration and deployments.  Lean seeks to optimise the process by reducing the cycle time, which is the time from when an idea is realised to the time it is consumed by the customer.

Agile approaches such as Scrum emphasise the need for cross-functional teams where the team has all the skills it needs to develop and deliver fully working and tested software in each iteration.  The reason for this is to reduce the cost of motion and actions of people that do not add value to producing the product (such as traveling from one location to another to find an answer).  Furthermore, Scrum emphasises the need for a dedicated Product Owner who can guide the team daily from a business perspective.  All team members and customers are often co-located in a team room on Agile projects to reduce the amount of motion needed to find an answer.  Frequent face-to-face verbal communication is also important to reduce the motion of moving artifacts and documents.  Traditionally, hand-offs of documents between analysts to designers to developers to testers is fraught with waste and mis-communication.

Finally, Defects are a huge waste and takes resources away from producing business value (new business capability) to fixing defects.  Instead of fixing defects, Lean principles address this point by focusing on building quality into the process and preventing defects from occurring in the first place.  Agile teams deliver working, tested software every one to four weeks.  They find themselves making more changes to the code, and staying focused on today’s deadlines.  The development team and the code itself must become more Agile, which means it must be capable of faster change, sooner to keep up with business changes.  Agile teams have found in practice that Agile code is extensible, low-defect code with the simplest robust design that will work for the features currently implemented.  It is well-factored and well-protected by unit tests.  Among the Agile methodologies, Extreme Programming (XP) goes into the most depth concerning how developers can keep themselves and their code agile.  Such practices enable the team to do more changes and provide them with a kind of Tai Chi flexibility – a new feature, enhancement, or bug can come at the team from any angle, at any time and teams can make the change with confidence that it won’t compromise on the integrity of the system.

Agile development teams regularly reflect by inspecting and adapting their way of working through retrospectives.  This enables the team to make incremental improvements regularly and tackle changes in manageable, bite-sized pieces that can be actioned immediately.  These retrospectives are important in identifying and eliminating waste in processes which will allow teams to do more valuable work.

In recent times, Kanban systems are being used in software development to limit a team’s work-in-progress to a set capacity and to balance the demand on the team against the throughput of their delivered work.  By doing this we can achieve a sustainable pace of development and flushes out issues that impair performance and it challenges a team to focus on resolving those issues in order to maintain a steady flow of work.

The simple act of limiting work-in-progress with kanban encourages higher quality code and greater performance.  The combination of improved flow and better quality helps to shorten lead times, improve predictability and due-date performance.  [Anderson 01]

Through commitment to Lean and Agile approaches of waste elimination, simplified processes and continuous process improvement teams can deliver in a continuous flow and do more with less.  So next time your pointy-haired boss wants you to do more with less, look into how Lean and Agile can help you.

References

• [Anderson 01] David Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”, 2010, Blue Hole Press.

Image Source: Scott Adams