Conference Presentations

Are We There Yet? Defining "Done"

"Are you done yet?" The answer to this question may sink your career, your team, and your project. If you respond with a "yes," you may be forced to take on additional work you can't handle. If you say "no," you may be branded as someone who can't get things done. Mitch Lacey notes that this innocent question is asked countless times on almost every software project. Establishing an upfront, common understanding of "done" can save teams and businesses countless hours of rework, process-thrash, unclear communication, and hidden work. Mitch describes what a "done list" is, how it adds value, and the value it communicates to stakeholders. Mitch takes you through an exercise on how to establish a common understanding of done and provides an exercise that you can use with your project teams.

Mitch Lacey, Mitch Lacey & Associates, Inc.
Overcoming the Pitfalls of Transitioning to Agile

If you've been trying to change your organization so that your projects are more agile, you may have encountered several problems-one is that it's difficult to have product management, senior management, and functional managers work together to lead in a way that makes sense for your agile project. You're also probably working with other parts of a large program that isn't agile; you have a geographically distributed team; your management wants to know at the beginning when the project will end; or you might have a project team that does not share a common vision of what "done" means. Johanna Rothman explores common organization, management, team, and individual team member issues. She offers suggestions for making the changes more acceptable and helping people work with you in a way that enables your projects to succeed.

Johanna Rothman, Rothman Consulting Group, Inc.
Seven Years Later: What the Agile Manifesto Left Out

Although the Agile Manifesto has worked well to help many organizations change the way they build software, the agile movement is now suffering from some backsliding, lots of overselling, and a resulting backlash. Brian Marick believes that is partly because the Agile Manifesto is almost entirely focused outwardly—it talks to the business about how the development team will work with it. What it does not talk about is how the team must work within itself and with the code. Even though those omissions were appropriate then, now more is needed. Teams starting agile need to know that more discipline is required of them, and that discipline is fruitless without a strong emphasis on skills. Teams need to recognize that success is not just fulfilling requirements. It is also increasing productivity and decreasing the consequences of mistakes.

Brian Marick, Exampler Consulting
Decisions, Decisions, Decisions

If you're working on more than one project at a time or if your managers are asking you to do so, it's time to make some decisions. Not every project should be started or finished, and certainly no one person or team should work on all projects at the same time. The organization needs to make some decisions about whether to commit to a project, kill it so it doesn't interfere with other projects, or transform it so it can succeed in a reasonable time.

Johanna Rothman's picture Johanna Rothman
Questions You Should Ask

It's a technique children and teenagers have mastered: asking "why" until they get to an acceptable response (or until we're too tired to continue answering). Find out how Michele Sliger uses a similar approach designed by Six Sigma to drill down into the underlying cause of any problem within software projects. She then continues the inquisition with a series of other questions in order to find out how these problems affect business value and technology. Read on to learn what these questions are and how you can start using them to find out why things aren't going as planned.

Michele Sliger's picture Michele Sliger
Going Mobile: The New Challenges for Testers

Mobile device manufacturers face many challenges bringing quality products to market. Most testing methodologies were created for data processing, client/server, and Web products. As such, they often fail to address key areas of interest to mobile applications-usability, security, and stability. Wayne Hom discusses approaches you can use to transform requirements into usability guides and use cases into test cases to ensure maximum test coverage. He discusses automation frameworks that support multiple platforms to reduce test cycle times and increase test coverage, while measuring and reporting at the different phases of the software lifecycle. Wayne presents case studies to illustrate how to reduce test cycles by up to 75 percent. He demonstrates solutions that have helped providers of third-party applications and services manage testing cycles for multiple mobile device releases.

Wayne Hom, Augmentum Inc.
Database Locking: What Testers Should Know, Why Testers Should Care

Database locking is a complicated technical issue for some testers. Although we often think that this issue belongs in the realm of the developer and the DBA-"It's not my problem"-database locking is the enemy of functional and performance testers. As Justin Callison can personally attest, locking defects have led to many disasters in production systems. However, there is hope! Justin sheds light on the problem of database locking, how it varies among different platforms, and the application issues that can arise. Armed with a new understanding of database locking, you can develop effective testing strategies. Join in and learn about these strategies: designing explicit locking tests, ensuring appropriate test data, implementing sufficient monitoring, and combining manual with automated testing to avoid disaster.

Justin Callison, Peak Performance Technologies
STARWEST 2008: What Price Truth? When a Tester is Asked to Lie

As testers and test managers, our job is to tell the truth about the current state of the software on our projects. Unfortunately, in the high-stakes business of software development, often there is pressure--subtle or overt-to distort our messages. When projects are late or product reliability is poor, managers' and developers' reputations-and perhaps even their jobs-may be on the line. Fiona Charles discusses the importance to testers of refusing to compromise the truth, recognizing a potential cover-up before it occurs, knowing the legal position around securing project information, and developing a strategy to maintain integrity and still get out alive.

Fiona Charles, Quality Intelligence Inc.
STARWEST 2008: Five Things Every Tester Must Do

Are you a frustrated tester or test manager? Are you questioning whether or not a career in testing is for you? Do you wonder why others in your organization seem unenthusiastic about quality? If the answer is yes to any of these questions, this session is for you. Julie Gardiner explores five directives to help testers make a positive impact within their organization and increase professionalism in testing. Remember quality-it's not just time, it's time and quality; it's date and quality; it's functionality and quality. Learn to enjoy testing and have fun-the closest job to yours is blowing up things for the movies. Relish the testing challenge-it's you against the software and sometimes, it seems, the world. Choose your battles-take a stand on issues that are vital and let the small things go. And most importantly, remember that the only real power we have springs from our integrity-don't sell that at any price.

Julie Gardiner, Grove Consultants
Has the Time for the Adversarial Organization Passed?

The concept of an independent test organization is considered a "best practice" by many experts in the industry. Is this degree of autonomy actually a good thing in the real world today? In such a structure, some testers can only play "Battleship" with the delivered software, shouting gleefully when they find a defect. On their first tours of Toyota's factories, American automakers were astonished to find no "rework area." Toyota engineers didn't subscribe to the approach of inserting defects on the production line only to remove them later in the quality control and rework area. Yet this is exactly what the independent test group excels at! Is it time to discard this organizational model and focus on working together with developers to prevent defects in the first place? Gerard Meszaros examines the sacred concept of independent test teams based on experiences from the agile software movement and Lean production systems.

Gerard Meszaros, Independent Consultant

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.