|
|
|
|
|
|
|
|
|
|
| One stakeholder says “Zig.” Another says “Zag.” There’s no compromise in sight, and the project deadline looms closer. Between the rock and the hard place? Welcome to the real world of software development. We don’t have to like conflict, but our ability to successfully deliver quality projects can depend on how well we navigate conflict. Andy Kaufman introduces you to conflict handling modes that describe different approaches to deal with conflict. Understanding these modes can help you get beyond your typical conflict responses to more effective responses that provide an opportunity for greater collaboration. How do you deal with an overly emotional stakeholder or a developer who is ignoring your requests? Learn to identify the different conflict handling modes, understand your own personal tendencies, and improve your ability to deal with and reduce conflict. Join Andy to explore real-world project conflict and leave with powerful new approaches for turning conflict into collaboration. |
 |
| Learn more about Andy Kaufman |
|
|
|
|
|
|
| What do users really need? Do they really know what they need? Although developers and testers are expected to implement stories and requirements that add real value, users often describe wants rather than needs and ask for features rather than solutions. Rob Sabourin shares his experiences applying task analysis using the “critical incident method” to better understand user processes and determine needs and desired solutions. Rob does not ask “what the system should do for the user” but rather learns “what the user does with the system.” The critical incident task analysis method is a fast and systematic way to study user experiences and analyze business needs. From brilliant successes and dismal failures we learn to identify and understand the user process. Rob shares examples of how task analysis captures critical attributes, quality factors, non-functional requirements, and failure recovery aspects of a system over and above typical functional requirements and business rules. |
 |
| Learn more about Rob Sabourin |
|
|
|
|
|
|
| Every organization has its own project patterns. Some management teams take a long time to start a project. Others interrupt and divert the project teams once they’ve started. Some project teams never finish because the product must be “perfect.” Still others believe there is a single solution to all their problems such as “Two weeks of overtime and we’ll be caught up!”, or “If the testers just tested more”, or “We just need some more time designing.” Project managers also fall into patterns: overly optimistic, pessimistic, risk-encouraging, risk averse, etc. Johanna Rothman explores different project and management patterns to help you understand which patterns are working—and which are harmful—for you. Learn about the power you have to change harmful patterns, including helping your leaders articulate the pattern, time-boxing pieces of the project, developing release criteria, using metaphors to explain your project’s progress, and more. |
 |
| Learn more about Johanna Rothman |
|
|
|
|
|
|
| Evidence shows than more than half of the ideas that we think will improve the user experience actually fail to do so—and some actually make it worse. Instead of guessing, why not measure what your real users like and don’t like? Controlled, online experiments (A/B tests being the simplest version) are a proven way to make data-driven decisions about what works and what doesn't. Seth Eliot shares numerous examples of online experimentation within Microsoft to test new user interfaces with their customers. Seth shows how special frameworks, such as Microsoft's ExP (Experimentation Platform), can also move testing into the high-value realm of testing-in-production. In addition to new features and designs, Microsoft tests the impact of new code in production. By employing online experimentation, you can control how and when new, potentially dangerous code is exposed to users. Exposure control enables you to reap the benefits of testing in production while limiting the potential negative impact on your customers and users. |
 |
| Learn more about Seth Eliot |
|
|
|
|
|
| Steven “Doc” List, ThoughtWorks |
|
|
| Good facilitation skills are essential for everyone in development. In fact, everyone facilitates whether they know it or not. If you work on a team, manage an organization, or simply work with others, the opportunity to facilitate arises often. Steven “Doc” List leads delegates in exploring the common patterns and anti-patterns—for both the facilitator and the participants—he’s seen and experienced during facilitation interactions. Join Doc for this highly interactive class and have some fun taking on roles like Gladiator, Guide, and Conclusion Jumper. Explore the facilitation behaviors that work—and ones that don’t—and participate in activities that provide an opportunity for you to practice new facilitation techniques. You’ll laugh and learn, and you’ll take away new skills and tools to help you and your team become more effective facilitators. |
 |
| Learn more about Steven “Doc” List |
|
|
|
|
|
|
| While agile and traditional software development methodologies differ in many key practices, they share the mutual goal of accurately representing customer needs through requirements—whatever their form. If requirements are poorly understood, lack key details, or are interpreted differently by stakeholders, unnecessary defects will be introduced into the product. Defects lead to rework which ultimately delays product delivery and decreases customer satisfaction. John Terzakis outlines proven practices, templates, and techniques you can use for writing requirements that more accurately capture customer needs. He discusses issues with “natural language,” shares ten attributes of well-written requirements, and explores ambiguity checklists. John presents practical templates and syntaxes for stories (aka scenarios), use cases, and traditional requirements documentation. He provides examples of poorly written requirements, analyzes them, and then rewrites them using the approaches he’s introduced. Regardless of the development lifecycle your team employs, you’ll leave this session with new tools and techniques to write higher quality software requirements. |
 |
