Saugata's Blog

A dedicated Scrum Master, this blog is about the challenges and some solutions from my professional life

[saugv]

Cracking The SCRUMBAN (Scrum + Kanban) Code For Product Maintenance

Scrumban?? Is this one of those process gimmicks which are better suited for theory rather than actual business? These were my immediate thoughts on hearing the concept of Scrumban ! Why then, you ask, am I writing about it?  Because I have felt its enormous impact and want to share the process with which I helped implement it, with you. Mind you, if you are a fence-sitter, I will convert you ! I will start by laying out the problem I faced in detail due to which I started looking at Scrumban as a solution.

The Layout

“The problems are solved, not by giving new information, but by arranging what we have known since long.” 

                                                                                           ―Ludwig Wittgenstein

As an organisation which develops products catering to both B2B and B2C, most of our product are under extended warranty (3-7 years). This causes extensive maintenance operations where upgrades and fixes are made available for all product lines which are under warranty. This scenario is familiar to anyone handling operations for a product development organisation. While we utilised Waterfall model, the process followed for maintenance was as follows:

End user on facing any issue, would call up customer care. At this point cost starts in real dollar value for us in terms of $X/min of call.

If caller is satisfied during the call, no further activity is recorded.

If not, the caller can ask the issue to be corrected.

At this point cost gets escalated exponentially as issue is logged on to Customer care database.

Through profiling of call, issue is allocated to different teams. These allocations mostly were wrong and hence, the turnaround time (TAT) was large.

Till the issue is correctly solved, cost keeps getting increased.

The service manager bunches numerous issues together and releases them to end users as an upgrade. The timing of such a release is not fixed.

Above mechanism may sound familiar to some of you. Even if it doesn’t I guess you would have understood the picture by now. The problem starts once transition to Agile from waterfall has been made (the details are available here). Simply put, if there are no departments, how do we now handle flow of maintenance issues? Hence, we arrive at the requirement:

The Basics

“I cannot teach anybody anything. I can only make them think”

                                                                                                           ―Socrates 

Before we start on the journey, we should get our basics defined. We need to identify what are the Agile processes we are discussing and their respective pros and cons. This will enable us to investigate what structures we can come up with to satisfy our goals stated in above section.

Scrum

Framework consists of 3 artifacts viz., Product Backlog, Sprint Backlog and Product Increment, using 5 events viz., Sprint planning, Sprint review, Sprint retrospective, Daily standup, Sprint. It has 3 roles associated with it viz., Product owner, Scrum Master and Scrum team.

Pros:

Teams use iterations to provide product level deliverable

Scope of iterations is defined by team

At the end of the iterations the deliverableare reviewed by all stakeholders

The priorities and backlog items can be changed during Sprint

The team can identify the rate of consumption of items (velocity) and can therefore, predict the release plan of all items

Cons:

Scrum process is not optimised for the case when constant, similar sized items create the backlog

Estimations may cause waste as different sized task are estimated randomly by team

Scrum allows items to be added/removed from backlog which might create a release not having all required items

Kanban

Framework is a set of processes which allow managing and improving workflow derived from the Japanese automobile industry. The 6 core practices of Kanban are:

Visualize the flow of work:the flow of work should be visible to all participants. This is done through a Kanban board (physical or electronic)

Limit WIP (Work in Progress):Kanban implements a 'Pull system’, wherein team members are required to first complete the task at hand before new work is pulled in.

Manage Flow: Flow of work is managed by highlighting work items and their status in each stage

Make Process Policies Explicit:Each stage has explicit policies and these policies should be highlighted so that all stakeholders can easily visualizethem

Implement Feedback Loops:Feedback loops are essential in Kanbanprocesses so that review of status, metrics and workflow can be done and feedback provided

Improve Collaboratively, Evolve Experimentally (using the scientific method):Kanban expects constant improvement through small changes, which helps the team to maximizeproductivity and achieve high performance.

Further,details on Kanban can be found in this article.

Pros:

Wastage is reduced using Kanban.

As only those items are picked which the team can work on, excess inventory is removed.

If jobs are entered at constant rate, a constant rate of release can be achieved.

Cons:

If jobs are of different sizes, this process leads to system lag

Since this process is related to day-to-day flexibility, multiple projects which require medium or long term planning cannot use this project optimally.

This process also has a requirement for a stable production environment where all dependent parties produce at the same constant rate. This may not be acceptable in all projects.

The Solution

“Do. Or do not. There is no try.” 

                                                                                                     -The Empire 

Strikes BackNow that we have visited the basics, can we identify a process which mixes the virtues of both these frameworks to create a structure which will help us reach or goals? Lo and behold - you have reached the answer - its SCRUMBAN!!

How We Set It Up

Team -  the team was a cross-functional team created from members in such a way that competency in all related fields were available. We setup a team of 9 members for each product line after consultation with all SME (Subject Matter Experts) and Product Owners. The team was encouraged to increase the 'T-profile’ in breadth so that every personnel could handle any incoming item and the competency of members did not become a bottleneck.

Roles - 3 roles were identified in this framework. Scrum Master was tasked with handling the operational aspects and fine tuning the processes. Team handled the execution of day-to-day activities. Product Owner acted as Service Manager who would handle prioritization of incoming requests and release planning.

Framework -

Job Card 

The very basis of Kanban is the job card which details the specification of the job to be done. This card is then ‘pulled’ by the team into the ‘FLOW’ which moves to various 'stages'. I initiated the Scrumban process by which, we kept the concept of the card by making slight modifications to our bug tracking system. The bugs entered into the system needed specific inputs based on which prioritisation could be done such as region of origin etc was included.

Workflow

The initial board created for Scrumban had a ‘Backlog' list into which all bugs (cards) would be entered. These cards would be pulled by the team into the ‘In Progress’ stage once the team was ready. The process of prioritisation within ‘Backlog’ was done using Big Data analysis. This topic will be dealt with in a future article.The criteria for the ‘Pull’ was -

The job currently in ‘Working’ stage under a team member was shifted to ‘Done’ stage or

The job currently in ‘Working’ stage under a team member was shifted to ‘Waiting’ stage, waiting for inputs from other stakeholders (outside the scrumban team) and

No more cards than the total number of team members can be in ‘Waiting’ stage at any given time

