What is Scrum?

Scrum is a rugby football term. The rugby metaphor was first used by two knowledge management experts in the mid-1980’s to describe a way of thinking about new product development1. It was recognized that the existing “relay race” model of handing off partly-finished work from one functional group to another in a linear fashion conflicted with the goals of maximum speed and flexibility. To meet these goals new product development required a more holistic approach: an approach more aligned with the game of rugby where a whole team works collaboratively to achieve a goal.

Software development, by its nature, is always concerned with the creation of “new product” so it was natural that the rugby metaphor eventually became adopted by the software industry, and the term Scrum was applied as a label. Scrum has often been referred to as a “software process” or a “software methodology” but it is neither. Scrum is much less than this, and at the same time so much more.

In a nutshell, Scrum is a simple approach to the management of complex problems. Scrum is a state of mind; it is a framework and a way of thinking that is firmly grounded in two key principles: empiricism and self-organization.

Empiricism refers to the continuous inspect/adapt process that allows both workers and managers to make decisions in real time, based on actual data, and as a result respond quickly to ever-changing conditions in the surrounding environment, e.g. the market place.

Self-organization refers to the structure of the teams creating the product of work. Small multidisciplinary teams are empowered to make the important decisions necessary to i) create high quality product and ii) manage their own processes. The thinking here is that those doing the work know best how to do the work. These teams work in a highly interactive and generative way, emerging the product through continuous dialog, exploration and iteration.

In Scrum organizations management hierarchies tend to get leveled and development teams have a more immediate and direct contact with customers. The work environment becomes less command-and-control and more collaborative. Regular, open dialog is encouraged over extensive documentation, and negotiated agreement is preferred to formal and impersonal contracts of work.

The qualities of openness, honesty and courage are fostered at all levels, and individual gain becomes secondary to collective advancement. A Scrum environment is a supportive one, where people at all levels show respect and trust for one another. Decisions are made by consensus, rather than imposed from above and all knowledge is shared in a fearless and transparent way.

Scrum goes against the grain for most companies in the software industry, where a phased approach coupled with a high degree of micro-management, and an insistence on defined processes and extensive documentation have been the norm for over thirty years. Many companies rely on fear and money as the key motivators for their workers. This approach has shown short-term success but more and more companies are beginning to understand that it is not a good long term strategy. Nevertheless, the concept of changing to something as radical as Scrum strikes terror into many executive and middle-management hearts.

Scrum is still at the early-adopter stage. It will take many years for the majority of companies to recognize the benefits of creating more trustful and compassionate workplaces. Without such change many software companies will likely sink under the sheer weight of their heavy processes, and overstaffed workforces. Others-those who dare to embrace the lean, lightweight, agile approach of Scrum-stand a greater chance of surviving and prospering. For those who turn to Scrum, and fully embrace it, a reversion back to the old way of working becomes unthinkable. A paradigm shift is occurring in the workplace, and Scrum is an important part of that shift.

Some Classic Testing Mistakes

The role of testing

• Thinking the testing team is responsible for assuring quality.
• Thinking that the purpose of testing is to find bugs.
• Not finding the important bugs.
• Not reporting usability problems.
• No focus on an estimate of quality (and on the quality of that estimate).
• Reporting bug data without putting it into context.
• Starting testing too late (bug detection, not bug reduction)

Planning the complete testing effort

• A testing effort biased toward functional testing.
• Underemphasizing configuration testing.
• Putting stress and load testing off to the last minute.
• Not testing the documentation
• Not testing installation procedures.
• An overreliance on beta testing.
• Finishing one testing task before moving on to the next.
• Failing to correctly identify risky areas.
• Sticking stubbornly to the test plan.

Personnel issues

• Using testing as a transitional job for new programmers.
• Recruiting testers from the ranks of failed programmers.
• Testers are not domain experts.
• Not seeking candidates from the customer service staff or technical writing staff.
• Insisting that testers be able to program.
• A testing team that lacks diversity.
• A physical separation between developers and testers.
• Believing that programmers can't test their own code.
• Programmers are neither trained nor motivated to test.

The tester at work

• Paying more attention to running tests than to designing them.
• Unreviewed test designs.
• Being too specific about test inputs and procedures.
• Not noticing and exploring "irrelevant" oddities.
• Checking that the product does what it's supposed to do, but not that it doesn't do what it isn't supposed to do.
• Test suites that are understandable only by their owners.
• Testing only through the user-visible interface.
• Poor bug reporting.
• Adding only regression tests when bugs are found.
• Failing to take notes for the next testing effort.

Test automation

• Attempting to automate all tests.
• Expecting to rerun manual tests.
• Using GUI capture/replay tools to reduce test creation cost.
• Expecting regression tests to find a high proportion of new bugs.

Code coverage

• Embracing code coverage with the devotion that only simple numbers can inspire.
• Removing tests from a regression test suite just because they don't add coverage.
• Using coverage as a performance goal for testers.
• Abandoning coverage entirely.