Linked In Question Posting

I just posted a question on LinkedIn,

The most interesting answer I got was a redirect to Chris Butler's Blog, It links to their "Project Anatomy" document. I like the ideas behind it.

To summarize:

"There are three specific steps dedicated to QA. The first two occur during the programming phase of the project, and the third occurs immediately after a site goes live. These QA steps are guided by involvement with almost everyone on the team, requiring a thorough review of every aspect of the site's design and functionality and producing a detailed report that we use to make any necessary corrections. However, there are two other QA steps in our Anatomy that aren't as immediately obvious, but are probably the most important."

The two items were Code Review and Integration. Code Review - is the Development group's role in Quality Assessment, and Integration is where Content Publishing and final fit and finish development occurs where the team as a whole is reviewing the deliverable.

They point to the key to QA is collaboration... hmmm do they have their own Scrum?

Very cool stuff - check out the other answers at my LinkedIn Question: Quality Assurance in a Web Design Firm - Where do you see it fit in?

Blog ya later!

Writing up a bunch - but nothing is read to go yet - ah the life of a QA person - perfection is not the goal for this blog I swear!

Well while I finish up my next one - check out James Bach at Google...

Dilbert Agile Training

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