The team owned the work in this structure. They gradually encouraged and coached each other in such a way that all members became competent across most competencies. No handoffs resulted in low lead time. The movement of card to ‘Done’ was only carried out once validation members undersigned the card as one which has passed the DoD (Definition of Done). As the same team was handling the cards, the lead time of each type of job was well defined after a short span of time. This allowed the team to predict accurately the rate of consumption of job cards. Extending this the Product Owner/Service Manager can plan for release at specified interval of time.

Improvement 

The team started with a Sprint duration of 2 weeks. The backlog which was filled with job cards was checked and prioritised during each Sprint planning. Of this the prioritised job cards filtered based on lead time were estimated to be resolved by end of the Sprint. At the end of Sprint, a verified release was made available which could be updated to the end customer. However, it was found during iterations that prioritisation of items changed within the 2 week sprint. Hence, the Sprint duration was reduced to 1 week. However, it could not be reduced much further as a complete release package was needed to be generated when Sprint ended and this was possible only after 1 week.

Kanban also emphasises constant improvement of work flow and identification of bottlenecks. To do so, the stages were modified where ‘To do’ stage was identified which held the exact number of items identified for the Sprint after filtering from the 'Backlog'. This helped in identifying the exact WIP limit of the team. Another stage was identified as ‘In Validation’ which was the stage reached when card DoD was needed to be verified. This was required after the team found that some cards were kept in 'Waiting' stage even though no activity other than DoD verification was needed. This addition also showed the duration for which cards were getting blocked in ‘In Validation’ or ‘Waiting’ stages. At such points of time, members could pull extra cards. Hence, the total number of cards in ‘To do’ were changed from 1* Number of team members to 1.5* Number of team members. Additionally, the reason for blocked items were unearthed and resolved. The full board picture was as below:

Structure

The complete structure now looked as follows:

The customer calls the Call centre(CC) which would raise a bug defect in bug tracking system giving specific details as required. This becomes a job card which goes through the Scrumban process as mentioned earlier. It results in a software release which is provided as an Update at regular intervals (decided by the PO) to the end user.

Conclusion

The Scrumban teams were able to reduce the defect density from product lines under maintenance. As seen from above diagram the impact was huge and a reduction of field calls by 50% on a year-on-year basis was observed. This impact was purely due to the successful execution of the framework as mentioned above. As can be seen, all goals mentioned in the first section were met. Hence, above steps can be utilized by any team who faces similar scenarios and want to achieve similar goals.

About Me : A passionate Scrum Master having 15+ years of experience in software industry, I have handled Agile based projects of various complexities. Having successfully handled Agile transition for multiple scrum teams, I write about my experiences, challenges and some solutions.Connect with me through LinkedIn or Google+

[cprime-project-management-blog]

How Uncertainty Works

by Kevin Thompson, Ph.D, PMP, CSP

How Uncertainty Works

All estimates are subject to uncertainty, and project schedules are no exception. A schedule consists of a set of tasks, which are executed at times dictated by dependencies and resources. The simplest schedule, consists of a set of tasks that are executed one after the other, and we’ll look more at this case below.

The schedule for a project contains uncertainty because the estimated effort or duration of each task has some uncertainty associated with it. We would really like to know exactly how long a task will take. If we can’t know that, we would at least like to know how much uncertainty is associated with the task. Unfortunately, we will never know the first, and usually will never know the second, either. (The exception to the latter rule is for tasks that are repeated, identically, enough times for us to collect meaningful statistics about them.)

In this article, we will look at uncertainty: Why it exists, how it behaves, how it accumulates, how to reduce it, and how to cope with it.

Why Uncertainty Exists

Suppose we are estimating the effort required to remodel a house. We will start by breaking down the project “Remodel House” into a few smaller steps, namely

Remodel Kitchen

Remodel Bedroom

Remodel Living Room

We want to estimate the effort required for each of these steps, such as “Remodel Bedroom.” Unfortunately, our estimate will not be exact. Estimates differ from reality because of uncertainties, which arise in many ways

Incomplete Understanding of Scope

We may not have accounted for all the requirements. Do we need to replace the baseboards? If we didn’t think about the baseboards, our concept of scope is missing an important element, and our estimate will not include the work to replace them.

Incomplete Understanding of Work per Scope

Perhaps we did include baseboard replacement in scope, but we assumed the effort involved was limited to nailing the new ones in position. Unfortunately, we didn’t account for the work required to measure and cut the baseboards to the right size, so even though the scope was right, the effort estimate will be too low.

Imperfect Understanding of Known Work

Even if we did remember all of the work that needs to be done for the baseboards, and estimate accordingly, our estimates may be off because some of the boards split when nailed. We will either have to replace those baseboards, or drill them to avoid splitting when we nail them. Either way, the work will increase beyond our estimate.

Inability to Forecast the Unexpected

What happens if the paint we need is out of stock, or someone delivers the wrong baseboards? These external events are unpredictable, and disrupt our schedule.

How Uncertainty Behaves

Most people have an intuitive feeling that tasks are more likely to require more effort than planned, rather than less. This feeling is correct, for two reasons.

First, we are likely to omit scope or tasks that contribute to the work, and so underestimate the effort. This is obvious, and we reviewed some examples above.

Second, there is more room, in a mathematical sense, for work to grow beyond expectation than to shrink below expectation. This may be less obvious, but think about the work required for Remodel Bedroom. Assume we estimate this work at three days. The actual time may be more than three days over this estimate, but cannot be more than three days under the estimate!

In mathematical terms, we cannot estimate a task as requiring “X plus or minus Y days,” because the estimate becomes meaningless if Y is greater than X.

What we can do is replace the concept of an increment of uncertainty with that of an uncertainty factor, F. This means that we think that X is the most likely duration, but the range of values is between X divided by F, and X times F.

For example, suppose we estimate “Paint Bedroom” at 3 days, with an uncertainty factor of 2.

The most likely case is 3 days.

The best case is 1.5 days, which is 1.5 days under the estimate.

The worst case is 6 days, which is 3 days over the estimate.

The real behavior of uncertainty is more complex than this simple model. (More sophisticated models rely on lognormal probability distributions and Monte Carlo methods.) However, our concept of an uncertainty factor is a convenient way to describe the most significant behavior of uncertainty, and we will continue with it.

How Uncertainty Accumulates

If errors were uniformly distributed above and below the expected values, they would tend to cancel out, on average, for a large set of tasks. As we’ll see, this is not the case.

