Wastes

Activities, manual or automated, that add no value to the organization or customers are considered waste. We utilize the 8 Wastes of Lean to categorize activities in the Lifecycle Sleuth deemed to add no value. The table below lists the waste categories in the Lifecycle Sleuth , a simple definition, as well as examples.

	Waste	Context/Purpose	Examples
	Not Categorized	Waste that has been systemically detected by the WORE but unable to definitively categorize it
	Defects	Unexpected behavior occurs	Defects found in higher environments that could have been captured in lower environment
	Extra Processing	Activities that do not add value	Non-reusable documentation
	Hand-Off	Activity where one is relinquishing responsibility of something to another. It also causes risk because the more information is handed off the more we lose knowledge of it	Analyst gets a requirement who then gives it to a development lead, who then gives it to a developer who then provides it to a tester when complete.
	Motion	Unnecessary motion of people	Walking to meetings, searching through logs, searching for artifacts
	Over Production	“Things” not required in the release of a solution to production	Activities in a staging environment, documentation that will only be read once, etc.
	Waiting	Waiting for an upstream process to deliver or for an automated process to finish before the activity can be started	Waiting on meeting outcome, waiting for a manual activity to complete, etc.
	Task Switching	Interruptions that causes one to lose focus – usually a ~15 minute loss each time	Phone calls, emails, “drive byes”, daily scrum, meetings, etc.
	Transportation	Unnecessary transport and handling of “things”	Emailing of “things” that others should be pulling on demand, copying artifacts to other locations for packaging, etc.

 Defects

Agile-Lean Engineering Guidelines 

1. Utilize a Test-First Approach
   • Test-Driven-Development (TDD) for unit and integration testing
   • Behavior-Driven-Development (BDD) for functional testing
2. Emphasize prevention of defects over identification
   • Utilize ~80% unit test code coverage over new or refactored code
   • Utilize relevant integration testing
3. Employ xUnit Testing for unit and integration testing
   • Standardize on a relevant xUnit framework per technology stack
4. Identify vulnerabilities and weaknesses early in the development process
   • Utilize Static Code Analysis (SCA) when merging updates to the repository
5. Utilize Continuous Integration to provide fast feedback
   • Automatically trigger the process when attempting to merge or add contents to the repository
   • Automatically trigger unit tests and fail upon a single failure
   • Automatically trigger integration tests
   • Provide feedback as quickly as possible to the software engineers
     • ~5 minutes for extra-small and small systems
     • ~10 minutes for medium sized systems
     • ~15 minutes for large systems
     • ~30 minutes for extra-large systems

Agile-Lean Testing Guidelines

1. Test only when truly needed and use trust where possible (e.g. cosmetic changes, very minor defects, etc.)
2. Utilize automated regression testing (functional, accessibility, security, etc.)
3. Establish baselines for testing coverage (e.g. ~80% for unit testing, ~50% for integration testing, ~100% for smoke testing, etc.)

Agile-Lean Architectural Guidelines

1. Consider the -ilities (security, stability, functionality, maintainability, etc.)
2. Consider utilizing spikes before committing to architectural / design decisions

_{Go to Top of Page}

 Extra Processing

Anti-Patterns to Think About

1. Meetings without defined value-added outcomes
2. Use of a process to “make sure” something occurs
3. Creating documentation because someone “may want it later“
4. Creating features because the users will “just ask for it later anyway“

Agile-Lean Engineering Guidelines

1. Develop only the minimal required code, scripts, data, etc. to satisfy a user
2. Create code / scripts / data for reuse
3. Emphasize on low-complexity code

Agile-Lean Testing Guidelines

1. Collaborate with users to determine the minimal testing needed
2. Ensure the outcome of each test adds value to the process
3. Test only when truly needed and use trust where possible (e.g. cosmetic changes, very minor defects, etc.)
4. Declare what the “right” amount of testing is before coding
5. Eliminate / reduce manual testing processes to include actual testing, oversight, management, etc. via the utilization of automated regression testing (integration, functional, accessibility, security, etc.)
6. Control the amount of manual processes by establishing baselines for testing coverage (e.g. ~80% for unit testing, ~50% for integration testing, ~100% for smoke testing, etc.)

Agile-Lean Architectural Guidelines

1. Incorporate the -ilities (security, stability, functionality, maintainability, etc.) upfront in order to prevent mass rework later
2. Utilize spikes before committing to architectural / design decisions that may prove to be poor decisions later

