It became transactional in that Agile also focuses on the management of people and their interactions rather than the processes or tools of the methodology they are following. Agile seeks to continuously collaborate with the customer in the development of the product, while responding to changes—immediately. External/regional/military terminologies have also been incorporated, making communication within Agile difficult at times.
A Look at Agile
Agile itself is different from other change management philosophies that abhor scope creep or even customer inputs (after the initial collection of parameters). Agile is meant to be iterative and adaptive using sprints, creating a rolling wave of milestones that can be surfed (riding the rolling wave) with a consistent fetch (flow direction) but leaving flexibility for the team to fulfill the requirements. This is the opposite of waterfall where once you have gone past a certain point, it is difficult to move back upstream even if there is a fetch switch (change in flow direction). Part of the risk matrix must look at the potential for shoaling (having the work pile up toward the end of the project requiring resource crashing) or the advent of a rogue wave (movements from multiple directions combining to create a scenario where the flow is so large that it cannot be handled no matter the amount of resources used) leading to odzi or anine (failure points or project cancelation) or All Pau (negatively over).
Agile terminology has changed through the years related to discussions about the velocity and inertia of a project as well as how to properly forecast the workflow. Agile language changed more as the methodology was incorporated into quality management and its user base expanded. For example, some of the terms highlighted above are from the surfing community, remnants of the Native American military code talkers with a little Hawaiian mixed in.
An important task for the continuous improvement practitioner is to ensure that when a term is used, everyone in the group understands what is being discussed! As you can see in just this section above, the terminology is likely to take a little getting used to.
As a process of quality management, Agile can be most readily used inside of a DMADV (Define, Measure, Analyze, Design, Verify) project. It can be used to address the needs that arise when the use of software or automation are the overriding factor in the fulfillment of customer desires – most often when moving from manual handling to a specifically-designed mechanization of the system/process.
What Is a Sprint?
From a quality management perspective, a sprint is an iteration of work and is similar to a Kaizen/Kaikaku engagement where there is a specific set of inputs and expected outputs to fulfill a singular purpose. However, in a sprint, there is an increased amount of effort brought to bear (similar in project management to crashing a project) and a hard-and-fast timeline that must be adhered to (timeboxing). A sprint is normally 30 days in length but can be as short as a week or as long as six weeks. But the biggest difference is that while a Kaizen produces an incremental improvement, the outcome of a sprint may be something reutilized or a completely new design.
Incorporating a Daily Scrum
In software development, a Scrum meeting is expected to occur each morning to make sure everyone is on the same page and timeline about 1) the work process and 2) what is being targeted for completion in the short term. The daily Scrum meeting should not take more than 15 minutes. The daily Scrum is more than just a status update; it’s a pulse check that should illuminate any impediments that are slowing the team’s progress.
During the daily Scrum, each member of the development team should briefly answer the following questions:
◈ What did you do yesterday?
◈ What will you do today?
◈ Are there any impediments in the way?
Each participant in this Scrum meeting should listen to the others and remain present through the entirety of the meeting. Often, members of the development team will identify opportunities to work together during the day based on discussions during the daily Scrum.
In quality management, a Scrum may only take place weekly or at the end of a sprint cycle. The Scrum Master will set the tempo of the frequency of the Scrum meetings and the desired outcomes. The Scrum Master uses information on the overall project parameters and knowledge of the burndown rate and sprint schedule to drive the overall schedule.
A Scrum meeting is a level-setting meeting used to ensure that all team members are up to speed on the current state of the project and perform a Scrum to determine if the project is ready to progress onward or if additional work must be completed before forward momentum is resumed.
A Scrum is an engagement where those team members who desire to press forward are faced by those who believe the product is not ready for the next iteration. This is similar to a forcefield analysis but is done on the fly verbally with the Scrum Master making the final determination. The side with the more powerful argument usually wins. If there are issues that need to be reworked in order to properly function, the Scrum Master may have the folks who were against moving forward accomplish a short parallel play or parallel sprint to bring the concerns to completion, while the rest of the team takes the next sprint. (That next sprint is usually decided though a Scrum and selected from a prioritized backlog.)
Burndown rate is based on the amount of human resources assigned to the project (based on knowledge-skills-activities [KSA] and work-breakdown-structure [WBS] and initially allocated through a backward-pass analysis of the known tasks) that can then be parceled out to fulfill tasks. The tasks (backlog or set of tasks in waiting) are often set up in a kanban system from the WBS (some call it a scrumban) where those tasks that are sequential are pulled into queue for work to be accomplished in order. Those that are to be done in parallel are pulled at the same time to begin the work, although they may be completed at different rates. The kanban is based on interconnected variables and dependencies and this is why the Scrum decision is so important – as is the knowledge/subject matter expertise of the Scrum Master.
Agile Scrum
Agile Scrum is Lean because it builds from the current state where value is mapped to fulfill a future state through story-driven modeling of outcomes, as they become known. The model changes in an Agile fashion with each input to derive the future state. The story is based on what the customer desires their experience with the system to be like, which often changes (volatility in which the backlog is refined). Then the system is designed, developed, fabricated, tested and deployed to provide that experience. This is accomplished by exploratory-through-adoption testing or run-pass or run-fail exercises where each fail becomes a “learning” that drives a bridge or fulfillment to close the gap.
A running earned value computation (normally used in project management) can be used to keep the Scrum Master informed as to how much of his allotted resources have been used while tracking time, cost and quality at the end of each sprint cycle. Then the actual costs can be compared with the planned value at that point and the earned value of the project known. The burndown rate and project schedule backlog (task definition list of tasks from the WBS) show if a project is on track and if the Scrum Master will have enough resources to finish the work or what the cost will be if additional resources are needed. If the project or segments thereof are running behind schedule, the Scrum Master may have to “crash” the project with additional resources in order to get it back on track before the next sprint is set to commence. This might only be identified during Scrum meetings and it is why they are usually held daily so that problems may be rectified before the current sprint iteration is complete.
At the end of the project a Scrum of Scrums will occur to determine if all of the project parameters have been met and are functional. This is similar to a Control/Verify phase tollgate in Six Sigma, but may require demonstration of the system to the stakeholders and customers to ensure verification and validation of the system or if retroactive action is needed.
The benefits of using Agile within your quality management functional work are easy to see. If you have not yet used Agile in a DMADV, give it a shot! It can drive positive results.
Posts
0 comments:
Post a Comment