Suppose we have a project containing 10 tasks, to be done one at a time, and each one is expected to take 10 working days. The naïve estimate for the project schedule is 100 working days for all tasks. The real schedule will deviate from the expectation, due to uncertainty.

Now we will assume that each task has an associated uncertainty factor of two. In the worst case, every task would take twice as long as expected, and the project would take 200 working days to complete.

The worst case isn’t very likely, so let’s consider a more typical case, where half of the tasks are under the estimate by the uncertainty factor, while half are over

The half that were under estimate take 5 days each (under by 5), while the half that are over estimate take 20 days (over by 15). The total time for all tasks is then 125 days.

Our typical case isn’t as bad as the worst case, but it exceeds the naïve schedule by 25% (25 days). This behavior is common, and it occurs because tasks can be over their estimates by more than they can be under. More realistic calculations, which rely on lognormal probability distributions instead of our simple uncertainty factor, are even more pessimistic. The long tail of the lognormal distribution has no upper bound, and tells us that some projects will never complete.

How to Reduce Uncertainty

While we cannot eliminate uncertainty when estimating work, we can take some steps to reduce it. One way to reduce uncertainty is to reduce the size of the thing to be estimated. The fewer the elements are that must be considered when producing an estimate, the more reliable the estimate is likely to be.

For example, the process of remodeling a bedroom contains a number of steps. If we estimate “Remodel Bedroom” directly, we may not think of all of the issues involved, and our estimate may be uncertain by a factor of three. Painting the bedroom, however, is a much smaller task, and has fewer elements that we may leave out of our estimate, so our estimate might be uncertain by a factor of two.

The obvious strategy for reducing uncertainty is to break large specifications or work items into smaller pieces. Thus we might break down “Remodel Bedroom” into four smaller tasks:

Remove old carpet

Paint room

Cut new carpet to fit

Install new carpet

Now we can produce an estimate for each of the smaller tasks. When we add these together, we will have an estimate for the bedroom remodeling, which is likely to be better than what we would have produced if we had not broken the work into smaller pieces.

The strategy of decreasing the “granularity” (size or level of detail) of items to be estimated improves accuracy, but has limitations. It can produce more items than we have the time to analyze, and thus delay the project completion. Also, there is no point in reducing the size below a level where the relative uncertainty does not improve. The important thing is to pick a granularity that (1) enables a tolerable level of uncertainty, and (2) produces a set of things to estimate that is small enough to be practical.

How to Cope with Uncertainty

Once we have reduced uncertainty to a practical minimum, the only other thing we can do is to take the remaining uncertainty into account in our process. We’ll look at strategies suited for projects that are subject to different kinds of constraints below. (For simplicity, we’ll assume that resources are fixed, since the ability to add resources does not vary in a meaningful way between the different scenarios. Similarly, we also assume that scope is well-enough controlled to prevent scope creep.)

Fixed Schedule, Fixed Scope

The first thing to understand about this set of constraints is that success is not always possible. If scope is truly fixed, and schedule is subject to uncertainty, then we have already seen that extreme cases will break any schedule.

These projects are planned with uncertainty in mind, by adding enough buffer time into the schedule to handle a reasonable level of uncertainty (for example, allocate 30% of the schedule for this purpose). This approach works well in situations where uncertainty is small, such as for repeating processes (e.g., laying carpet, or painting houses).

Fixed Schedule, Adjustable Scope

Many agile project-management frameworks handle uncertainty by committing to the only thing that can truly be controlled, which is the schedule, and adjusting the scope as required to meet the schedule. This strategy is particularly useful in high-uncertainty environments, where estimation is known to be inaccurate, and where scope is not well-understood and may change frequently.

The Scrum framework handles this situation effectively. It requires careful planning, but in a way that handles high uncertainty gracefully. Scrum projects work in short cycles to deliver modest increments of scope quickly, and to allow for frequent changes in scope and priority. Within each cycle, scope is adjusted as necessary in order to guarantee that the schedule is met.

No Schedule, Unknown Scope

Uncertainty is greatest when the scope is not known prior to the start of execution. This is the case for reactive organizations, such as Customer Support groups, which receive urgent requests that must be handled quickly, but which cannot be scheduled or planned in any meaningful way.

Another agile process, Kanban, is useful for this scenario. Kanban processes re-prioritize requests daily, and throttle (control) the flow of work by limiting simultaneous work-in-progress to a specified number (e.g., up to three concurrent requests can be handled by the staff).

Conclusion

Uncertainty cannot be eliminated by any estimation methods. It arises partly because of imperfect knowledge of what to do and how long it should take, and partly because of unpredictable events. The nature of task estimates is such that uncertainty biases deviations up, on average, relative to expected values. Again, on average, these upward biases accumulate even when as many tasks are under estimate as over, lengthening the schedule beyond the sum of expected task durations.

Reducing scope helps to reduce uncertainty, but only to a point. When uncertainty has been reduced as much as practical, the next step is to design the process to cope with uncertainty. We have reviewed three strategies for handling uncertainty:

For fixed-schedule and fixed-scope projects, add buffer time in the schedule. This works for low-uncertainty projects, especially those that repeat the same type of work many times.

For fixed-schedule projects, use an agile process such as Scrum, and adjust scope in a planned way to meet the schedule. This is an effective way to conduct a project when estimates are poor, and scope is poorly-defined and changes frequently, while still allowing for planning and a useful degree of predictability.

For unscheduled projects with unknown scope, uncertainty is very high, and planning is not possible. In this case, a strategy such as Kanban, which focuses on constraining work-in-progress, is effective.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.

[cprime-project-management-blog]

Integrating Waterfall

by Shayan Alam, PMP

Waterfall and Agile/Scrum development methodologies are widely used by all organizations and are individually considered a proven approach for development. However, challenges arise as these two methodologies merge and clash. Here are a few key tips to help integrate both methodologies into your development organization. Let’s first discuss each methodology and its unique characteristics and assumptions.

The waterfall software development life cycle methodology believes in getting everyone together and involved early in the design process. The design process is longer and iterative as the team steps through the high level requirements, conceptual approach, solutions design, preliminary design and critical design. This assumes little will be left for discovery through the development and testing phases. Generally, waterfall has worked effectively for certain types of products – large, enterprise-wide development efforts where the user is being led through a standardized process.

