|
|
|
|
| |
|
|
| |
|
| Payson Hall, Catalysis Group |
|
An economic storm is upon us, with rough waters, dark skies, and hard choices on the horizon. Have you taken action to prepare your projects for challenges when “business as usual" seems a likely recipe for disaster? Payson Hall identifies proactive steps for software project managers and sponsoring executives to prepare their projects and portfolios for increasingly resource constrained times. Learn what status information a project manager should have immediately available, what criteria portfolio managers can use to pare down their fleet of projects, how they can work together to prepare for further turbulence, and what you can do to sustain the productivity of your crew. Find out how risk profiles are likely to change, what new risks may emerge, and what you can do to stay afloat through it all. Payson reviews often overlooked opportunities to use adversity to focus on business decisions that streamline project operations, deliver value, and strengthen your organization to ride out the storm.
|
 |
| Learn more about Payson Hall |
|
|
|
| |
| |
Many agilists take little time to prepare for the first planning session of their first iteration on a new project. They dive right into the “work” and, sometimes, ultimately deliver software that lacks much value. Some newly formed teams believe that collocation breeds instant success and altogether ignore early planning. While sitting together always helps, it does not mean that people spontaneously collaborate to create sustainable value. Before holding the first planning session, a bit of preproduction work helps communities learn about each other, the value they will deliver, and their newly forming ecosystem. Pragmatic preproduction does not need to imply empty ceremony or Big Design Up Front (BDUF). David Hussman shares practical ideas for mining value, connecting communities, and creating productive working environments. If you are forming or leading one or more agile project communities, you’ll leave with ready-to-use tools for selecting agile practices, bonding teams, building rich user-centered product backlogs, and more. |
 |
| Learn more about David Hussman |
|
|
|
| |
| |
|
| Jeffery Payne, Coveros, Inc. |
|
Agile software development presents an appealing array of possibilities for building better software—customer focused development, high team communication, frequent releases of production-ready software, and early lifecycle testing. Unfortunately, many organizations who have attempted to develop software using agile methods have not been very successful at transitioning to an agile process. Often, the organization attempts to change too much of its software process too quickly. Jeffery Payne describes an approach to incrementally improve the agility of your organization's software process while continuing to achieve your software delivery goals. Jeffery describes high value agile management and agile development methods—including daily stand-ups, continuous integration, pair programming, and test-driven development—and then prioritizes these approaches by their impact on the organization. Leave with an understanding of how to incrementally increase the agility of your software organization and measure its business value along the way.
|
 |
| Learn more about Jeffery Payne |
|
|
|
| |
| |
|
| Alan Shalloway, Net Objectives |
|
Eliciting and articulating customer requirements—clearly and precisely—is difficult to say the least. Inaccuracies often creep in when translating requirements from business ideas into software models. Working with many clients, Alan Shalloway found that creating a large number of tables with examples—however time consuming the tables are to create—adds to the clarity and precision of requirements. He found, too, that if you can use the same example table as tests, then the time is well spent. Alan presents table-driven requirements as an approach to defining both functional and test specifications. Examine business rules, user interface flows, user-observable states, and other forms of useful tables. Learn how to employ the Framework for Integrated Testing (FIT) to turn table-driven requirements into table-driven tests. Alan describes the FIT row, action, and column fixtures and shows examples of how to use them to create complex requirements specifications and develop tests. See how these tables can drive the code with less requirement-to-code translation, resulting in more maintainable systems.
|
 |
| Learn more about Alan Shalloway |
|
|
|
| |
| |
|
| Dawn Haynes, PerfTest Plus, Inc. |
|
Many software development organizations have a Quality Assurance (QA) component. Often, QA is just an impressive name for “we do some testing before rolling out our product.” True QA encompasses an integrated process that guides software development from inception to delivery using approaches such as CMMI®, Six Sigma, and ISO. The software testing that occurs near the end of a software development process is a separate, standalone activity that assesses “fitness for use” before delivery. Dawn Haynes explains the differences between quality measures and software requirements with an interactive exercise. She discusses ways for you to evaluate and measure progress toward quality goals during development and explores ways to build management support and develop a skilled QA team. So, if you’re not implementing a truly formal QA program, come see what you are missing.
|
 |