| Learn more about John Terzakis |
|
|
|
|
|
|
| Even though the code may have been written only five years ago, there it is—a sprawling unintelligible mess that nobody wants to touch. For most people and teams, this reality is a cause for fear and loathing—something we want to sweep under the rug. We can, however, choose to see “bad” code as a challenge to restructure and refactor into a maintainable design that serves the business for years to come. Although legacy code presents many constraints on design choices, it offers the opportunity for incremental improvement. Michael Feathers shows you how to practice design within the boundaries of what some see as unintelligible code and explains ways to make the improvement process manageable. See how you can escape the fear that holds you back from productive action. Find out how to start with what you have now and progress toward a structure that supports the work at hand and immediately adds value. |
 |
| Learn more about Michael Feathers |
|
|
|
|
| James McCaffrey, Volt VTE |
|
|
|
Earned Value Management (EVM) is one of the key topics in most all project management courses and is part of the Project Management Institute's PMP® certification and PMBOK®. However, many software project managers do not understand EVM well—and even fewer practice it well. James McCaffrey demystifies EVM, explores its benefits, and clearly explains the often confusing terminology—planned value, earned value, actual cost, schedule variance, schedule performance index, cost variance, and cost performance index. In this hands-on class, you’ll practice EVM techniques through a set of short and simple exercises within a case study. Leave with a rock solid understanding of the assumptions made by EVM, how to compute and correctly interpret EVM metrics, when EVM techniques are appropriate to use, and when alternative approaches are more suitable.
PMP® and PMBOK® are registered trademarks of the Project Management Institute.
|
 |
| Learn more about James McCaffrey |
|
|
|
|
|
|
| In tough times, both shoes often drop simultaneously. Then, unsustainable “scarcity thinking” takes over. Many times, the tendency is to say “yes” to impossible dates, take on too much, quietly suffer the budget cuts, and pray that heroics will save the day. Resulting dysfunction can wreak havoc on your projects in the form of scope greed, death-march deadlines, and budget cuts. It takes a skillful manager to “right size” critical projects—right team, right scope, right dates—from the beginning. Michael Mah describes how to lead difficult conversations and discuss the undiscussable when needed resources are threatened. He shares how to artfully frame trade-offs for stakeholders to help them set priorities. Learn how to get buy-in for realistic scope, schedules, and team size using a blend of common sense, essential measurement concepts, and rules of software estimation. Whether you’re agile, waterfall, or you outsource, you’ll discover information you need to make the right choices and gain the support of your organization. |
 |
| Learn more about Michael Mah |
|
|
|
|
|
|
| Business rules and data needs are essential ingredients for a balanced set of requirements and are vital for successful product delivery. When analyzing requirements, some teams focus on business rules at the expense of data. Others dive deeply into modeling data, skimming over or skipping business rules. When it comes to delivery, if either data or rules are inadequately elaborated, you risk not delivering the right requirements and wasting precious time and money. Mary Gorman demonstrates how to leverage behavioral analysis models to discover and detail business rules and data in tandem. After identifying four types of business rules, she describes when to start modeling rules and data together, whom to involve, the skills you need, and the level of detail to explore. Learn the risks of single-focused requirements and how modeling business rules and data simultaneously enables you to deliver a more complete, correct, and consistent understanding of customer needs. |
 |
| Learn more about Mary Gorman |
|
|
|
|
|
|
| By its very nature, the endgame of software projects is a hostile environment. Typical dynamics include tremendous release pressure, continual bug and requirement discovery, exhausted development teams, frenzied project managers, and “crunch mode” for testers. However, hope and relief are available. By using metrics derived from defect discovery and repair patterns, you can learn how to guide projects toward a successful release with less stress and more certainty. Bob Galen shares patterns that you can mine from your defect metrics to focus your entire team on a few key performance indicators. Examine defect patterns, maturation rates, and other organizationally unique patterns that you can leverage as project milestones. Learn about the Pareto Principle and its implications on defect actions and workflow. Next time, you’ll be better prepared for your project endgame and increase the likelihood of an on-time delivery. |
 |
| Learn more about Bob Galen |
|
|
|
|
|
|
| We understand the vital importance of collaboration among team members. However, how can we deal with non-collaborators—people who won’t work with us? Although we may not be able to change them, we may be able to work with them or around them. Pollyanna Pixton describes how to identify non-collaborators—a leader, team member, team, or even a process. She then examines the system within which the non-collaborators work: their success factors, motivations, measurement and reward systems, fears, hot buttons, and hidden agendas. Pollyanna teaches you how to assess the risks in dealing with non-collaborators. Using a trust and ownership model, she maps the traits of non-collaborators and considers tools and techniques to cope with each trait. Finally, if all else fails, learn the options for working around non-collaborators. Learn to deal with non-collaborators by building a strategy that empowers you and your team to get the job done no matter what. |
 |
| Learn more about Pollyanna Pixton |
|
|
Top of Page
|
|
|
 |
Software Quality Engineering • 330 Corporate Way, Suite 300 • Orange Park, FL 32073
Phone: 904.278.0524 • Toll-free: 888.268.8770 • Fax: 904.278.4380 • Email: sqeinfo@sqe.com
© 2009 Software Quality Engineering, All rights reserved. | | | |