However, Agile/Scrum is meant for a more volatile world and provides an iterative approach. For example, in the mobile applications space, the landscape is constantly shifting as new phones, new operating systems, and new technology to deliver data compete to get the user to interact in as many ways as possible. Short iterative development allows for an “open” mind for discovery since less time is invested upfront. In this case, discovery involves anything from functional flaws to ineffective user flows to the concept being deemed a bad idea altogether.

The fundamental difference between the two is Agile/Scrum assumes there will be flaws and therefore jumps into the coding to expose these. Therefore the success of the development team is driven on its ability to adapt and react quickly. Waterfall, instead, takes early precautions to mitigate any flaws.

This obviously causes a clash between development teams practicing each of the development methodologies. But certain steps can be taken to show the development team the advantages of the other’s methodology and ideally bring a team together.

5 Tips to integrating agile development groups with waterfall development groups

Trying to introduce agile as iterative waterfall will not work

Some organizations think they can be more “agile” by doing waterfall in smaller iterations. The problem is the timeline is tough to compress when fully vetted artifacts are expected after each round of reviews. There is too much overhead with all of the document creation which detracts from the amount of time left for coding. Agile is about streamlining processes not compressing them.

 Development / QA can be iterative while being bookended by design and integration

One transition strategy is to employ agile in the development and QA cycles. Smaller scoped development cycles followed by QA. This way the customer sees the evolution of the application and can comment along the way. The design is properly vetted at the beginning and ample time is allotted for integration at the end.

 Watch out for scope creep

A project manager’s challenge in working in a fast-paced “can-do” development team is managing scope creep. Since changes can be implemented quickly, anything and everything seems possible. So the distinction must be made and managed between what is considered a fix versus what is considered a change so that sprints are tight and marching towards the agreed-upon end product.

 Play nice with QA

QA is always burdened as a release approaches, their schedule’s usually backed up against a wall. In waterfall, QA expects tight use cases to derive their test cases. So in the agile world, they get code thrown over the wall. That is why in agile teams, sometimes developers rotate into the QA role and become part of the solution from the beginning.

 Be mindful of the end user

Since at the end of each sprint a fully functional application is delivered, it is very tempting to release it. This can be very annoying to users if this requires a frequent patch or upgrade. It makes the user wonder whether a polished product is ever in the horizon. If the upgrades are seamless, it may be a hassle to keep up with the new changes. Therefore a published release schedule or roadmap keeps the user in the loop. Major releases semi-annually and/or functional releases quarterly are recommended.

 If you would like more information on this topic, send an email to [email protected]. We welcome your questions, comments and feedback.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.

[cprime-project-management-blog]

In these series of videos, Dr. Kevin Thompson compares and contrasts Agile projects with Waterfall projects and shows the affects of each when facing uncertainty. Kevin conducts a methodology experiment and shows why Agile projects succeed when others fail. All estimates are subject to uncertainty, and project schedules are no exception. A schedule consists of a set of tasks, which are executed at times dictated by dependencies and resources. The simplest schedule, consists of a set of tasks that are executed one after the other. The schedule for a project contains uncertainty because the estimated effort or duration of each task has some uncertainty associated with it. We would really like to know exactly how long a task will take. If we can’t know that, we would at least like to know how much uncertainty is associated with the task. Unfortunately, we will never know the first, and usually will never know the second, either. (The exception to the latter rule is for tasks that are repeated, identically, enough times for us to collect meaningful statistics about them.) Read the entire article.

Please watch Parts 2 through 5 here.

[agilescrum]

Technical debt is a natural byproduct of every successful software system. Great teams learn how to use technical debt to their advantage to improve time to market and balance short-term gains with long term pains. This talk shares some experiences creating, measuring, and paying down technical debt by sharing how to create a technical debt portfolio and used the portfolio as a guide for planning change. Creating a technical debt portfolio requires that we consider not only the debt within architectural components but also how those components align with the system's roadmap. We can measure debt in the architecture by looking at metrics such as such quality, churn, and conceptual integrity. We can prioritize the debt across our system by combining technical metrics with business concerns such as the probability of change (based on our roadmap) and potential value created (estimated by our product manager). By the end of this talk, you will learn strategies for measuring technical debt, creating a portfolio of debt, and using that portfolio to choose next steps to improve your software system. Video producer:

Technical debt is a natural byproduct of every successful software system. Great teams learn how to use technical debt to their advantage to improve time to market and balance short-term gains with long term pains. This talk shares some experiences creating, measuring, and paying down technical debt by sharing how to create a technical debt portfolio and used the portfolio as a guide for planning change.

[agilescrum]

A list of online Agile tools that can be used to facilitate remote retrospectives for distributed Scrum teams.

Many Scrum teams are based on a distributed organization where members are in different locations, countries or time zones. How could these Agile teams perform their retrospectives? Some companies have developed online tools that can be used to facilitate retrospectives for distributed Scrum teams.

[agilescrum]

Agile and Scrum team formation is a natural human response to certain conditions. Once they exist, the formation process begins. This session looks at those

Agile and Scrum team formation is a natural human response to certain conditions. Once they exist, the formation process begins. This session looks at those conditions, and then looks at what other conditions need to be reached to progress through the different stages defined by Bruce Tuckman: Forming, Storming, Norming, and Performing. We don’t need tricks to make it happen; we just need to know what kind of environment is needed, and we just need to help it along.

[saugv]

Wondering How To Make Your SPRINT RETROSPECTIVE Rock? Read This!

Teams not achieving the intended velocity. Missing deadlines and forecasts. We have all been there. As Scrum Master's, we have faced such issues and tried to understand the root cause. And the tool to understand underlying causes to the teams performance is a 'lessons-learned' or 'retrospective meeting' activity. In Waterfall process, PMBOK guide tells you to conduct this during the 'Closing' phase of the project. In Agile process, since iterations occur frequently, it is held after every iteration. However, even if we adhere to the prescription in letter, not maintaining it in spirit does not help us. How many times have we conducted the retrospective without having any impact whatsoever on our projects? In this article we will identify a template of retrospection based on a real life scenario which helped bring change in team morale, boosted productivity and ensured better metrics all round.

What is a Retrospective Meeting?

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" - Agile Manifesto -----------------------------------------------------------------------------------------------------------

Case Study

