Continuous improvement can range from the achievement of pragmatic, incremental change to widespread and radical transformation with contrasting degrees of success. Perceptions often vary on what it is, who does it, where to begin, how extensive it should be, how to measure progress, etc. Continuous improvement practices can be applied to achieve organizational, departmental, inter departmental, project team, functional team and individual improvement goals. It can be challenging to define and successfully achieve a continuous improvement initiative as a result of numerous pitfalls that can arise such as a lack of clarity of the goal, too large of scope, or insufficient management support. Even within organizations with well intentioned objectives for excellence, individuals or teams often become overburdened with the task at hand and time allocated for reflection and improvement is lost. In other cases, continuous improvement is viewed as an external entity that will bring much needed change, and individuals do not recognize the key role they play in the identification and implementation of change.

This presentation will look at the potential to identify, influence and implement continuous improvement initiatives regardless of your experience level or role and the importance of developing an effective and adaptive roadmap to achieving improvement goals.

You know you should be performing regular retrospectives, but you can't convince management or the team that it's a worthwhile investment of time ... Your team has been performing retrospectives every iteration, and they have become monotonous and have stopped producing valuable insights ... You've heard about retrospectives, but don't even know how to get started ...

The difference between a retrospective that is considered dull and worthless and a retrospective that produces team bonding and valuable insignts is in the planning and preparation. All effective retrospectives share a common structure: safety, review history, insight mining, prioritization, and concrete action planning. Explore the different ways that iteration and milestone retrospectives fill in this structure based on the type of learning that we need to draw out of the team at a particular point in the project. Variations on the activities that fill in the structure are described and experienced first hand.

Many teams have tried to implement agile software practices and failed. When you read about it, It sounds so easy. What happened?

Janet Gregory will share some of the lessons she has learned when working with teams that help agile teams be successful. She will talk about what to avoid, what is critical, and some basic practices that can make the difference between success and failure. One example of a critical practice is using the whole team approach, and what happens when your team keeps your test team separate.

In today's economic climate, many companies are cutting their costs by eliminating their training budgets. However, employees are expected to keep their skills up to date and gain new knowledge while embracing change. So what is the answer to this catch 22?

Instead of waiting for the training money to start flowing again, take this opportunity to create a learning environment in your workplace. This presentation will explore ways to create an environment where people are free to grow, explore, be challenged and love it.

Michelle will provide numerous career enhancing things to do to create a learning environment that cost almost nothing in monetary terms.Michelle will share some of the lessons she has learned when developing learning environments. She will give pointers about what to avoid, what is critical, and some basic practices that can make the difference between success and failure.

With test automation we never really stop learning. In this session Peter and David share their insights into implementing test automation in several different organizations - examining what has worked and just as importantly what has not. Topics covered will include:

• Test automation strategies
• Avoiding common pitfalls
• Selecting the right tools - open source or commercial
• Structuring test automation within an existing test team
• Collaborating with developers

These ideas will help you introduce test automation into your organization, reinvigorate ailing test automation projects, and magnify the benefits of test automation. Although ideas cannot be discussed in great detail due to time restrictions, there will be enough information for you to understand and then apply.

Collecting and reporting effective metrics can be a tricky business. Einstein captured it well when he noted "Not everything that can be counted counts, and not everything that counts can be counted".

Software projects have a history of measuring irrelevant and even counter-productive progress tracking metrics. The "Hawthorne Effect" should teach us that we will influence what we measure, yet companies continue to overtly track things like hours worked and lines of code written, unaware that they send the message of valuing long hours over results, and discourage simplifications and healthy refactoring. Quite often the metrics we want to track are intangible and subjective and so people tend to shy away from them.

More fundamentally, why are we even tracking these metrics? Is it to report on what has already occurred or help steer our future course? Often an imperfect view of the future is more useful than a perfect view of the past. In the real world, rear-view mirrors are much smaller than windshields for good reason, yet the accuracy of hind-sight and our attraction to certainty often creates too much of an emphasis on lagging, already occurred measurements compared to leading metrics. So we get fancy graphs of project spend and defect rates, but no better insights into what we should be doing differently in order to meet our goal.

In this presentation Mike will review many common project metrics and explain why they are largely misguided and counter productive. An alternative set of "Design Factory" metrics will be presented that are "simple and relevant to the true project goal", these metrics leverage the Hawthorne effect and focus on leading metrics to support smarter decision making.

