Scrum of the Earth? Scrum and QA.

Scrum?

First off - what the heck is Scrum? We talked earlier about it being an Agile methodology that seemed to be more Project Management based - because of that, there must be some more documentation and process about it. So, I did some more digging and found out the following about Scrum (taken from: controlchaos.com)

• Scrum is a wrapper for existing engineering practices.
• Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
• Scrum is a process that controls the chaos of conflicting interests and needs.
• Scrum is a way to improve communications and maximize co-operation.
• Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
• Scrum is a way to maximize productivity.
• Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Next, are the Scrum terms, since they have a bunch which I have not seen before. I will "borrow" the definitions from the Scrum Alliance:

1. Scrum
• Proper name of an Agile methodology
  
• Named after the rugby term SCRUM -- a group responsible for picking up the ball and moving it forward.
2. Sprints
1. An iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a functional increment of product must be produced each sprint.
3. Burndown Charts
1. Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward. The Scrum books define a sprint burndown chart as a place to see daily progress, and a product burndown chart as where to show monthly (per sprint) progress.
4. Backlogs
• Product Backlog: The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements.
• Sprint Backlog: Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.
5. Product Owner
• In Scrum, a single person must have final authority representing the customer's interest in backlog prioritization and requirements questions.
6. Velocity
• In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
7. Daily Scrum Meeting
• A fifteen-minute daily meeting for each team member to answer three questions:

1. "What have I done since the last Scrum meeting? (i.e. yesterday)"
2. "What will I do before the next Scrum meeting? (i.e. today)"
3. "What prevents me from performing my work as efficiently as possible?"

• The Scrum Master ensures that participants call sidebar meetings for any discussions that go too far outside these constraints.

OK - so here goes for a summary of Scrum now:

Scrum is an Agile methodology

So here we are, a whole lot of terms, and I can't see anything that calls out QA. The more I read - there are two schools of thought, QA as part of the Scrum team from beginning to end, and the other sees QA as an independent group that tests after the Scrum team thinks they have a deliverable product. If you choose the latter, I personally don't think you are performing a Scrum methodology - it's based on a team structure. The moment there is a "Throw over the wall" mentality, it's Waterfall and not Agile.

So, we shoot for Agile, what are the next steps? What do you do to get it going?

• Company "Buy-in" - this is the biggie. No one will disagree with flexible collaborative design and development. But the practice of it - that's another story. No company can work organically and scale.
  
• Training - Get everyone talking the same language and starting on the same foot. new employees should participate in trainings right after they start - to drink the company Kool-Aid and learn how the processes work at your company.
• Restructure - Your "teams" need to be embedded with every participant to the project including the client. The forming of a dedicated team to the project raises the internal accountability, and eventual release quality.
  
• Communication - Meetings are minimal - because the team works together. Reporting is not gut-driven, but milestone, budget and roadblock based. The client is brought in at the end of each sprint - eliminating long periods of time without seeing progress and therefore improving perception and customer satisfaction.
  
• Change the perception to QA being just another "developer" on the team. Code is written with the requirements in mind and tests are as well. Because the project contributors are "embedded" with each other on the team, tests are communicated during coding as an "open book test" and issues can be found before the code is delivered to QA to review. Higher standards are created.

QA can do a lot of things on their own to help guide and promote quality deliverables and customer satisfaction, but without a total team effort, it can be tough and sometimes adversarial. Building the blocks for buy-in are my next steps. What are yours?

Informational Links:

• Embedded QA (agilegamedevelopment.com)
• Succeeding with Agile (mountaingoatsoftware.com)
• Implementing Scrum (implementingscrum.com)
• Do we need QA in Scrum? (SQAForums.com)
  

Books:

• Agile Software Development with SCRUM

Software:

• TargetProgress
  

Quality Assurance Blog - Why the Heck Would you do that?

I have always said that you do not join the field of QA for the hugs. If you do your job well, people wonder why you are there at all, and if you miss one thing, they wonder why you are there as well.

I joined the field of QA by accident. I was hired in my early 20's to be a developer for the Mac version of an existing application for managing Head Start children's information. I had never written code outside of my Comp Sci classes in college - this was my first chance in the real world. I was TERRIFIED. The fear of failure was humongous. They decided to not go with the Mac version, and asked me to go into Tech Support before I could even start. I was relieved.

In Tech Support, I helped design a support ticketing program with the lead engineer, and started the beta programs, testing the new releases by myself, and then with sample client groups - I LOVED it. I knew where things would probably break, I understood the code, I understood the client. It was the perfect job.

I then moved to new companies with established QA groups. I learned the methodologies that I knew naturally and understood how and when they were used through study and training. Using the word "training" loosely, I learned test methodologies through trial and error in the field.

My career in QA has gone from beta tester to QA Director. I now spend most of my time looking for ways to show how cost effective testing can be. I believe in the need for internal audit and checks and balances. I also think that the most important role for QA is to communicate to the business the accurate status of the product being released so that there are no surprises. Risk communication and mitigation is the key.

In this blog, I hope to chat about what QA can achieve, get some of your opinions from the ether-world of the internet, share practices, links and books as well.

Please come back soon for more!

-KZ