Forums

Dear all,

I read Scrum Guide to investigate scrum from a few of software development methodology concerns. But What made me confused is that, If I suppose Scrum to be a methodology, then why is that there are a dozen of topics that are not covered in scrum whilst software development methodologies are supposed to give a remedy for them?!

For example software testing is very vague in Scrum Guide, this guide only points out that at the end of each iteration product must be tested. But this never suggests any notion, tool or method to do so.

- for this specific purpose, is that the case that scrum doesn't got any test concept?
- and in addition, is scrum guide the only official document to be referenced to? I mean whenever people are talking about scrum, can we associate them with scrum guide or it has broader meaning?

Omid,

The "Scrum Guide" is the official document that defines Scrum and there are no specific guidelines for testing or any other engineering practices for that matter. However, in the section Definition of Done you will find the following:
"... Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together"

Exactly how you define "thoroughly tested" is up to the team and will vary. A team working with space shuttle software may have a different definition of "thoroughly tested" than a team writing software for internal use.

Creating a potentially shippable product increment after each sprint is a challenge and it will make the need for good engineering practices highly visible. Exactly what techniques to use is up to the team.

+1 to what Fredrik said, and I would only add that Scrum is not a methodology. It is a framework within which multiple techniques, practices, and methodologies can be used. The Scrum Guide, the official definition of Scrum, is simply a framework, with intentional gaps or variation points to let the implementer decide what is best for their team/product context.

UNSUBSCRIBE



From: ScrumForum@scrum.org [mailto:ScrumForum@scrum.org]
Sent: dinsdag 11 december 2012 6:17
To: annemoni@ziggo.nl
Subject: RE: Scrum got specific ways for testing software? [00000235:00000807]

Hi Omid,

As Charles has said, Scrum is not a methodology hence it is not prescriptive. You should find the missing pieces and find what is important for your software yourself and plug it in the Scrum framework.

+1 for Fredrik and Charles. The only thing I want to add to Charles is, that the last sentence gives me the feeling of having to decide for the team, what the should do as "good engineering practices", but for me it is the team, that should come up with those practices (with my help, for sure)

Br,

Philipp,

Is it really common for the team to drive this change? Especially if the team has not already adopted good practices before they try to adopt scrum. The SM should encourage the team to strive for technical excellence but I wonder how common it really is that this is driven by the team.

Thanks everyone for sharing your knowledge here.
Now I think I have a better understanding of what scrum is and how this can be helpful in transforming to agile processes, But still there are many questions to be answered.

Kind Regards
Omid Najaee

Phillip,

The only thing I want to add to Charles is, that the last sentence gives me the feeling of having to decide for the team, what the should do as "good engineering practices", but for me it is the team, that should come up with those practices

Good point, Phillip. When I said "Scrum implementer," I was referring to the Scrum team as implementers, not any one person. In the specific case of testing, I would say that it's really up to the Dev Team as to how to handle it.

Fredrick

but I wonder how common it really is that this is driven by the team.

This one is a bit tricky. The Scrum team, if they are held accountable for quality and bugs escaping into production, will often drive better technical and testing practices. It can also come from outside of the team as the organization realizes the lost business value due to low quality practices. In the end, though, the org needs to give the Scrum team enough room to self organize and specify their own release dates and such so that they can take the time to meet and/or improve their Definition of Done. If the org continues to hammer at the team for missing deadlines, then quality is usually the first thing to get sacrificed. In fairness to the org, the team needs to get better at proposing realistic release dates, too. OTOH, if the org doesn't listen to the team, then the (brow)"beatings will continue until morale improves."