Saturday, July 19, 2008
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)
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:
- 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.
- Proper name of an Agile methodology
- Named after the rugby term SCRUM -- a group responsible for picking up the ball and moving it forward.
- 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.
- 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.
- 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.
- In Scrum, a single person must have final authority representing the customer's interest in backlog prioritization and requirements questions.
- 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.
Daily Scrum Meeting
- A fifteen-minute daily meeting for each team member to answer three questions:
- "What have I done since the last Scrum meeting? (i.e. yesterday)"
- "What will I do before the next Scrum meeting? (i.e. today)"
- "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 methodologySo 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.
- Embedded QA (agilegamedevelopment.com)
- Succeeding with Agile (mountaingoatsoftware.com)
- Implementing Scrum (implementingscrum.com)
- Do we need QA in Scrum? (SQAForums.com)
Saturday, July 5, 2008
- On Time
- On Budget
- With a happy client (internal or external)
After the screaming in your head subsides (OH DEAR GOD NO IT'S IMPOSSIBLE, THERE IS NO WAY THIS CAN HAPPEN), you shake it off and see how you and your team can "get it done". Your management team thinks the "Waterfall" methodology is ancient and dusty and wants you to use one of the more flexible methodologies that they have read about recently, so you start surfing to read what they are about.
At a top level, you come across some intriguing development methodologies (Oh, there are more, but they all start looking similar very quickly):
- Agile - (from the Agile Manifesto)
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- An Agile method
- An Agile method
- Project-centric - "they provide managers with tools to monitor, prioritize, and control projects without specifying anything about how the software is built." (testobsessed.com)
"Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams with "just enough" ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders." (From Agile Modeling)
OK, the screaming in your QA head is probably starting again - and it comes in one word "HOW??" Have 4 deep breaths, and come back in a minute... Better? Good. Incremental in 3 weeks, hmmm - that doesn't sound like a fit. In 15 business days you need to understand what the client wants and make it. "Agile" is what your team needs to be, but the methodology sounds like nebulous and wishful thinking. When QA people get their hands on it (since there is no QA in the methodology theoretically), it then gets some structure to it.
That sounds a lot more like something that can be utilized by a team. So then I found Elisabeth Hendrickson. QA's role is supporting the development team in their goals and the customers in validating that "they got what they paid for". QA is part of the development process from beginning to end. Overall, it's all about embracing change and planning for maintenance. Her high level bullets to describe an Agile lifecycle are:
agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.
A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing. (From James Bach's Blog)
- Get Feedback
- Deliver Value
So, with my 4 week project, the team should sit down and break it into logical chunks. Each chunk is an iteration unto itself, and each can be designed, developed (including testing), and run by the client as it is completed. That to me is worth a try.
XP and Scrum are flavors of Agile from different perspectives (Dev and PM). I had tons of opinions on XP prior to this blog, both positive and negative (The founding father of XP, described QA as, "irrelevant in the brave new world of eXtreme programming") as for Scrum, I see terms like "manage" and "control" so that tickles my QA fancy, but it may not be as "agile" as one would like - so I will get back to you on that.
In the cloud world of Web 2.0 with 3.0 biting on its heels, how do you as a QA person bring some order to the hip methodologies that are the recent big buzzwords like Agile, XP, and Scrum to name a few. Agile truly is nebulous, but has some good ideas that can be transformed into goals and a development methodology tailored to your company. XP has tools for how to get it done from a design and development perspective. Scrum - looks promising, with its communication points to management, and I will be looking more into that over the next few weeks. The biggest thing I can see, is that with all of these methodologies, if you don't have your test group work throughout the iterative lifecycle, you don't have an Agile process :)
Night all... more Agile thoughts to come on how to actually do it in a project.
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!