I was handling a scrum team for a particular product line in late 2017. The team strength was 7. We had worked for 2 Sprints. However, the forecast had never been met. This was a project which was supposed to be a derived product line - hence, the velocity had been verified in the actual product line. The EPIC burndown forecast after 2 Sprints looked as below:  

  As can be seen, velocity has completely deteriorated. Sprints have failed miserably. Questions were being asked about the capability of the team in progress review meetings. Deadlines were questioned and team commitment was under scanner. What was going wrong? To understand this, 2 retrospective meeting had been arranged after the increments. The retrospective meetings were held as per mandate with actions which were cursory in nature arriving at a list of items under 3 broad headings:

What should start doing

What should we stop doing

What should we continue doing

However, no concrete action could be arrived at. Why do you think that happened? -----------------------------------------------------------------------------------------------------------

The agile manifesto proposes that a "team reflects on how to become more effective". Agile mandates 2 ceremonies under the "Inspect and Adapt" process. First, is the Sprint Review. The second, is the Sprint Retrospective. Sprint Retrospectives are a great way for scrum teams to evolve and improve.

  As part of the 'Check' item in 'PDCA Cycle', scrum teams use retrospective activities to focus and improve overall way of working (WoW). In general teams verify the actions prescribed in previous retrospective. They 'Inspect' the status of their activities and define what 'Adapt'ation is required in their WoW.

Who participates and when is it held?  The scrum team participates along with a facilitator, who is mostly the Scrum Master. Note that the scrum team owns the retrospective. Along with the team and Scrum Master, Product Owner and any other stakeholder who is needed can be asked to participate in the meeting. It is generally held after the Sprint Review when ideas for improvement are easily available. However, it can be held at multiple points during the Sprint as and when needed. Please note that retrospectives should be handled at multiple levels for an organization to be completely effective. Also, for Scaled Agile variants, the 'I&A' cycle at the end of a Program Increment (PI) can be used for an organizational retrospective.

Why do we need to do retrospective? Retrospectives are meant to hold a mirror to the teams WoW. Please carefully note the difference. It is not the activities but the WoW that is of essence. It gives the team power to introspect and in most cases implement changes. In practical sense, they suggest those changes which require organizational support. However, they do hold a lot of power to modify the WoW as they feel is needed. The team goes through the actions committed previously, checks the efficacy, suggests changes and commits to them. This gives control back to the team and makes the Agile journey simpler and a more enabling one for them. As per the Scrum Guide the retrospective should be an “opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” The theme therefore, for retrospective is to be a placeholder for 'continuous improvement'.  

The Process And Its Outcome

                              " There is a way to do it better. Find it "

                                                                              - Thomas A Edison

To understand the goals of retrospective, let us first understand the difference between Review and Retrospective. Sprint Review is an activity which is carried out at the end of the Sprint in order to highlight the work DONE by the team. It is a ceremony during which all stakeholders can be invited to view demonstration of the increment of product environment and receive instant feedback. Scrum team run the spotlight on their work and get kudos for their work on negative feedback from stakeholders. Completed work, including partial ones where Sprints have failed, can be demonstrated.Sprint Retrospection is held after review. It allows the analysis of the work completed by the team which was demonstrated during review. Feedback received during review is discussed. Issues related to the team’s performance can be discussed in a free and fair manner without malice. This meeting need to be attended by all stakeholders.The goals for Sprint Retrospective is then to have a discussion about two different aspects:

The increment - the result of the increment demonstrated. Whether it met the specifications of DoD set by Product Owner? Were all working agreements regarding the increment met? Did the Sprint fail and if so what stories could still be demonstrated. Was the increment deriving the business values it set forth to? If not, what could be done better?

The process - what improvements can be brought about in the process? What was being done correctly ? What was incorrect? What modifications were needed.

-----------------------------------------------------------------------------------------------------------

  Case Study continued..

The typical retrospective that was mandated would be held at the end of Sprint Review on the last Friday evening of the Sprint. Team would try to wrap up the retrospective as soon as possible. Most of the team would not participate and would remain mute to the conversation. the general discourse would revolve around the 3 mandated questions mentioned earlier. For most of the questions, team would start a blame session.

Typical conversation would be :

J: We should start having regular sanity test reports on our builds

S: That would mean more work for me as I would be undersigning these reports. I cannot do it.

J: We should mention it anyway as part of “What should we start”.

M: What is the purpose of adding it if there will not be any results. Management has never helped us out. I remember last Sprint, we had asked…...

As shown in the diagram, for two Sprints the team had followed the same retrospective and had the similar failure rates. The forecast for 3rd Sprint was even worse. No actionable item was forthcoming from the retrospective and the environment around the discussion was often vitiated. Participation was also minimal. The time had come for some improvements to be made to the retrospective. -----------------------------------------------------------------------------------------------------------

Improvements

                     "Continuous Improvement is Better Than Delayed Perfection”

                                                                                                   -Mark Twain -----------------------------------------------------------------------------------------------------------Case Study continued..

The improvements discussed below have been derived from the book -

Agile Retrospectives

by Esther Derby & Diana Larsen. As a facilitator I started with ensuring the following -

I made the team aware of the Prime Directive as stated by Norman Kerth - "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." This gives the team a sense of a safe environment where anything could be discussed without fear.

Based on guidelines from the Scrum Guide I kept the meeting timeboxed to 2 hours for a 3 week Sprint. This gave a sense of focus to the team and reduced chances of long discussions which kept the team from wandering in their thought process.

I ensured that all activities were physical ones with electronic items kept at bay. This ensured that team was always 'available' in the space and not drifting away. Members working with Pen on Paper tend to have more concentration on the task at hand than when they are using electronic devices.

Members were also informed of follow up activity which was planned based on inputs from the retrospective. I had planned a meeting with product management on coming Monday based on issues reported during retrospective meeting and follow up sessions on a weekly basis.

The team was informed about the timeboxes and the games for each stage. General working agreements were chalked out:

No personal attacks

Actionable items should only be discussed

Conflicts are good and whatever conflict unearthed needs to be handled within the meeting. No extension of the conflict should be impacting the individual collaboration outside the meeting

The five stages  

  Setting the Stage - (Activity - ESVP)