Jobs, Jobs, Jobs...

How many interviews have you gone on, where the job you were interviewed for, was not what you applied for, and possibly, not the one you were hired for?

OR...

How many interviews have you conducted where the person on the Resume doesn't match up to the person you are interviewing?

What Happened?

In this presentation, Sabina will share her lessons learned as both an interviewer and an interviewee for QA Professionals; having reviewed over hundreds of QA Profressional's resumes (from across the country & south of the border), and conducted almost as many interviews, she will share her learnings from both sides of the fence.

• As an Interviewer; strategies for hiring the 'BEST' person for the job
• As an Interviewee, strategies for getting the JOB you want.

Karen Price's two decades of management experience have been in a diverse range of companies each focusing on IT and Quality Assurance. While these companies have included start-ups like Aventail, the large ERP vendor People Soft and industry leaders like Intuit, her management skills and dedication to quality have always been her main passions. Her work has included major software conversions, ERP implementations, continual process improvement, quality auditing, project management, system software development lifecycles and maintenance, and compliance projects such as Sarbanes-Oxley (SOX) and Financial Services Authority (FSA) in Great Britain.

As a manager of both projects and products, Karen has achieved success through team building and leadership. Coaching and mentoring hundreds of software professionals in Canada and the U.S., she has always maintained her dedication and commitment to quality. This has been amply demonstrated in her roles as a QA Manager and a proponent, early adopter, and practitioner of agile principles and practices.

The great and wise W. Edwards Deming said, "Does experience help? NO! Not if we are doing the wrong things." Over 20 years in IT and software development and 15+ years in a management role have resulted in a myriad of lessons learned. Here are some examples.

Testing tools and Rich Developer-Tester Interaction with Visual Studio 2010. Learn about the new testing tools in Visual Studio 2010 and how the generalist tester is now brought into the full Microsoft ALM platform. The new Test Professional product is a purpose built tool for test professionals to plan, execute and manage testing of your web, Windows Forms or WFP application. See how the rich defect reporting including IntelliTrace and other information about the execution and system under test helps eliminate the "I can't reproduce the bug" response from development. Test Lab Management can also assist in streamlining the setup and teardown of test labs for test.

As IT professionals we strive to deliver quality projects to our business stakeholders and end users. We focus on improving our project delivery by examining our development processes, encouraging continuous learning of team members, and spending time on project retrospectives to look for areas of improvement. Sometimes as we strive to improve things external to us we find that we cannot always effect change.

There is something we do have control and the ability to change, ourselves. I have found that as I continually strive to become a superstar tester, I am continuously challenging myself to grow. This presentation will examine what it means to "Cut the Mustard" and will challenge attendees to cut the mustard in their own ways. By using the same continuous improvement skills we often focus externally, we can refocus that energy inwards on ourselves and redefine our own excellence. Leveraging our role in the industry of software quality and focusing first on ensuring quality within ourselves and all we do, we can effect positive change and transformation within the teams we work with.

Key Points of the Presentation include:

• Examining traits of superstar testers and what it means to "Cut the Mustard";
• How the essence of continuous improvement can be leveraged for self-improvement;
• Analyzing the pathways for growth;
• Sharing inspirational stories of incremental to monumental team transformations by individuals through their actions.

It's time for our craft to grow up. Whatever the organizational structure of our development shops, it's time for us testers to get out of the Quality Assurance business.

If you're a tester, you're typically not allowed to change the source code. You can't control the scope of the product. You don't have authority over the budget, staffing, schedule, customer relationships, market placement, or the development model. So how, exactly, can testers assure quality?

Michael Bolton argues that testers cannot assure quality, nor should they try to do it. Decisions about quality and how to assure it are in the hands of those with the authority to make such decisions--the programmers who write the code, and the managers who run the project. Testing is not confirmation, verification, and validation of what we already know or hope to be true. Instead, testing is focused far more on exploration, discovery, investigation, and learning. In this view, when we're doing our best work, we're providing valuable, timely information about the actual state of the product and the project. We don't own quality; we're helping the people who are responsible for quality and the things that influence it.

It's time for our craft to grow up. Whatever the organizational structure of our development shops, it's time for us testers to get out of the Quality Assurance business.