_{Go to Top of Page}

 Hand-Offs

Anti-Patterns to Think About

1. Organization utilizes “sign-offs”
2. Organization utilizes stage gates reviews
3. Culture is a mistrusting / punishing one
4. Organization doesn’t think developers can test
5. Organization doesn’t think developers can interact with customers, stakeholders, etc.

Agile-Lean Engineering Guidelines

1. Have the delivery team responsible to update documentation (architectural, design, implementation, etc.)

Agile-Lean Testing Guidelines

1. Developers create and execute their own unit tests
2. Developers create and execute their own integration tests
3. Developers performs at least the “happy path” for functional testing
4. Document and transfer knowledge when and where necessary
5. Developers fix their own bugs / defects
6. Developers have authority to close bugs / defects
7. Developers have authority to close their own spikes

Agile-Lean Architectural Guidelines

1. Have the delivery teams build out the architecture vice a shared service group focused on architecture
2. Utilize a shared service team focused on architecture for just governance and guidance
3. Have the delivery team responsible to update documentation (architectural, design, implementation, etc.)
4. Utilize simplicity in design and approach so any delivery team member can help build out the architecture

_{Go to Top of Page}

 Motion

Anti-Patterns to Think About

1. Long walks to scrums, swarms, meetings, etc.
2. Inability to quickly find artifacts & information
3. Inability to quickly find information in logs

Overcoming Anti-Patterns

1. Favor collocation of team members to reduce timeline for clarifying questions, scrums, swarms, etc.
2. Favor remote access over psychical access as much as possible
3. Utilize video-capable social media platform for non-collocated delivery teams for clarifying questions, scrums, swarms, etc.
4. Produce just value-added lightweight documentation to reduce the “noise” within data so information can be more quickly found
5. Log everything and have the information readily available to every team member
6. Push useful data & information to team members vice them having to search for it

Agile-Lean Engineering Guidelines

1. Collocate the delivery team to provide opportunities for pair-programming, discussions on approaches, etc.
2. As much as possible, embed business owner, stakeholders, users, etc. with the team for planning, clarifications, demonstrations, etc.

Agile-Lean Testing Guidelines

1. Collocate testing teams to provide opportunities for pairing, discussions on approaches, etc.
2. As possible, collocate testers with developers for pairing, planning, clarifying questions, demonstrations, etc.

Agile-Lean Architectural Guidelines

1. Utilize secure remote access networks and virtual machines vice physical access
2. Provide secure remote access to logs, artifacts, etc.

_{Go to Top of Page}

 Over Production

Anti-Patterns to Think About

1. Creating documentation because someone “may want it later“
2. Creating features because the users will “just ask for it later anyway“
3. Unused logs
4. Unused artifacts / wikis / documents / etc.

Agile-Lean Engineering Guidelines

1. Develop only the minimal required code, scripts, data, etc. to satisfy a user
2. Create code / scripts / data for reuse
3. Create just the right amount of documentation to convey design and usage
4. Utilize a centralized logging approach to eliminate the creation of essentially duplicate code, data, scripts, etc.
5. Utilize pre-production environments that truly add value to the quality assurance of a product
6. Utilize short feedback cycles to ensure just value added minimal features are being developed

Agile-Lean Testing Guidelines

1. Collaborate with users to determine the minimal testing needed
2. Test only what is agreed to
3. Ensure the outcome of each test adds value to the process
4. Test only when truly needed and use trust where possible (e.g. cosmetic changes, very minor defects, etc.)
5. Declare what the “right” amount of testing is before coding
6. Utilize automated test harnesses / scripts in lieu of test cases and test plans

Agile-Lean Architectural Guidelines

1. Only incorporate efforts to meet NFRs that matter (AKA the -ilities like security, stability, functionality, maintainability, etc.)
2. Continually utilize spikes for feedback to determine what architectural matters that need to be addressed

_{Go to Top of Page}

 Waiting

Anti-Patterns to Think About

1. Developers wait for others to have their code merged
2. Code push / merge takes more than a few minutes
3. Individuals waiting on others to attend a meeting / ceremony

Overcoming Anti-Patterns