| Learn more about Dawn Haynes |
|
|
|
| |
| |
|
| Rick Hefner, Northrop Grumman Corporation |
|
The CMMI® model was written to apply to a variety of project environments—defense, commercial, development, maintenance, services, and small to large project teams. Its authors used words like “adequate,” “appropriate,” “as needed,” and “selected.” When a project or organization adopts the CMMI® model for process improvement, they consciously or unconsciously make choices about how it will be implemented—scope, scale, documentation, and decision-making to name a few. These choices have a profound effect on the speed and cost of CMMI® adoption. Rick Hefner describes the strategic implications of CMMI® on planning and implementing project processes. He identifies the decisions to be made, the options available, and the relationships between these options and project contexts and business objectives. Take away a deeper understanding of the model and better strategies for its adoption. By understanding the options and making smart choices, CMMI® adopters can ensure that the promised benefits of CMMI®-based improvement are realized.
|
 |
| Learn more about Rick Hefner |
|
|
|
| |
| |
|
A long history of failed software projects using traditional waterfall methodologies was one inspiration for agile development methods. Regarded as novel and even radical a decade ago, agile methods are now widely adopted. Ken Katz’s personal experiences do not lead him to support the proposition that waterfall is doomed to the discard pile of development methods. He has a solid track record of managing projects successfully with waterfall. Ken critically analyzes the Agile Manifesto and its principles, demonstrating that they are based on assumptions that, in certain circumstances, are just as invalid as the generally discredited assumptions underlying waterfall. He describes when waterfall methods are most appropriate and how to use some agile concepts to improve waterfall. Leave this session with an appreciation for the strengths and weaknesses of agile and waterfall, an understanding that no methodology is a panacea, and guidelines to consider when you select the best methodology for your project.
|
 |
| Learn more about Ken Katz |
|
|
|
| |
| |
|
| Paul Robinson, Jr., The College Board |
|
Organizations often invest great sums of money and talent in software projects—often to no good end. A key factor is that many software managers and project teams have, at best, a cursory understanding of expected benefits and little or no quantifiable information about how to evaluate project outcomes—other than cost and end-date targets. Join Paul Robinson to explore a proven software project benefits lifecycle model, including how to: enhance business cases by creating quantitative and qualitative benefit statements; generate business-friendly project success goals and metrics; and track and report the realization of benefits throughout the project lifecycle. Learn how to gain and maintain executive management and team involvement while creating your project business cases, setting business value goals, and monitoring progress. Don’t work on another project that realizes little business value and causes business executives to rail against IT and development for “wasting our money.”
|
 |
| Learn more about Paul Robinson Jr. |
|
|
|
|
| |
| |
|
Leaders can stifle progress when they unnecessarily interfere with team processes. However, as a leader, you don’t want your project to go over the cliff and fail miserably or deliver the wrong results either. There are times when leaders should stand back and let the team work things out for themselves—and other times when leaders should step up and really lead. How do you know which is which? Pollyanna Pixton focuses on collaboration as the key and teaches you how and when to step back and unleash the hidden talent in your organization and teams. Learn how to create an open environment that fosters innovation and creativity and how to let your team members take ownership and hold themselves accountable. Equally important, develop the techniques to step up and lead to keep the project on track without impeding the flow of ideas. Come away with tools to both motivate and guide teams and organizations effectively—and learn to master the balancing act of leadership.
|
 |
| Learn more about Pollyanna Pixton |
|
|
|
|
| |
| |
|
| Rachel Weston, Rally Software Development |
|
In coaching diverse teams on their roads to agile adoption, Rachel Weston has had the opportunity to witness and assist with the different challenges and pitfalls they experience. While each team is unique, a constant and focused “inspect-and-adapt” process has allowed them to identify their current pain points and develop personalized plans for handling them. Rachel examines some of the most common challenges and pitfalls including useless and frustrating daily stand-ups, team over-commitment, backlogs not prepared for planning, difficulties in role transitions, and more. Examine the behaviors that lead to these challenges and learn real-world solutions to help you succeed—an inspect-and-adapt focus through frequent retrospectives, implementing action plans for change, developing a schedule for constant planning from visioning to well-run daily stand-ups, and backlog grooming techniques to help your team stay focused on value delivery. Return with a toolkit of approaches to help your new agile team get off to the right start.
|
.jpg) |
| Learn more about Rachel Weston |
|
|
|
|
| |
| |
|
| Donald Mark Haynes, Synova |
|
Quality assurance is more than just testing software through processing a series of controlled inputs and outputs. It must also include an assessment of all the deliverables associated with the project. Developers and testers often view software documentation as merely a source of information, not as artifacts that require evaluation. All software documentation should undergo a rigorous quality assessment just as the actual software is subject to comprehensive testing. Mark Haynes describes quality models and attributes that can be used to evaluate requirements documents. He shows how imprecision (that will haunt you later) can be detected and removed through a set of formal criteria and informal heuristics. To experience using these techniques, Mark shares examples of poorly written requirements for you to evaluate and improve. Additional quality attributes, even subjective ones, can be used to conduct a quality dialogue. Leave with a better understanding of the process used to ensure quality requirements that become the basis for successful systems development.
|
 |
