module-3 Understanding Agile at a Deeper Level
Flow
Flow is one of the most important lean principles to understand to maximize the efficiency of any process. There are a number of factors that contribute to maximizing flow, which include: ◾ Small batch sizes ◾ Just-in-time production ◾ Concurrent processing
Just-in-Time Production
Having large quantities of raw materials waiting to be processed is inefficient because they become bottlenecks. A much more efficient process is based on just-in-time processing, when the raw mate- rials arrive just at the right time that they are needed in production. A large business requirements document in a software development environment is equivalent to a large pile of raw materials in a manufacturing environment. Instead of developing large requirements documents that wait to be processed, it is generally more efficient to develop requirements just-in-time as needed in the software development process. For example: ◾ Early in the process, high-level requirements should be sufficient to do whatever level of planning is needed at that point. ◾ The elaboration of requirement details can be deferred until later in the process when those partic- ular requirements are ready to enter development.
Small Batch Sizes
In a manufacturing process, it is well known that small batch sizes are much better for optimizing the flow of a process than large batch sizes. If large batch sizes are used, bottlenecks can easily develop at various points in the process, and material winds up waiting at those bottleneck points, creating waste. There are at least a couple of types of waste associated with large batch sizes: ◾ Excess material inventory is used in the process, creating unnecessary inventory cost, space for storage, and additional handling costs. Mary Poppendiek uses an example of the construction of the Empire State Building in New York. The Empire State Building was the tallest building in the world and was built in a total of 20 months, including demolition of existing buildings and plan- ning and design of the new building.11 One of the most serious constraints was that there was only a limited amount of vacant real estate in the area to store the materials needed for the building. This meant that the flow of the project had to be very carefully planned. The building was built in iterations of a few floors at a time, and the arrival of material had to be scheduled meticulously to have just the right materials available at the right time to maximize the flow. ◾ If the inventory is perishable, it can go stale and become unusable. By perishable, I'm not nec- essarily referring to fruits and vegetables. Dell Computer is a good example. Dell builds systems for customers out of a variety of different components (disk drives, graphic cards, etc.), and those components become obsolete quickly and are constantly being replaced by newer versions. Using small batch sizes and building systems on demand as customers need them reduces the risk of winding up with too much obsolete inventory of components in the pipeline.12 The other major advantages of small batch sizes are13: ◾ It reduces the end-to-end cycle time (Little's Law of Queuing14). ◾ It makes waste a very hard problem to ignore as any waste in a small batch size system will cause much larger problems than when you've got inventory at hand to smooth it over. You then have to confront and fix the waste. The visual metaphor often employed is that a stream running low uncov- ers the rocks on its bed. Attempting to define all the requirements for a product or application up front in a traditional development process is analogous to attempting to process large batch sizes in a manufacturing process. It's impossible to work on all the requirements at once, so bottlenecks develop at various points in the process and requirements wind up waiting to be processed. Having an excess of require- ments sitting around waiting to be processed is similar to having excess inventory in a manufacturing process: ◾ There are handling costs associated with managing those requirements waiting to be processed— they have to be well documented and tracked or they may be forgotten and left out of the design. There is also a certain amount of overhead associated with managing changes to these requirements.
Push system process of delivering product
In a traditional manufacturing pro- cess approach, production output is forecast, inventory is stocked at various points, and raw materials are then pushed through the process to fulfill that forecast. This type of process has been the predom- inant approach used in manufacturing for many years to maximize the efficiency of the production equipment used in the process. This approach has three potential deficiencies: 1. The forecasting process requires an intelligent guess at what the customer demand will be well in advance of when it is actually expected to be delivered from production. This is very difficult to do accurately and is fraught with lots of potential problems. 2. The process is very difficult to adjust—if there is a change in customer demand, it can take a considerable amount of time and effort to re-plan the entire process to adjust to that change. There also may be a considerable lag associated with restocking material to support the revised plan. 3. If the forecast is wrong, there are significant potential risks, including: ◾ Winding up with a significant amount of unusable inventory that might have to be scrapped (In a software project, unusable inventory translates to extra features that no one needs or is likely to use that complicate the product and cause unnecessary maintenance if they are not removed.) ◾ Not having sufficient inventory to fill customer demand if the forecast is wrong (In a soft- ware project, this translates to not having the right features to satisfy customer needs.) ◾ Having to stockpile or store inventory beyond the originally planned duration (In a software project, this translates into undesirable product management overhead.) "I've often seen this administrative burden lumped onto the project manager who must now wade through bloated scope matrices, backlogs of change requests and unwieldy specifications."
The Seven Wastes of Manufacturing
Inventory Extra processing Overproduction Transportation Waiting Motion Defects
The Seven Wastes of Software Development
Partially done work Extra processes Extra features Task switching Waiting Motion Defects
TQM
Total quality management
TQM philosophy is base
1. Cease dependence on inspection 2. Emphasis on the human aspect of quality 3. The need for cross-functional collaboration 4. Importance of leadership 5. Ongoing continuous improvement
Pull system process of delivering product
A pull system works by producing only the required amount to meet demand at each stage. In a manufacturing system, this would be characterized by a just-in-time production scheduling system. Many of the ideas for lean manufacturing came from the Toyota Production System and Kanban. If the word Kanban were translated literally, Kan means visual, and ban means card or board. The idea is based on inventory demand cards that are sometimes used in a manufacturing system: Once the developer has picked up a user story to begin working on, he/she will then work directly with the user to pull more detail as needed to fill that requirement.
Task of an AGILE PROJECT MANAGER
An agile project manager needs to understand agile at a deeper level in order to apply it to different situations effectively. The key to that is to develop a systems thinking approach to understand agile principles and practices at a deeper level. In order to develop that kind of systems thinking approach, it is valuable to understand the roots of agile and how agile thinking evolved. The roots of agile go fairly deep, but there are two major sources that had the most impact on its development: ◾ Total quality management (TQM) was probably the strongest factor in influencing the agile approach to quality. ◾ Lean manufacturing was probably the biggest factor in influencing agile process thinking.
Map the Value Stream
An important principle of both lean manufacturing and lean software development is to map the value stream. This process basically involves starting from the point that the product or service is delivered to the customer (either internal customer or external customer) and working backward from that point to map all the process steps that led up to fulfilling that customer value. The next step is to identify and differentiate steps that produce value to the customer from steps in the process that produce no value to the customer and may constitute waste.
Concurrent Processing
Concurrent processing is another well-known way to improve flow in any process. In a manufactur- ing process, bottlenecks are much more likely to develop if there is only one path through the sys- tem and everything is sequential than if there are parallel paths available and some work can be done concurrently on different paths. In a product development process, there are typically greater opportunities for concurrent engi- neering to improve the flow through the process. Here are a few examples: ◾ Requirements development can be overlapped with design instead of being sequential, and quality testing can also overlap with design instead of following it sequentially. This requires a much more collaborative, cross-functional approach to development, which can be difficult to achieve, but the potential payoff can be significant. ◾ Design teams can work on multiple iterations concurrently. This requires breaking up the design effort into iterations and requires some coordination among design teams: Concurrent engineering is especially useful when dealing with 'unprecedented' requirements . . . This can provide cover in situations where you have multiple integration approaches to choose from and don't know which is best (e.g., which will deliver the right performance, availability, or conform to other non-functional requirements). Similarly, challenging UI problems are sometimes best tackled using concurrent engineering (e.g., prototyping multiple solutions and testing them with real, representative users) in a 'survival of the fittest' approach.
SYSTEMS THINKING
Practice of thinking that takes a holistic view of complex events or phenomenon, seem- ingly caused by myriad of isolated, independent, and usually unpredictable factors or forces. Systems Thinking views all events and phenomenon as 'wholes' interacting according to systems principles in a few basic patterns called systems archetypes. These patterns underlie vastly different events and phenomenon such as diminishing returns from efforts, spread of contagious diseases, and fulfillment in personal relationships. Systems Thinking stands in contrast to the analytic or mechanistic thinking that all phenomenon can be understood by reducing them to their ultimate elements. It rec- ognizes that systems ('organized wholes') ranging from SOAP bubbles to galaxies, and ant colonies to nations, can be better understood only when their wholeness (identity and structural integrity) is maintained, thus permitting the study of the properties of the wholes instead of the properties of their components.
Why is systems thinking important?
◾ You see the whole rather than the pieces and understand their relationship. In an agile implemen- tation you see the business as a large ecosystem and see the development process as only one component of that ecosystem and you begin to better understand how the two are interrelated to each other. ◾ Within an agile development process, you begin to better understand how all the components of that process work together to make the overall process more effective and instead of following the process rigidly and mechanically, you see it as a much more dynamic process where each compo- nent of the process may need to be adjusted to fit the situation. Binary thinking is the antithesis of systems thinking. Instead of seeing the real complexity that is inherent in many situations, people who engage in binary thinking are sometimes looking for a simple, cause-effect explanation for something that isn't really very simple at all: ◾ They tend to see the agile values and principles in black-and-white terms, as absolute statements, rather than relative statements that need to be interpreted in the context of the situation as they were intended to be. ◾ They see the relationship of agile and more traditional plan-driven approaches as either-or, mutu- ally exclusive choices (Either you're agile or you're not) and they may see these approaches as com- petitive with each other rather than seeing them as potentially complementary. That sort of narrow thinking has led to many stereotypes, myths, and misconceptions about what agile is, and also about what traditional project management is. We need to rethink what agile is as well as rethink what traditional project management is to see them in a new light as potentially com- plementary rather than competitive approaches. Systems thinking is the key to that.
