Gerson R. de Almeida

2014/10/01

SCRUM, REALLY!? In Software and Test development a word in great vogue nowadays is SCRUM (sometimes confused

with Agile).

However, do we really understand all the implications of the method ?

Can we do more or less using this framework ?

Can we use something else or even can we still perform with old methods?

To me Scrum is great, but there are issues outside the defined framework that needs to be addressed by

other means and understandings.

In this paper I describe some ideas that I have thought, learned and developed. I am sure that many will

have some arguing points (good or bad) on those ideas and I would like to hear from.

1

Introduction

Many years ago, when I had little experience with Scrum,

someone told me that the name ‘SCRUM’ was originally from

the Rugby game; as a normal curios tester I checked in some

dictionaries and web pages to confirm this information, and to

my surprise, there were two main definitions (maybe soon, it

will be added the Software related one, making three). I guess

if you never looked for it, you will also be surprised, it is

almost a joke made on request.

One of the main idea in the Agile manifesto is to bring the focus back to the real points in software

development: the customers, the product and the producer (the team). However we must not forget that

it is still very important to know about processes and techniques before trying to implement an agile

(scrum) process, otherwise we will incur in a great risk of trying to reinvent the wheel (again..), or worse,

trying to force wrong wheels in wrong cars.

Below I give some of my reasoning’s about the need of processes and extra thinking. And have tried not

to be led by the ‘party feeling’ of some in the agile community and vendors.

In testing, there is no such thing as a silver bullet.

We can never kill the Werewolf, but we can seriously cripple him.

Sprint, sprint, sprint… or Marathon

Any runner athlete can tell that to run a sprint is a lot different from running a marathon. And it requires a

focus mindset, planning and preparation for the race. The same applies to Software development on

regards to what and how it should be done.

Having projects without knowing the past and not seen the future is good as dancing in a forest, we may

see our steps, but we don’t see the trees or the paths. For this reason a more stable and organized process

is necessary. The use of Scrum sprints to produce software is a good practice; if you are running small,

short or self-containing projects, but as we move to large and long developments, something more is

necessary: the long run planning.

This I would like to call “Marathon”, a holist view of a project and/or product, that need to be done in a

controlled way. To my view this is only possible to achieve if we use some structure management

processes (something like RUP, ITIL, Prince2, etc.). My main point here is that we need to have this

Marathon planning (the Holist approach), and this cannot be done by simplistic approaches. And do not

believe that scrum of scrums will fix the problem (it can temporarily, maybe), but is not a solution for the

main problem: Planning and Traceability.

Ok, you may say, we have the PO and he is normally someone that collects the User Stories (on our old

days, we called it Requirements) and set priorities, and we know how hard is to have good and defined

2

ones. There are also the needs for different visions and positions, as stakeholders are so different. And

what about customers, regulatory offices (ISO, Government, Tax, etc.).

And do not forget that changes are a constant and the only certainty in the development process.

My point is, The backlog is not enough, we need to have a better way to plan and control the whole

project from start to end, not from one sprint to another.

The Rapids

When we compare Waterfall and Scrum closely, we can see that they are not that different after all.

Almost everybody talks about Scrum as it was a new approach, but in reality it is a new dress for an old

problem: How to develop software faster.

First let’s see the definitions:

The waterfall method

The waterfall model is a sequential design process, often used in software development

processes, in which progress is seen as flowing steadily downwards (like a waterfall)

through the phases of Conception, Initiation, Analysis, Design, Construction, Testing,

Production/Implementation, and Maintenance. http://en.wikipedia.org/wiki/Waterfall_model

Scrum Framework

Scrum is an iterative and incremental agile software development framework for

managing software projects and product or application development. Its focus is on "a

flexible, holistic product development strategy where a development team works as a unit

to reach a common goal" as opposed to a "traditional, sequential approach". http://en.wikipedia.org/wiki/Scrum_(development)

The truth is that both scrum and waterfall have a lot in common. Scrum is a series of small iterations (the

sprints) that are basically sequential by nature. We must have the Backlog before choose the Sprint-

backlog; we need to create some design before code and need to have some design (and maybe code) to

be able to test. The demo is the realization part. And we start all this process again.

These cycles or iterations are in reality making the whole process a sequence of mini-waterfalls. Then,

when you taking together the sprints, we will then have the Rapids.

3

There is no such thing a Scrum team

The people who advocate the use of scrum likes to tell us that there is only one team, and all team

members can or should be able to do all the tasks. The problem is that does not leave space or take in

consideration the different competences and specializations in the team.

The truth is that in a scrum team there should be at least 2 sub-groups: the first to implement the tasks and

the second to validate it. This does not mean that they are separated groups, isolated or antagonistic; It

only means that their focus is going to opposite directions (even though many times competences are

overlapping), making their work and results also to have different results.

I advocate a creation of a “Yin and Yang” concept in scrum, that is, the Development and Test are

to work together (and separated) for a common goal.

Below I present a schematic example on how we believe the team should work. When Development is

creating design, Test is creating TCs and checking documentations, during the coding phase, there is the

test execution.

Also, there are the problems with how to address some regression test, smoke testing, test of delivered

product at sprint demo, etc.

The 100-50% staff rate is an approach to show that for every 2 developers 1 tester is needed (but of

course, your project should decide it). This can implies that when a task takes 100 points (our hours, etc.)

for developing, the test will take 50 points.

4

2 for 1 Burn down

Following the previous reasoning, the burn down should be a combination of Development and Test as

parallel activities that are interdependent and part of a common effort.

Below I show one example on how we can approach this. Note that the main important point is the same:

to get the total effort to zero, but the burn down curve is the combination of both efforts. This can be more