| Learn more about Donald Mark Haynes |
|
|
|
|
| |
| |
|
Turbulent weather such as tornados is characterized by chaotic, random, and often surprising and powerful pattern changes. Similarly, turbulent software projects are characterized by chaotic, seemingly random project changes that happen unexpectedly and with force. Dealing with turbulence is about dealing with change. Testing teams must contend with continuously changing project requirements, design, team members, business goals, technologies, and organizational structures. Test managers and leaders should not just react to change; instead, they need to learn how to read the warning signs of coming change and seek to discover the source of impending changes. Rob Sabourin shares his experiences organizing projects for testing in highly turbulent situations. Learn how to identify context drivers and establish active context listeners in your organization. Explore test strategies—test triage, just-in-time testing, exploratory testing, and session-based testing—to help you avoid wasted effort and get things done within a project tornado. This class is presented in a highly interactive style. Warning! Those sitting in the front rows may get wet.
|
 |
| Learn more about Rob Sabourin |
|
|
|
|
| |
| |
|
Virtual Retrospectives for Distributed Software Teams
Project retrospectives are challenging enough when the software development team and stakeholders are together in one location. What happens when the team members are spread across multiple locations, time zones, and continents? John Terzakis describes the key challenges of retrospectives for geographically dispersed software teams and provides solutions he has used to address each challenge. Beginning with a brief overview of the retrospective process, John introduces the concept of a “virtual retrospective” and offers techniques and tips for successfully facilitating them. He identifies cultural, geographical, and site-based issues and risks that can imperil virtual retrospectives and demonstrates collaboration tools to overcome distance barriers. Find out how to conduct retrospective exercises, including a valuable project timeline exercise, when participants are not co-located. Learn to identify and mitigate potential risks, plan the logistics, and then facilitate your first virtual retrospective.
|
 |
| Learn more about John Terzakis |
|
|
|
|
| |
| |
|
| Thomas C. Staab, Wind Ridge International, LLC |
|
“Quality” is one of the most misunderstood and elusive aspects of system development. Ask five people to define quality and you‘ll probably get five different answers. Although everyone thinks he knows what it is, very few can really define it in context. High quality software doesn’t just happen—quality must be built in from the start. In this highly interactive presentation, Tom Staab defines quality and explains why quality planning is important. Join in the discussion about where most defects are injected into software, how to establish meaningful quality metrics, ways to communicate results to management in language they understand, and how to calculate the return-on-investment that can be expected from quality improvement activities. Quality must be defined in a project’s specific context, quantified at the beginning of the project, and measured throughout the development lifecycle. Learn how quality improvement can have a positive return-on-investment and how to report results to executive management in their language—money.
|
 |
| Learn more about Thomas C. Stabb |
|
|
|
|
| |
| |
|
| Noopur Davis, Davis Systems |
|
With all the hype about agile, lean, CMMI®, and every other method du jour, we sometimes forget that our real goal is high performance. High-performance software teams consistently deliver products that delight their customers, all while remaining on schedule, keeping with agreed-to functionality, and maintaining high quality. These teams are proud of what they produce and are continuously improving the way they work. Over the past decade, Noopur Davis has worked with many high-performance teams in both large and small organizations. She has discovered that high-performance teams share a number of key practices, regardless of the process they use. Noopur shares these effective practices, including self-direction, openness and transparency, simplicity of work practices, focused use of data, an uncompromising commitment to quality, and others. Using a number of illustrative case studies, she explains these practices and shows you how to use them in your organization. Take away an action plan for improving your team’s performance.
|
 |
| Learn more about Noopur Davis |
|
|
|
|
| |
| |
| Richard Leavitt, Rally Software Development, and Michael Mah, QSM Associates |
|
The proof is now in, and it shows that implementing agile is the best way to get critical, revenue-generating applications to market faster and at less cost. How much money and how many jobs could your organization save? Richard Leavitt and Michel Mah document the financial returns agile project teams are experiencing compared to their traditional counterparts and provide you with a business case toolkit for your senior executives considering agile practices. Rally Software Development commissioned research firm QSM Associates to benchmark twenty-nine agile development projects against their database of 7,500 software projects. The Agile Impact Report compares the performance of agile development projects against plan-driven and waterfall industry averages for time-to-market, productivity, and quality. Receive free access to an online toolkit of ROI calculators and the full study to quickly estimate the cost savings agile development can bring to your company. |
  |