1. Automate entire CI/CD pipeline(s)
2. Eliminate non-value add activities in CI/CD pipeline(s)
3. Reduce duration activities in CI/CD pipeline(s)
4. Optimize pipeline to stop as soon as enough testing results indicate it lacks the quality to be promoted
5. Establish working agreements for more effective meetings / ceremonies
   1. Meetings do not run up against each other (e.g. 5 minute gap between each meeting)
   2. Require an agenda so they can execute more quickly
   3. Require rooms are setup and ready to go on time (seating, tables, physical boards, etc.)
   4. Require electronics are tested and ready to go on time (virtual platforms, microphones, etc.)
   5. Attendees come prepared to actively participate (knowledge, electronics, etc.)
   6. Attendees indicate their availability so others are not waiting on them

_{Go to Top of Page}

 Task-Switching

Anti-Patterns to Think About

1. Team members attend a lot of meetings
2. Too much collaboration
3. Meetings scattered throughout the day
4. Too many people with direct access to the team
5. Teams and individuals are continually interrupted to perform non-delivery activities (management oversight, reporting, etc.)

Overcoming Anti-Patterns

1. Reduce meetings to those that teams and individuals consider vital
2. Reduce collaboration to level that teams and individuals consider optimal
3. Conduct events, scrums, meetings, etc. at beginning of day vice throughout the day
4. Limit access to individuals and team from external resources (leadership, stakeholders, managers, etc.)
5. Limit managerial actives for teams and individuals
6. Eliminate individual from meetings who are not providing constructive feedback / input
7. Eliminate individuals from meetings who are there for information purposes and find other mechanisms for knowledge transfer (wiki, recording, etc.)
8. Have teams collaborate on at least a generic Definition of Ready for work items to reduce clarifying questions on what to do
9. Have teams collaborate on at least a generic Definition of Done for work items to reduce clarifying questions on the level of quality the business and stakeholders need
10. Have delivery teams participate in creation of acceptance criteria on work items to reduce clarifying questions on what to build, test, and demonstrate
11. Require team confirms understanding of work items before committing to them
12. Establish “In-the-Zone” hours to prevent the team from any interruptions unless of an emergency nature
13. Frequently review the purpose and outcome of meetings to ensure they still provide value

Agile-Lean Engineering Guidelines

1. Conduct planning and refinement events with the entire delivery team so they have shared understanding to reduce future clarifying questions
2. Utilize tools for feedback so others can provide input
3. Utilize visual cues to indicate individual current-level of concentration
4. Only work on one thing at a time
5. If need to perform work on multiple products focus on just one at a time
6. Attain all the information you need before starting the test process
7. Remove yourself from meetings where you do not provide constructive feedback

Agile-Lean Testing Guidelines

1. Conduct planning and refinement events with testers so they have shared understanding to reduce future clarifying questions
2. Limit Work-in-Progress for testing activities in order to complete something vice having conversations about starting and stopping on activities
3. Actively participate in planning and refinement events in order to reduce the need for clarifying questions

Agile-Lean Architectural Guidelines

1. Provide secure remote access to systems logs, architectural artifacts, etc. so as to not interrupt others for them

_{Go to Top of Page}

 Transportation

Anti-Patterns to Think About

1. Movement of people to meet with a single person or fewer people
2. Movement of team meetings away from where they work
3. Manual activities to build, test, package, and deliver solutions
4. Long-running automated activities to build, test, package, and deliver solutions
5. Team members are asking for information like ticket numbers, data, web links, scripts, etc.
6. Dispersed team members meet in person for all / most reviews, demos, etc.
7. Team members complain they are doing useless work (over production; processes or artifacts)

Overcoming Anti-Patterns

1. Have leadership go to where the people are
2. Have team meetings where they work
3. When efficient, connect people and teams virtually
4. Continually evaluate forums and logistics for meetings, events, ceremonies, etc. for elimination or improvement
5. Physically arrange office spaces to provide easy quick opportunities to collaborate
6. Invest time to identify and eliminate overproduction in the software factories
7. Invest time to quantify fiscal cost of transportation for leadership to allow time for improvement
8. Identify and eliminate non-value added activities (what the customer would not want to pay)
9. Invest time to identify online collaboration tools for activities like code reviews, peer review, design reviews, etc.
10. “Feed the Need” – establish working agreements to provide necessary information, data, web links, etc. so individuals do not have to go search for it

_{Go to Top of Page}

Consulting Services

disruptiveOps can support your organization with training, workshops, and consulting services to better understand how to identify waste, how to handle it, and continue to lean your processes. Please Bother Us or go to the services page of our website to learn more on how we can assist.

Access via RESTful Services

If your organization wishes to dynamically pull wastes outside of the Lifecycle Sleuth application, we have the secured RESTful microservices to do so.