Value-Driven Delivery - Part 3
With incremental delivery, the team regularly deploys working product increments throughout the project. The working software is typically deployed to a testing environment for evaluation in software development environments. When the team regularly deploys working increments to a test environment for evaluation, we have the opportunity to realize the benefits of the product and get an early return on investment. In addition, the cost of the change curve tells us that issues found in a test environment are much cheaper to fix than issues found during production later in the project. By delivering project value in small increments:
The customer can respond to features and review the product.
The initial product delivery is faster and costs less.
After each iteration, regression tests are utilized to uncover defects.
Minimal Viable Product (MVP)
The term "minimal viable product" refers to the package of functionality that is complete enough to be helpful to the end-users but small enough so that it does not represent the entire project. By deploying an early project version via incremental release, the business can experience an early return on investment while the development team keeps working on the primary functionality.
Agile Tooling
It is essential to understand that teams in an agile environment prefer low-tech, high-touch tools over complex ones. When using high-tech tools, two problems can arise:
Data accuracy perception increases.
Barriers to stakeholder interaction.
Instead, agile teams using low-tech, high-touch tools can avoid a tool-related perception of data accuracy and allow more people to revise the plans as suitable for the project. A key reason agile teams value these tools is collaboration and communication, two fundamental characteristics that, when present, help facilitate learning and knowledge transfer on the project. A Task or Kanban board is an essential tool used by agile teams that emphasizes the agile values of visual communication and transparency while allowing teams to use the task board to control their WIP.
Work in Progress (WIP) and WIP Limits
WIP is the work that has been started but has yet to be accepted by the customer. Lean and agile methods aim to reduce the number of WIP items to prevent issues such as:
The project uses investment capital and delivers no return on investment until the work in progress is converted into an accepted product.
Hiding bottlenecks in processes that slow overall workflow (or throughput) and mask efficiency issues.
The work in progress represents a risk in potential rework since there may still be many changes to work items until they have been accepted.
Short iterations limit the amount of work the team takes on at one time. Teams that do not use short iterations place WIP limits and restrict the number of items that the team can work on at once. Once the limit is reached, no new items may move to the column on the task board until another is moved out. WIP Limits are critical because reducing work in progress increases a team's productivity by speeding up the work completion rate. The goal is to optimize throughput rather than resource utilization. From an agile perspective, moving through the work queue as quickly as possible is more important than keeping all team members as busy as possible at all times.
Cumulative Flow Diagrams (CFDs)
Cumulative Flow Diagrams (CFDs) are stacked area graphs representing the features in progress, remaining, and completed over time. CFDs are helpful tools for tracking and forecasting the delivery of value. In addition, applying Little's Law (the duration of a work queue is dependent on its size) to the items in progress and the cycle time (how long it will take to complete those items), the agile team should consider WIP Limits and reduce cycle times as a means to avoid sunk investment costs that have yet to be realized. The more WIP and longer cycle times in a project, the higher the probable waste in the system if we encounter an issue.
Bottlenecks and the Theory of Constraints
The Theory of Constraints (TOC) is a tool that aims to identify the bottlenecks within a given system and find ways to improve related issues. Introduced by Eli Goldratt, TOC can be utilized on agile projects to identify bottlenecks by following the Five Focusing Steps:
“...changes to most of the variables in an organization usually have only small impacts on global performance. There are few variables (perhaps only one) for which a significant change in local performance will effect a significant change in global performance.”
Identify the constraint.
Exploit the constraint.
Subordinate all other processes to exploit the constraint.
If steps 2 and 3 are done, more capacity is needed to meet demand and elevate the constraint.
If the constraint has not moved, go back to step 1, but do not let inertia (complacency) become the system's constraint.
Another tool used to identify bottlenecks is a detailed CFD. Instead of micromanaging team throughput, detailed CFDs allow us to identify bottlenecks unobtrusively. To determine bottlenecks in a detailed CFD, we look for areas that widen before the completion of the last activity, signaling that the widening area above the activity is progressing slower.
In the next section of the series, we will discuss Agile Contracting.