Learn more about Richard Leavitt
Learn more about Michael Mah |
|
|
|
|
| |
| |
|
| Michael Cottmeyer, VersionOne |
|
Agile methods emphasize trust, empowerment, and collaboration—moving us away from command and control project management to harness the passion, creativity, and enthusiasm of the team. In established organizations, success with agile practices hinges on how well traditional project managers adopt new ways of thinking about project structure and control. Building on the principles of the Project Management Body of Knowledge (PMBOK®), Mike explores how PMPs with experience in traditional development can adapt their styles and practices to become effective agile project leaders. Mike tackles the hidden assumptions behind the PMBOK and explores agile approaches for managing time, cost, and scope. Taking an in-depth look at PMI Processes and Knowledge areas, he also explores ways to adapt them to agile projects. Project managers, business analysts, and other stakeholders will leave with a new way of thinking about project management practices within the agile context and new tools for delivering value in the face of uncertainty.
PMP® and PMBOK® are registered trademarks of the Project Management Institute.
|
 |
| Learn more about Michael Cottmeyer |
|
|
|
|
| |
| |
|
| Jonathan Kohl, Kohl Concepts, Inc. |
|
In many current software development approaches, architecture and design are downplayed. Rather than actually architecting products, good designs are assumed to “emerge.” Yet, managers must be confident that their products are well designed. In their efforts to produce products quickly, teams may overlook vital architecture and design issues, such as performance, security, usability, and accessibility. When managers try to help, they can be deterred by jargon and tools that are difficult for non-programmers to understand. Jonathan Kohl illustrates a way for managers to understand and influence product architecture and design. You don't need detailed technical skills to provide valuable insight into a project. Learn how to understand an application and its impact in three contexts: the code (where the application is developed), the system (where the application operates), and the social context (where the application is used). Jonathan also demonstrates how to use a general systems thinking approach to understand architecture and design, without having to know the inner workings.
|
 |
| Learn more about Jonathan Kohl |
|
|
|
|
| |
| |
|
| Gregory Pope and Ellen Hill, Lawrence Livermore National Laboratory |
|
You are probably familiar with maturity models for software development. Greg Pope and Ellen Hill describe a corresponding five-stage maturity model for software quality—not just testing—which addresses the challenges faced by organizations attempting to improve the quality of their software. How do you go about transforming your organization to improve software quality in today’s better, cheaper, faster world? Greg and Ellen present the different maturity levels of software quality organizations: (1) the whiner or know-it-all phase, (2) writing documents phase, (3) the measure the process phase, (4) the measure-based improvements phase, and (5) the tools and process automation phase. Learn how to recognize the signs of each maturity level, where and how to start the quality improvement process, how to get buy-in from developers and management, and the tools to predict and measure software quality.
|
  |
Learn more about Gregory Pope
Learn more about Ellen Hill |
|
|
|
|
| |
| |
|
| Robert Galen, Independent Consultant |
|
Many teams have a relatively easy time adopting the tactical aspects of the agile methodologies. Usually a few classes, some tools’ introduction, and a bit of practice lead teams toward a fairly efficient and effective adoption. However, these teams quite often are simply going through the motions and neither maximizing their agile performance nor delivering as much value as they could. Borrowing from his experience and lean software development methods, Bob Galen explores essential patterns—the ”thinking models” of mature agile teams—including large-scale emergent architecture, relentless refactoring, quality on all fronts, pervasive product owners, lean work queues, stretching above and beyond, providing total transparency, saying “No”, and many more. Bob also explores the leadership dilemma of self-directed teams and why there is still the need for active and vocal leadership in defending, motivating, and holding agile teams accountable.
|
 |
| Learn more about Robert Galen |
|
|
|
|
| |
| |
|
The benefits of a virtualized lab environment for development and test teams are compelling and quantifiable—rapid provisioning and tear down of environments, faster test cycles, and powerful new capabilities to resolve defects. Although some application development teams have experimented with virtual machines and have seen some of the benefits, they’ve also discovered issues with virtual machine “sprawl,” difficulties administering the lab, and lack of virtual private networking. Ian Knox provides solutions to these problems and offers ways to simplify both managing and using virtualization in your development and test environments. Ian describes the basics of virtual lab automation and how you can use virtual labs to solve some of the most pressing and expensive challenges in software quality. He guides you through the important implementation choices for building a virtual lab and, using real-life case studies, explores the common pitfalls. Take back an understanding of a virtual lab’s capabilities and limitations and learn how to automate your lab with specific tools and build integration techniques.
|
 |
| Learn more about Ian Knox |
|
|
|
|
|
|
|
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:
[email protected]
© 2009 Software Quality Engineering, All rights reserved. |
| | |
|
