OneStopTesting - Quality Testing Jobs, eBooks, Articles, FAQs, Training Institutes, Testing Software, Testing downloads, testing news, testing tools, learn testing, manual testing, automated testing, load runner, winrunner, test director, silk test, STLC

Forum| Contact Us| Testimonials| Sitemap| Employee Referrals| News| Articles| Feedback| Enquiry
Testing Resources
  • Testing Articles
  • Testing Books
  • Testing Certification
  • Testing FAQs
  • Testing Downloads
  • Testing Interview Questions
  • Career In Software Testing
  • Testing Jobs
  • Testing Job Consultants
  • Testing News
  • Testing Training Institutes
  • Introduction
  • Designing Test Cases
  • Developing Test Cases
  • Writing Test Cases
  • Test Case Templates
  • Purpose
  • What Is a Good Test Case?
  • Test Specifications
  • UML
  • Scenario Testing
  • Test Script
  • Test Summary Report
  • Test Data
  • Defect Tracking
    Software testing
  • Testing Forum
  • Introduction
  • Testing Start Process
  • Testing Stop Process
  • Testing Strategy
  • Risk Analysis
  • Software Listings
  • Test Metrics
  • Release Life Cycle
  • Interoperability Testing
  • Extreme Programming
  • Cyclomatic Complexity
  • Equivalence Partitioning
  • Error Guessing
  • Boundary Value Analysis
  • Traceability Matrix
    SDLC Models
  • Introduction
  • Waterfall Model
  • Iterative Model
  • V-Model
  • Spiral Model
  • Big Bang Model
  • RAD Model
  • Prototyping Model
    Software Testing Types
  • Static Testing
  • Dynamic Testing
  • Blackbox Testing
  • Whitebox Testing
  • Unit Testing
  • Requirements Testing
  • Regression Testing
  • Error Handling Testing
  • Manual support Testing
  • Intersystem Testing
  • Control Testing
  • Parallel Testing
  • Volume Testing
  • Stress Testing
  • Performance Testing
  • Agile Testing
  • Localization Testing
  • Globalization Testing
  • Internationalization Testing
    Test Plan
  • Introduction
  • Test Plan Development
  • Test Plan Template
  • Regional Differences
  • Criticism
  • Hardware Development
  • IEEE 829-1998
  • Testing Without a TestPlan
    Code Coverage
  • Introduction
  • Measures
  • Working
  • Statement Coverage
  • Branch Coverage
  • Path Coverage
  • Coverage criteria
  • Code coverage in practice
  • Tools
  • Features
    Quality Management
  • Introduction
  • Components
  • Capability Maturity Model
  • CMMI
  • Six Sigma
    Project Management
  • Introduction
  • PM Activities
  • Project Control Variables
  • PM Methodology
  • PM Phases
  • PM Templates
  • Agile PM
    Automated Testing Tools
  • Quick Test Professional
  • WinRunner
  • LoadRunner
  • Test Director
  • Silk Test
  • Test Partner
  • Rational Robot
    Performance Testing Tools
  • Apache JMeter
  • Rational Performance Tester
  • LoadRunner
  • NeoLoad
  • WAPT
  • WebLOAD
  • Loadster
  • OpenSTA
  • LoadUI
  • Appvance
  • Loadstorm
  • LoadImpact
  • QEngine
  • Httperf
  • CloudTest
  • Perl Testing
  • Python Testing
  • JUnit Testing
  • Unix Shell Scripting
    Automation Framework
  • Introduction
  • Keyword-driven Testing
  • Data-driven Testing
    Configuration Management
  • History
  • What is CM?
  • Meaning of CM
  • Graphically Representation
  • Traditional CM
  • CM Activities
  • Tools
  • What Is Software Testing?
  • Effective Defect Reports
  • Software Security
  • Tracking Defects
  • Bug Report
  • Web Testing
  • Exploratory Testing
  • Good Test Case
  • Write a Test
  • Code Coverage
  • WinRunner vs. QuickTest
  • Web Testing Tools
  • Automated Testing
  • Testing Estimation Process
  • Quality Assurance
  • The Interview Guide
  • Upgrade Path Testing
  • Priority and Severity of Bug
  • Three Questions About Bug
    Home » Testing Articles » Manual Testing Articles » Scrum in old fashioned software environments?

    Scrum in old fashioned software environments?

    A D V E R T I S E M E N T

    The "normal" Scrum project

    When I look around in the Scrum community, I wonder whether Scrum is only suitable for modern software development. All these shiny, new ways of making really cute, web- based software, with modern source repositories, automated unit and regression testing tools, and other fancy stuff. If you look at typical job postings for Scrum specialists, you see the same situation: It's all about modern, web-based systems and applications.

    How about legacy applications in an old-fashioned insurance company?

    Because I was working in a "classical" software environment, I wondered why Scrum was not more frequently used in those environments.

    Some excuses for not using Scrum include

    • "We always do it like this; there is no need for change!"
    • "I like the ideas, but I cannot imagine how we can deliver something in only three weeks time, even the regression test will take longer!
    • Our processes prevent us from using the Scrum methods, we have to do X, Y and Z, otherwise we will not succeed."

    I think there is a fundamental reason for the reluctance to adopt Scrum in those software environments, and it is exactly the reason why Scrum was invented.

    A typical example in a "classical" environment

    Before we go into details let me tell you a short story about test automation of letter production. In an insurance company, the focus on regression testing of the software system was very high, because all the standard letters, which were sent to the customers, had to be tested manually. They had to be inspected manually and have been visually compared to the former versions. It was obvious that the effort to automate this process would realize its ROI even in the first project when it was applied. Nevertheless the automation was never implemented. It had been scheduled into each project, but because of time constraints it was always de-scoped in favor of some more "real" functionality.

    How could this happen? Because the team who was able to implement the automation (the developers) did not get any benefit from it, and the team who was asking for the automation (the testers), was not able to implement it. Therefore it was delayed for years.

    So what and who caused the effort to fail?

    This question is not easy to answer. In every project the Project Manager made the right decision in de-scoping the automation task. It was always the right decision because it stabilized or even rescued his project. So if it was not the Project Manager's fault, who was to blame? Upper management should not be made responsible for the Project Manager's decisions, which are real day-to-day work and should never be discussed at their level.

    So, if nobody is guilty, then the process must be at fault. The established process leads to the situation where the automation task is always de-scoped. Also, it makes it less urgent than some other tasks in every project where it is included.. To summarize, there is no control in place that is able to monitor the effects of de-scoping the automation task in a global "cross project" view.

    What rules must be changed to get the automation task done?

    1. Obviously the testers must have the authority to request the development from the developers.
    2. The Project Manager must not be able to de-scope the task in favor of new requirements.
    3. At a minimum, upper management must be aware of any decision to delay the task

    If we think about the probability that we can to achieve the above changes, I'm not too optimistic. How should I empower the testers to prioritize the developers' work? How should I limit the project manager, so that he is not allowed to de-scope the task? How should I make these tiny project decisions visible to upper management? All these changes are prohibited by the process. The process' rules prevent them.

    And in a more "agile" environment?

    Now let's have a look at a Scrum set-up. How would this situation be handled in a Scrum organization?

    In a Scrum organization, the team would be cross functional, where all relevant parties participate. In this example the testers and the developers would be in one team. The team could not be successful if all tasks were not "done" at the end. And after the team has accepted a task it is responsible and stays responsible to get it done.

    In a Scrum organization the product owner cannot change the contents of a Sprint. He cannot de- scope a task in favor of another task during a Sprint.

    In a Scrum organization, if a task is part of a Sprint and it cannot be delivered, the managers are made aware at the end of the Sprint...
    In a Scrum environment the problems in our example are resolved.

    If it is this easy, why don't all organizations just switch to Scrum?

    It's all about agility

    The problem is the transition to Scrum.

    First, you need to have one team which is representing all aspects of product development and is capable to fulfill all the needed tasks.

    To achieve this, the established walls between the different roles in the software creation process have to be torn down. And those walls have been so comfortable for all participants. (it is much easier to blame process as opposed to at a colleague). And if a development is not yet ready, a tester has no problem complaining about delays in his plan..

    In my project experience I once tried to establish Scrum practices in a kind of a "silent roll-out". I wanted the team to work together across departments and roles, but I realized that this was not possible. You cannot build a "real" team without letting the team define its rules themselves. And you cannot change the rules that have been used by the established processes, without explicitly changing the processes.

    Second, you need to establish the Scrum roles. You need a "real" product owner, who knows how to play his role. You need a ScrumMaster who fights for his team and protects it from outside influences.

    Third, you need to transition to a time-boxed approach as soon as you start with Scrum. The time box is the most revolutionary change to the classical environment imaginable. Once, when I wanted to establish some Scrum-like practices in a project, I convinced the IT line manager and the project manager to have fixed development intervals of 3 weeks. We had a pipeline from development to testing and finally to user acceptance testing. But as soon as we got a delay in development, the project manager wanted to have the dates shifted to get more results as soon as possible. The benefit of having a time-boxed approach and agreed handover dates from team to team, was sacrificed for a potentially "more complete" next code drop.

    You need all of this to start with Scrum. And don't be overly optimistic. It will require discussion, training and good leadership to transition.

    What did we learn?

    As I stated earlier, I think there is a fundamental reason for the reluctance to adopt Scrum in "classical" software environments, and it is exactly the reason why Scrum was invented.

    In some organizations, the established processes are stabilizing themselves even if they are not helpful. There is no culture for changing the established processes.

    In some cases, the established roles in a "classical" environment do not take responsibility for the whole. There are situations where team members make excuses because something isn't their responsibility. Also, individuals are not empowered to make decisions.

    In "classical" environments, time and cost are less important than quality. Because of this approach, delays are widely accepted and at the end of the project de-scoping of less prioritized tasks is typical. This leads to projects whose status cannot be measured continuously.

    In other words: with Scrum you constantly measure your performance, empower your team, and constantly improve your processes. These elements of Scrum are crucial for an organization to improve its processes and to accelerate the release cycles and the features delivered in each release. Unfortunately the inability of the processes in "classical" environments to support these improvements leads to the difficulty in implementing Scrum in those environments.

    Implementing Scrum is hard work, but it's worth the effort.

    More Manual Testing Articles
    Previous 1 2 3 4 5 6 7 8 9 10 11 Next

    discussionDiscussion Center


    Yahoo Groups
    Y! Group
    Sirfdosti Groups
    Contact Us

    Looking for Software Testing eBooks and Interview Questions? Join now and get it FREE!
    A D V E R T I S E M E N T

    Members Login

    Email ID:

    Forgot Password
    New User
    Testing Interview Questions
  • General Testing
  • Automation Testing
  • Manual Testing
  • Software Development Life Cycle
  • Software Testing Life Cycle
  • Testing Models
  • Automated Testing Tools
  • Silk Test
  • Win Runner
    Testing Highlights

  • Software Testing Ebooks
  • Testing Jobs
  • Testing Frequently Asked Questions
  • Testing News
  • Testing Interview Questions
  • Testing Jobs
  • Testing Companies
  • Testing Job Consultants
  • ISTQB Certification Questions
    Interview Questions

  • WinRunner
  • LoadRunner
  • SilkTest
  • TestDirector
  • General Testing Questions

  • Testing Forum
  • Downloads
  • E-Books
  • Testing Jobs
  • Testing Interview Questions
  • Testing Tools Questions
  • Testing Jobs
  • A-Z Knowledge
    Study ABROAD ?

    Study Abroad

    Vyom Network : Free SMS, GRE, GMAT, MBA | Online Exams | Freshers Jobs | Software Downloads | Programming & Source Codes | Free eBooks | Job Interview Questions | Free Tutorials | Jokes, Songs, Fun | Free Classifieds | Free Recipes | Bangalore Info | GATE Preparation | MBA Preparation | Free SAP Training
    Privacy Policy | Terms and Conditions
    Sitemap | Sitemap (XML)
    Job Interview Questions | Placement Papers | SMS Jokes | C++ Interview Questions | C Interview Questions | Web Hosting
    German | French | Portugese | Italian