Eliminating Waste in Software Development
By Team Arrk |
|
6 mins read |
The increasing acceptance and implementation of Lean principles by software companies is becoming a phenomenon. Whether these principles are introduced as values, guidelines or via the book, it can make a significant impact to individuals, teams and organisations. We are hearing (as well as being involved in) more and more examples of Lean implementation, often under Lean Transformation Programmes.
Lean however does come with its own set of challenges and complications. Companies that find it difficult to imbibe and transform with Lean, more often than not overlook or fail to embrace the following:
- Lean isn’t just a set of tools or a change program that can run its course over a short period; it takes considerable time for organisations to change and evolve
- Lean is a change in thinking which doesn’t apply only to specific departments or functions, but even the upper echelons of management and the organization as a whole
- ‘Respect for People’ a significant yet complex aspect of lean is mostly overlooked leading to disrupted implementations
Many texts exist on Lean and its implementation across various industries, which do re-iterate the value of Lean Transformation. Once organisations embrace Lean as a philosophy or way of thinking its many benefits can be realised.
One of the key benefits is the identification of value generation stream and eliminating the non-value adding activities termed as ‘Waste’, to improve quality, speed, efficiency and productivity. ‘Waste’ is any process or activity that doesn’t add value, with value measured and defined by customer needs. For efficiency sake, we need to identify waste (i.e. inefficiencies, variations, deviations and any other non-value adding activities) in the processes and people practices followed in software development.
This blog is an attempt to put various activities in software development under the lens of ‘waste’ and identify some activities that can prove detrimental to the end result of fulfilling customer needs. Before we do, it is pertinent to briefly understand the seven wastes of software development1so that these can be seen, understood and eliminated.
- Partially Done Work | Until the software is actually used by the user, it is likely not satisfactory/ incomplete/ failure-prone/likely to be rejected or become obsolete/…
- Extra Processes | Examples being more paperwork/too much detail within requirements etc.
- Extra Features | gold-plating, more code than necessary typically adding complexity or requiring more maintenance, inject bugs etc. [1]
- Task Switching | includes non-sequential work or work multi-tasking/hand-offs between team members.
- Waiting | includes delays of any kind (e.g. in staffing, start of testing, getting approvals) that impedes the value delivery to the customer
- Motion | e.g. non-availability of stakeholders, distributed teams, artefacts sent for review
- Defects | not finding defects early enough of any severity or impact is a waste
[1] Adapted for software development by Mary & Tom Poppendieck
Pre-Sales
This is a critical activity for any company and one that “brings in the money”, ensuring sustenance and continuity of operations. Contract bidding, price negotiation and navigating politics are vital to be successful. Efficiency can only be derived and improved through the tasks performed by individuals that enable companies to make that final bid. Listed below are probable wastes that are generated and how we may eliminate them.
| Example of Waste | How to Eliminate |
|---|---|
| Excessive documentation (Extra Processes) | Ensure regular communication with customer, regular grooming of user stories |
| Same-role multiple reviews (Task Switching/Waiting) | Knowledge sharing; proper roles and responsibilities |
| Lack of team work, time lag for communication and limited information (Waiting) | Team workshops |
| Estimation not done scientifically due to poor analysis/information gathering (Partially Done Work) | Knowledge sharing; joint estimation and story sizing with customer |
| Relevant stakeholders not tapped for eliciting needs/requirements i.e. poor stakeholder management (Motion) | Proper stakeholder analysis (via RACI matrix/The Power/Influence v Interest Grid) |
An argument can be made by sticklers that aspects like requirements study, analysis and research for projects that the company incurs but doesn’t bid for, is a waste. From a Lean perspective however this is ‘useful waste’ (provided it is indeed used) which won’t add immediate value to the particular task per se but will help build and consolidate the domain knowledge.
Analysis and Design
The typical outcomes generated as part of this activity are plotting user journeys, persona development, digital simulations and lo-fi prototypes, architectural designs. Typical waste can include:
| Example of Waste | How to Eliminate |
|---|---|
| Lack of collaboration during analysis (Partially Done Work) | Scheduled catch-ups with customer/PO to discuss value generation in delivery as part of backlog grooming |
| Wrong choice of technology or solution (Defects) | Technical spikes |
| Dependency on a single source (Waiting) | Regular knowledge sharing sessions; team centric approach and development |
The skill sets critical here are decisive thinking, foresight and thought collaboration. Value addition cannot only be attributed to current project implementation, as certain tasks performed during this activity might be beneficial in the long run.
Requirements Management
This activity involves the discovery, eliciting and documentation of business needs (via specs, epics, user stories etc.) that are required to be addressed in the probable solution. This is an area that can be prone to waste. In Lean software development projects, the principle is to define just enough detail to stories just in time for development to begin. Examples of waste in this activity include:
| Example of Waste | How to Eliminate |
|---|---|
| Documentation that is too detailed (Extra Processes) | Collaboration with team/customer; deliver working software regularly |
| Switching meeting rooms/re-scheduling sessions (Motion) | Plan better! |
| Missed or misunderstood requirements (Defects) | Regular knowledge sharing; automated testing (e.g. BDD/ATDD) |
| Lack of appropriate and skilled resources (Extra Processes) | Better ways of working; cross-functional team |
| Delay in feedback and approval (Waiting) | Ensure regular communication with customer |
Development and Testing
Although Development and Testing have traditionally been two distinct activities, in Lean software development, the two work extremely closely together and so the non-value adding tasks arising out of the two are listed together. Both involve a level of standardization, innovation and critical thinking to deliver optimal solutions. Common wastes include:
| Example of Waste | How to Eliminate |
|---|---|
| Lack of domain knowledge, inadequate impact analysis, and ineffective test strategy (Partially Done Work) | Regular customer/SME involvement, user workshops, adequate documentation |
| Refactoring due to missed requirements (Defects) | Regular impact analysis, ensure trace-ability, ensure customer involvement in demos |
| Technical complexity not analyzed properly during spring planning (Partially Done Work) | Ensure a technical spike before estimation |
| Lack of transparency (Partially Work Done) | Regular communication to team; effective usage of task board, team wiki |
| Assumptions/clarifications and impediments (Waiting) | Raise red flag before moving into danger zone ensuring guidance from stakeholders, track impediments effectively |
| Lack of ground-level analysis of the tasks required for the stories (Task Switching) | Ensure judicious splitting of stories into tasks and its ordering |
Pre-requisites need to be created and adhered to, before individuals begin their tasks. Pre-requisites can be in terms of defining standard coding or testing practices, impact analysis during grooming/planning ceremonies, determining integration planning & coverage, and resolving queries before they impact the work just before it needs to happen.
Recap | How to eliminate waste in software engineering
- Define ways of working and create standards | Set clear standards for the team to be followed (e.g. via Definition of Ready, Definition of Done, Social Contracts, Checklists, Code quality benchmarks) to determine when the task can be deemed complete. This will help maintain the balance between over-work and the right amount of work needed to get the job done.
- Defining specific roles and responsibilities | These go a long way in clarifying, reducing overlap and over-processing for many of the tasks. This ensures that there is no compromise in the flow.
- Strategizing based on long term vision | Designing and developing solutions with an eye for future help in reducing the re-work and refactoring that might be needed later. Ensuring Release planning based on Minimum Viable Product via key stakeholder(s) involvement
- Maintain focus on present deliverable | ‘Eye for future’ and ‘focus on present’ is a duality conundrum. Being aware of the lean principle that states ‘Decide as late as possible’ works best. For example, one doesn’t need to test on environments to check handling user load of 100,000 users when the current & near future expected traffic is 10,000 or thereabouts. As individuals and organisations, we need to be pragmatic in formulating a strategy that sufficiently tackles both aspects.
- Smarter documentation | Documentation is a quintessential aspect of any project and we cannot live without it. However, determining the right level needed is far more important than just falling in the trap of documenting everything. Excessive documentation upfront in a project doesn’t add much value since the finer details are bound to change, also not many read pages and pages of text. The entire pre-text of Agile is to engage in conversation to hash out finer details and deliver incrementally.
- Continuous knowledge sharing and transparency | Helps in avoiding dependency and ensures smooth workflow in delivering only what the customer wants. Also enriches the collaborative knowledge built within the team.
- End user empathy | Closely relating to the needs of end users, helps in defining the exact deliverable needed. Developing a high-tech and modern application is of no use if it doesn’t resolve the problem or it goes beyond what the immediate need is.
- Selection of appropriate process and tools | Ensures optimum utilization of time and resources, and reduces the waste of ‘Over-processing’. Tools also mean automation – the more the better.
- Cross-functional and dedicated team | A fact that cannot be stated more. Ensuring this aspect will ensure consistency and higher productivity.
All the aspects stated above are standard management principles covered across other methodologies in some form or another. One might ponder then, what is different in the Lean teaching?
Lean teaches us to take the holistic and people-oriented view to interpret the essence of deriving efficiency by identifying wastes. What it calls for is a deeper introspection in how we do our work, recognise the end goals and model our actions to deliver maximum value by eliminating waste as we identify them. This can be achieved by orienting our processes and practices such that our efforts in achieving the end goals are truly justified and optimized.