The team was seated in a semicircle facing each other. Obstructions such as tables, movable desks etc, were removed. Product Owner was also requested to participate as insights from Product Management would also be valuable.The activity which was chosen was ESVP. The reason behind choosing this activity was to understand whether any participant was reluctant to participate and if so, why? The time box given for this activity was 15 min. During this activity, individuals could identify themselves belonging to a particular identity - Explorer, Shopper, Vacationer or Prisoner. Further details of this can be found in Section 4.3 of

Agile Retrospectives

by Esther Derby & Diana Larsen. None of the participants identified themselves as Prisoners, however, 2 identified as Vacationers. This showed clearly that there was interest in the team to participate in the retrospective even if not actively supporting. I decided to have a show of hands at the Close of the meeting to see if there were any changes in attitude among the participants.

Gather Data - (Activity - Mad,Sad,Glad)

The reason behind choosing this activity was that it gave ample opportunity for the team to celebrate their achievements. The time box for the meeting was set at 30 min. I asked the team to identify events which were associated with a specific emotion during the length of the Sprint. Mad were those events which they felt were had no place during the Sprint execution. Sad were those events which had a negative emotion attached to it. And Glad were those events which were marked with positive emotions. These events could be personal or professional. The events were written on postscripts and stuck onto flip charts. After the expiry of time box, all members went through each of the items and tried to understand a bit more about them. We bunched together those which were similar in nature. This gave us quite a few items for our next stage. Their were small hiccups as follows:

One member informed that he did not have any comments specific to this Sprint. I encouraged him to write about items in general about the project.

Some other members were worried that individuals would be identified as problem makers. I informed them that the environment was completely secure. Moreover, all postscripts were of same colour scheme and anonymous hence, no individual could be identified.

Whenever any item appeared which blamed any individual, as per working agreement, the item was rejected.

The non-believers were converted by the end of this activity. I could clearly see that those who were skeptical about the efficacy of the meeting, were also completely involved in the activities. I also ensured that every member had at least one representation on the board. This ensured that every member’s voice was at least represented once. It helped in opening people up for the next stages. The outcome of this stage was a set of issues which were taken as input for our next stage.  

        Gather Insights - (Activity - 5 Whys)

The reason behind choosing this activity was that it gives the ability to discuss an issue in-depth in a very short period of time. The time box for this meeting was 40 min as we were doing this activity for the first time and hence, needed time to collect our thoughts. Since there were 8 of us in total, we setup 2 teams of 4 each and divided the issues identified in previous stage in roughly half for use of each group. Following a Round Robin manner, each member of the group asked the next member 5 consecutive questions starting with 'Why’ regarding the topic at hand.

E.g, S: Why was dependability of members not guaranteed?

R: Because team members were not committed

S: Why were they not committed?

R: Because team motivation was low

S: Why was the motivation deemed low after previous Sprint review?

R: Because there was no commendation from MT members in the demo

S: Why was there no commendation?

R: Because MT members were only looking for failures and not for success

As can be seen from above discussion, in general after 4th or 5th 'Why' the core issue was found out. These were noted down. After 30 min I asked the activity to be concluded. For the next 10 min, we discussed and debriefed about what we had found and tried to collate the findings into similar themes. By this stage everyone was already committed to the activities. Since, the discussions were held in a Round Robin manner, everyone participated and I found their participation to be wholehearted. They believed that through this activity they could bring about change as they were at last finding out the core issues inhibiting the team from acting positively.  

  Decide What To Do (Activity - SMART Goals)

This activity was chosen as it allowed team to derive Specific, Measurable, Attainable, Relevant and Timely goals from the outputs of previous stage. The time box was set for 20 min for this activity. The team was asked to identify SMART goals around the themes we had found earlier. They were then asked for small, specific tasks to be created to meet the goal. They were also asked to create measurable criteria around the tasks and timeline along with specific action holders. The tasks were not only meant for team members, but for other stakeholders as well. I had already setup meetings over the coming week with other stakeholders in order to discuss these actions and help monitor them.The team was extremely enthused by the end of this stage and almost all members took initiatives for most tasks. Some tasks were immediately added to the Product Backlog as Product Owner was already available in the meeting and discussions were straightforward. It was decided that other tasks would be taken up based on the outcome of the activities of the team members during the intervening time frame. The output was taken as a live document which was to be revisited on every retrospective so that the progress could be visualized.

Closing the retrospective (Activity - Appreciation)

This activity was chosen as I wanted to end on a high. I asked every team member to take a min and then say an appreciative comment about any other team member or stakeholder who might not even be present. The time box for this activity was 10 min. It actually helped in members genuinely appreciating each others efforts and people believing in the positive energy of the team. The best outcome though was after the retrospective got over. Over the next day or so, visible changes were seen within the team. People started helping each other more effectively and generously. They started bonding as a tribe. And they also started disseminating some of the knowledge to other Scrum teams who had not done similar retrospectives. This gradually started changing the culture of the teams. -----------------------------------------------------------------------------------------------------------

Improvement in retrospective can be done using multiple set of activities. I have shown usage of one of them above. Any other mechanism can be used effectively as well. The efficacy of this activity is dependent on the facilitation and expectations. Remember to always ensure a setup which is fair to one and all and where everyone is encouraged to voice their opinion without fear. It is a continuous improvement activity which will gradually help introduce a new culture in the team and raise its level of productivity if done correctly. However, please ensure that while conducting these activities, the ethos of the organization is always kept in mind. Cultural change takes place gradually and cannot be enforced. 

Conclusion

Sprint Retrospective is one of the most important ceremonies held under Agile processes. If run correctly, it allows a team not only room for improvement but to bring about a culture of collaboration and road to success. The above template shows how I was able to help one of the scrum teams I was working with. Any alternate set of activities can be used just as efficiently if correctly implemented. However, the takeaways are the crucial nuggets of information which I derived from my experience, which can help out others who might be in a similar position as I was in.

[agilescrum]

A Coach Guide to Agile Testing introduces the Agile Testing Quadrants, how to use test automation and explains how software testers contribute in Scrum meetings.

A Coach’s Guide to Agile Testing is part of the nice series proposed to Agile coaches by Samantha Laing and Karen Greaves. This book provides a complete plan to run a workshop where members of a Scrum team can understand and learn the concepts behind Agile Testing.

[saugv]

Want to Walk the Agile Way? Here is How You Modify Your Test Strategies!

