Systems thinking is an approach to solving complex problems that seeks to understand the system as a whole, recognizing patterns and considering connections. Systems thinking recognizes that complex systems are made up of not just parts, but also of interactions and rules. These rules are important decisions that guide the behavior of the system. Systems thinking also recognizes relationships between parts and that relationships between parts influence each other. A systems thinking approach focuses on a system’s properties, such as its relationship to other elements in the system, and the relationships among these elements and behavior of the system as a whole. An excellent reference on Systems Thinking is the book 'The Fifth Discipline' by Peter Senge. In it, Peter describes 11 laws: Today’s problems come from yesterday’s ‘solutions.’ The harder you push, the harder the system pushes back. Behavior will grow worse before it grows better. The easy way out usually leads back in. The cure can be worse than the disease. Faster is slower. Cause and effect are not closely related in time and space. Small changes can produce big results…but the areas of highest leverage are often the least obvious. You can have your cake and eat it too—but not all at once. Dividing an elephant in half does not produce two small elephants. There is no blame. Developing Systems Thinking improves the ability of leaders, coaches, Product Owners and Scrum Masters to holistically solve the problems at hand, rather than solving the symptoms.

Value-stream mapping, is a powerful visual technique originating from Lean Management to determine the efficiency of a value stream. The Value-stream map visualizes the flow of both materials and information as they progress through the process from Idea to Solution. It involves labelling and quantifing the activity time, and waiting (idle) time to calculate the effeciency of the value creation process. Value flow efficiency of 5-10% is typical for a large number of manufacturing processes, product development in large organization, etc. Mapping the time taken during the value creating activities and idle time between two activities, helps identify the process improvement areas in an organization.

Velocity is not a Scrum term, it is a term used in Extreme Programming. Velocity is the rate at which value has been delivered. It's calculated as an average of the value delivered by a team in the past few Sprints. [ Let's say average of last 4 or 5 Sprints ]. Let's say: The Team Acers delivered below number of Product Backlog Items: Sprint Number of Product Backlog Items Delivered 5 7 6 6 7 7 8 5 9 8 10 7 At the end of Sprint 10, the velocity of team Acers is 6-7 Product Backlog Items per Sprint. The velocity trending upward over a period may indicate that the team is delivering more output. More velocity does not equal more value or more impact. Also, velocity numbers can easily be gamed when velocity is used for micro-managing the team or pushing them to deliver more than what they could comfortably deliver. Comparing Velocity of two teams is usually a waste of effort and futile. As two teams may have different set of work, complexity, skill set, collaboration, availability of Product Owner and many other variables would be different.

The maximum amount of Work-In-Process (WIP) that can be pulled in for processing / implementation within a workflow. This is a limit on the total amount of items that can be in process. The purpose of having a WIP Limit is to increase the focus on the flow of value. Due to the limits on WIP, the remaining work items can be either Waiting to be Picked up or Completed (Done). In a Scrum environment, to improve the flow of value delivery, it's recommended that the number of work items in progress may be lesser than the number of developers available to execute the work items.

Complimentary Practices - Agile and Scrum Glossary

Systems Thinking

Test Driven Development

Toyota Production System

Value Stream Mapping

Velocity

WIP Limit