complicated and time consuming, but it will show very clear the stages of both areas and its progress.

Also, I have added the notion of testing after code freeze, before and after demo. This is something

normally neglected by the community and I regard as source of bugs and delays for the next sprint. The

reason is that the demo is ‘never’ complete, and almost always has a last minute change, or worse, some

ghost presentation glitch.

Testing the Demo

If we assume that the test team has done all the necessary tests during the sprint, and the development

team has implemented and/or fixed all the issues, then the demo should be a breeze with no glitches. But

we know that until the last minute before the demo (and maybe beyond that) there will be still some open

questions or some last minute changes and implementations.

What we are going to do then? should we test more? Leave to the next sprint? Forget? (See the The

cycle of life)

My point is that the demo is not the final point for the test team; There are still some work to be done.

The priority should be to verify the last minutes changes, and may need for a post-testing time after the

demo day. This effort can be included in the next sprint, as a task, and making a small confusion, as the

5

team is still testing the ‘Sprint 1’ during ‘Sprint 2’. If some issues are uncovered during this task, what

will be the process? Most likely a bug issue will be added and need to be fixed (in which sprint?)

One solution could be to define a code freeze before the Demo day, and some questions need to be

answered: is the time enough, can all tests be done, code freeze is equal demo code, what development

will do during this time, etc. As you see, even this approach will not assure that the sprint delivery will be

ok and without bugs and misses.

Recurring tests in scrum

What about regression tests. When and How do we need to do it?

Surely it will take time for the test team to plan and perform it, and every new sprint the test team will

need to evaluate and redefine the test set. This is not a task that is related direct to a sprint, but an ongoing

process that is relevant to the entire project (and maybe after that).

Another issue is the Smoke test. I prefer it not to be part of the regression test, but a specific set designed

to prove the health of the delivery in order to star testing. During a Sprint it may be required to execute it

many times depending on the frequency of the released builds. This process needs to be evaluated,

planned and executed as part of the normal test process.

And what about Performance, Integration and Maintenance tests, these are not some tasks that can be

defined in a Sprint (normally), as they are more a continuous process and will certainly overlap many

sprints.

6

Scrum grooming

http://www.mitchlacey.com/intro-to-agile/scrum/release-planning-grooming

http://www.scrumalliance.org/community/articles/2011/march/how-to-hold-an-effective-backlog-grooming-session

One of the problems I have seem is the time and effort used to plan the next Sprint, called “Sprint

planning”. This sometimes take a day (and I have seen it takes 5 days). The idea is strait forward, the

team gets together , look in the base line and choose the top priority tasks for the next Sprint. Based on

the velocity, the team will know how much it can do. Clear and easy!

The problem is that, normally, almost no one in the team know about the next tasks and it’s needs, which

will need clarification. The points attributed to each task is therefore very empirical and based on gut-

feeling. Later in the process someone will need to clarify it, collect more information about the

implementation, test and other correlated needs.

My suggestion is to revert this time to a task done during the previous Sprint, having some members from

the team to get together with the PO and some others stakeholders, to choose and clarify the tasks for the

next Sprint, as well giving a preliminary point and collecting related information needed, like:

Development and Test environment, documentation, extra information from other projects, POC, etc.

My assumption is that in the end of a Sprint some people can be allocated to these tasks, as there is

probably not much more to do, the tasks are already under development/Test and the extra time needed is

already planned in the Sprint BL.

7

A good way to think when planning to do anything , these verbs are cyclical and part of the work (do and

repeat):

And always start the Sprint planning with a “Haka” dancing ;-)

http://www.bing.com/videos/search?q=rugby+haka&docid=608003589373233290&mid=0E93E0F3B9DC79A2

0F650E93E0F3B9DC79A20F65&view=detail&FORM=VIRE5#view=detail&mid=F563F188315908CBF8E0F

563F188315908CBF8E0

Are you the green, the white or the boll?

When doing scrum it is useful to think about the rules of a game.

As in rugby, we must understand the concepts of the game and

apply it to our profit; otherwise we can be defeated by a few simple

and commonplace problems. Here are some of the simple questions

we must answer before any attempt is made to implement scrum:

What side are we playing for?

o Customers, Market, Sales, our own job, etc.

What team do we support?

o What are our customers, internal and external?

Do we know the rules?

o Can we implement it, change, evolve, and combine?

o Have we competence in the techniques needed?

Are we trained enough?

o Training is never enough. Do we have planning and time to do it?

In a nice blog by Kurt Christensen “When is Scrum Not Scrum? “ (2007 - Yeap, that old! -

http://www.infoq.com/news/2007/02/scrum-not-scrum ), he points to some ideas that we cannot disregards.

Below I present these points. Try to imagine if those are applicable to your process and if you can come

with contra-arguments before you go and read his blog.

Why

What

How

Who

When

Where

8

Product owners are part of the team

Two-week sprints

Tasks are not measured in hours

Use of task boards rather than spreadsheets

Backlogs on the wall

Estimation meetings

Insistence on agile engineering practices

The Scrum Master role is not always necessary

Never mind the test plan

Think about that: How long takes to write a Test plan and Test strategy?

The problem is that normally it takes a long time to write, compile and review those documents, and in a

Scrum environment, it will be more than one sprint, and worse, probably no one will care.

Do we really need those docs? I guess not, the main reason is because we already have all the information

we need in Scrum, it is only a matter of looking in the right direction. Of course, the work evolution,

needs and learning will change the results, and we may need still to write a kind of documentation, but

only to keep the results and information in one place (which are dynamic)

Below I present the main points to be addressed by a Test plan, and were they are in the Scrum

framework.