As a Scrum Master you have been leading a team which works on both software and hardware components. Your organisation has decided to move to Agile framework from the pure Waterfall model after looking at the substantial advantages Agile brings to the table. You along with the team have enthusiastically supported this move as it helps you deliver quality software without the bureaucracy of Waterfall model. However, there is one fly in this ointment. What do you do with the phase gate testing strategy that your organisation operates? And mostly manual testing at that! How do you modify or reuse these in order to maximize your product quality? If you want to know of a template for such a transition, read on.

 The Template 

Phase gate test strategy - Waterfall model has strict quality guidelines and metrics which need to be followed in both spirit and letter. If an organisation follows Waterfall model or its multiple variants such as Spiral model, V model etc, it will need to have a test strategy document which gives details regarding how the organisation through its test team plans to implement the quality control it desires.

                                            OR

As can be seen from above diagrams, regardless of which flavor is used, Waterfall has extremely stringent requirements regarding the test strategies to be used. Hence, you would be having an established order of testing activities provided in strategy document which should have:

Test planning

Test Environment setup

Test tools and setup

Test case review

Unit testing

Functional testing

System Testing

Integration testing 

Acceptance testing

Stability testing

Certification testing

Resource planning

 The various levels of testing is targeted at various levels of development. There might be additions to this but in general, these or a combination of these activities would be listed in the strategy document. Now let us add the complexities of phase gate development to above scenario.

Various levels of test cases are designed during the design phase. Validation team comes up with Integration, Acceptance, System and Feature Test cases based on the requirements and developmental activity. Once these have been accepted through design review process, the testing activity starts. Please note that Unit Testing as an activity is retained with development team. Once the development team delivers features in Phase gates, feature testing takes place. In case System testing can start earlier than the Final phase, it is also started early. Integration and Acceptance testing occurs where multiple modules from multiple teams are integrated onto a single Product line. Stability testing starts only when the Product is completed. This then is a short primer about Testing strategies used in Waterfall.

And herein lies our problem. Following Agile principles there are no phase gates. The items delivered by Scrum Teams are expected to be Product increments. Ideally speaking therefore, once Product Backlog Items (PBIs) are delivered by teams, they are expected to be working as a final Product which is shippable. Hence, the delivered PBIs should have been completely tested through all test variants (Functional, System, Integration etc). How do we bridge the gap between this expectation and the existing reality of Phase Gate testing already available before the transition to Agile is completed?

 Implementation

The implementation of our modification needs to be done in 2 phases -

1. Add slices of test variants - Each Sprint consists of PBIs which are READY. To resolve the test strategy dilemma you need to ensure that no PBI is termed READY till it has a thorough test plan. The test plan should be drawn up under the guidance of the validation members who are part of the Scrum team (after all the team is cross-functional). There are 2 very important functions of the Scrum Master here:

Help in guiding the team to include validation members during self-organizing activities to make it truly cross-functional

Ensuring that Scrum principles are adhered to, where, testing is not a separate activity and needs to be carried out by each individual. 

The guidance from validation member is crucial at this juncture. She needs to ensure that all PBIs which are targeted for the Sprint should have been properly tested. Slices of test cases from Functional, System, Integration and if possible Stability testing pertaining to the specific Sprint Backlog needs to be added to the Sprint activities. Although all Scrum members are responsible for carrying out the testing, Validation members should ensure that the Definition of Done (DoD) for each PBI should ensure correct evaluation of test cases. However, there arises a different problem. 

Let us say you are in the Sprint planning session. PBIs 1,2 and 4 are marked as most important by the Product Owner (PO) and are READY. As per prioritization principle, Sprint Backlog should be populated with these 3 items.

However, validation members inform that PBIs 1,2 and 3 mark a block which can be adequately tested (through all variants). PBI 4 is from a different block which cannot be tested as standalone. What should be done in this scenario? The solution is to get PBIs 1,2 and 3 READY and in Sprint backlog. It is more important to provide a shippable increment of correct quality than an increment of low quality. 

Please note however, that this issue can be corrected once you move to the next phase of transition.

There is 1 significant item overlooked in above scenario. Stability and Stress testing! And I have not mentioned those to be added onto the DoD because it might be a bit difficult to do so. Scrum members doing manual stability testing for 24 hours - 48 hours do not tend to generate correct information. Hence, it is up to the Scrum team to decide how to introduce Stability and Stress testing for the PBIs they deliver. It might be that they slice up this variant as well and accept testing for up to 4-8 hours under stress scenarios. Or it might be that they completely give up stability testing to a system team which keeps on doing this activity throughout all Sprints. My suggestion is to go for the first option and introduce a degree of stability for your delivered increments.

2. Automate testing - As a Scrum Master you have introduced mini test planning sessions as part of your Sprint planning. Hence, you are now providing high quality shippable increments as part of your Sprint deliverable. 

There are a couple of problems still seen which is visible through your teams outwards facing artifacts. 

The velocity achieved by the team is generally low or       lower than achievable. 

There are defects which still evade the Scrum teams.       This impacts overall bandwidth and health of Scrum teams.

We need to now move on to the next phase of test strategy modification. Test automation activities need to be supported by the teams to rectify above mentioned problems. The goal of this activity is to establish a process, where the scrum team member should be able to trigger a CI build and automated testing from his work machine after developing code. Once the testing is over, it should give the confidence to all stakeholders that the testing has been thorough and will not cause defects, regressions or performance degradation in the product. Automation is a huge subject, the scope of which cannot be completely dealt with in this blog. Following link for Agile Test Framework gives more details. Suffice to say that Automated testing is essential in releasing the full potential of your Scrum Team.  

However, please note that introducing Automated testing is a decision for the management team and not for Scrum teams. The effort required for setting up Automation in some cases will be equal to the effort for the whole project. Such a large effort may or may not be desirable by all stakeholders. If possible C-level management needs to be involved to understand the utility of such a movement and cost.

One of the biggest arguments in favor of such a move is that without automation any movement towards scaling agile would not be effective.

A mechanism to introduce automation is to also introduce it through a phased manner where initially, Automated UI testing is carried out, which progresses to Automated service testing etc. This reduces the effort used for introducing automation while ensuring the system gradually moves towards a fully automated test strategy.

 Conclusion

​Before we conclude, we need to deal with a remaining aspect of our test strategy we have studiously ignored so far. The subject of Certification testing was left as this almost always assumes a philosophy of its own. Those of you who have handled Certifications by running and passing Certification test suites will accept that this is the proverbial 'Bull-in-a-China-Shop'. It has the power to wreck your whole product if issues are not handled early. However, to simply start such testing requires almost all other aspects of the product to have been assessed for quality. What should the mechanism be for assimilating Certification testing within Sprint planning? 

Certification testing is too large for it to be broken into slices and taken into Sprint planning depending on PBIs taken in Sprint backlog. Instead, during initial stages of Agile transitioning, specific Sprints should be run for Certifications.

However, once Automation is setup, Test Driven Development (TDD) can be used quite effectively to handle Certification test suite within Sprints themselves. Certification test suites come with the advantage that test cases are defined in detail to start with and more often than not, ensure that system is more thoroughly tested than any given test specification.

In conclusion I must stress the point that given the right strategy, validation can be used as a great weapon to get verifiable quality for your Sprint increments. We just need to ensure that during transition the strategy does not get us unfocused from our goals

[saugv]

How to Handle Suppliers While Transitioning from Waterfall to Agile !

Here you are, a Scrum Master who has successfully made the transition from waterfall to agile along with your team. You have coached the team and facilitated self-organization. Your team has also started Sprinting regularly following a cadence and you are satisfied with the velocity achieved. All of a sudden you find that an impediment punches a hole in your perfect agile world.                                                                    

               Suppliers!!!

You believed that your movement to Agile would be mirrored by your Suppliers. However, they could not agree less with you!!

You could not convince them to move their process which has resulted in your team facing a huge impediment. They will need the supplier delivery for next Sprint which starts in 3 weeks. What do you do? If you would like to know of one of the templates to handle this situation, read on.

The Template

Back to the Statement of Work (SoW) - We now find ourselves in a position where Supplier has refused to move to an Agile process and will follow the waterfall model. Since the supplier is still on waterfall model, they would have signed a SoW with you giving the details of delivery along with other specifications. Let us go back to this SoW. Does it give a single delivery on a given date? Or multiple deliveries till the final version? It should not matter in which way the delivery is scheduled, although do make a mental note to ensure that next SoW should mention multiple        deliveries. These deliveries would be associated with a deadline. Let us now look at how to use this SoW to solve the impediment faced by the scrum team.

                                                       OR

Slice the salami - Let us imagine that the delivery pipeline has been setup with Supplier where deliverable goes through rigorous internal testing (on Supplier side) and acceptance testing (on Client side) before being integrated into the Production. If you require repeated deliveries from your supplier for every Sprint, not only would the Supplier have to setup a robust system to handle the regular testing and fixes but you would also need to setup a regular acceptance testing format. In all reality your Supplier would be reluctant to handle the initial cost associated with this setup. After all he has a perfect working system in place. How do we handle our requirement of Sprint dependencies in this scenario?

           If we go back to the Agile Manifesto we will find an important lesson:

            "Customer collaboration over contract negotiation“

 Let us discuss with the Supplier about the modalities needed to handle these deliveries.  It is time to slice the salami!! If we visualize the delivery  pipeline as a whole salami we need to slice it as thin as possible for our dependencies. However, the Supplier need not test each such delivery. We, as clients need to strengthen our test formats to support the Supplier and inform of any defects back to her. This helps both the Supplier and us by

Generating defects early

Providing regular deliverable for Sprint dependencies

The Supplier only tests those deliverable for which she has agreed as per the original SoW. This does not increase her cost hence, is a manageable operation.

However, now a key question crops up: "How do we synchronize the delivery slices to our Sprint requirements?”

Planning and Communication- This leads us to our last but most significant set of activities.

Planning - The Sprint planing and refinement activities should bring out those dependencies needed for next 2 Sprints. In parallel, Sprint planing should pull those Product Backlog items which can be completed using the high level delivery information from Supplier which should be taken as a guide. E.g, If you are trying to create a backend database solution through PBIs in current Sprint, while SoW says Supplier will be concentrating on the UI components, the Sprint will surely fail. One more question haunts us. When do do an intake? Will it be correct to do an intake whenever the Supplier provides a delivery, Surely not as this will lead to utter confusion. Imagine a situation where team is Sprinting with a Supplier sdk having API 1. In the middle of the Sprint, Supplier sdk with API 2 is taken in. It might result in complete Sprint failure. Hence, Supplier deliverable should be coordinated to be available either at the beginning or end of Sprint (for next Sprint) or at both times.

Communication - Regular communication with Supplier is needed in order to communicate the requirements of each slice. This should be done well in advance (at least 2 weeks). This will enable Supplier to get the requirements early and make any adjustment to his schedule. Feedback in terms of defects need to be reported every week so that Supplier is kept well informed of such issues. This might also help in getting early fixes to Critical issues seen in the sliced deliveries. Although not agreed to, after all no team wants to deliver crappy product to their clients!!

        To summarize, a hotline with your Supplier goes a long way in solving the impediment you now face!!

Conclusion

However, before we conclude, there is an important question. Wouldn’t above mechanism lead to waste? After all any organization tending towards Lean operation would find it an anathema to support an operation which leads to creation of waste. In my experience, having successfully implemented above operation, I found that it not only stops creation of waste but actually, removes it. The metrics we ran to prove it were defect counts (as delivery timeline and scope remained same). As we had an SoW which had phased delivery plan, defect counts were taken at each phase and in total. It was seen that regular input of defects to Supplier led to better quality software being delivered at each phase and the defect count in total reduced by 25% from projects where waterfall model was followed.

Hence, in conclusion, above mechanism can be taken as a template to handle suppliers without modifying the SoW during Agile transition of your scrum team.

[saugv]

CPU Information by Leonardo Ribeiro is now available on Google Play. Download via AppZapp http://ift.tt/1teI4P4

[saugv]

Compass and leveler by Dunji Mobile is now available on Google Play. Download via AppZapp http://ift.tt/1uM6qUt

[saugv]

Ncell by Ncell is now available on Google Play. Download via AppZapp http://ift.tt/1n0G2hx

[saugv]

Sniper Shooting: Killer 3D by Siren Echo is now available on Google Play. Download via AppZapp http://ift.tt/1o4FRBp

[saugv]

Stickman And Gun by RAON GAMES is now available on Google Play. Download via AppZapp http://ift.tt/1BsMcRq

[saugv]

WorldCraft 2 Survivor by Sariadabilisim is now available on Google Play. Download via AppZapp http://ift.tt/1mb6iWh