Tutorials

Identifying, documenting, and communicating software requirements are key to all successful IT projects. Common problems in requirements engineering are “How do we discover the real requirements?”, “How do we document requirements?”, and “How do user stories fit into requirements?” Erik van Veenendaal answers these questions and more while helping you improve your skills in requirements engineering for both traditional and agile projects. With practical case studies and hands-on exercises, Erik illustrates requirements issues and solutions. Practice finding, specifying, and evaluating requirements while learning how to gather information through varied elicitation techniques. Exploring the advantages and disadvantages of each technique, Erik offers guidelines for developing both functional and nonfunctional requirements. Learn a rule set for determining how much documentation you need for “good enough” requirements. Explore requirements review techniques—walkthroughs and inspections—to determine what will work best for you. Collaboratively create a set of Golden Rules for requirements engineering that every project can use.

Software projects are known to have challenges with estimation, uncertainty, risk, and commitment—and the most valuable projects often carry the most risk. Other industries also encounter risk and generate value by understanding and managing that risk effectively. Todd Little explores techniques used in a number of risky businesses—product development, oil and gas exploration, investment banking, medicine, weather forecasting, and gambling—and shares what those industries have done to manage uncertainty. With studies of software development estimations and uncertainties, Todd discusses how software practitioners can learn from a better understanding of uncertainty and its dynamics. In addition, he introduces techniques and approaches to estimation and risk management including using real options and one of its key elements—understanding commitment. Take away a better understanding of the challenges of estimation and what software practitioners can do to better manage estimation, risks, and their commitments.

On agile teams, testers can struggle to keep up with the pace of development if they continue employing a waterfall-based verification process—finding bugs after development. Nate Oster challenges you to question waterfall assumptions and replace this legacy verification testing with acceptance test-driven development (ATDD). With ATDD, you “test first” by writing executable specifications for a new feature before development begins. Learn to switch from “tests as verification” to “tests as specification” and to guide development with acceptance tests written in the language of your business. Get started by joining a team for a simulation and experience how ATDD helps build quality in instead of trying to test defects out. Then progress to increasingly more realistic scenarios and practice the art of specifying intent with plain-language and table-based formats. This isn’t a “tools” session. These are tabletop, paper-based simulations that give you meaningful practice with how executable specifications change the way you think about tests and collaborate as a team. Leave empowered with a kit of exercises to advocate ATDD with your own teams.

Because systems are now more complex and competition is extreme, testing for usability is critical for ensuring our products not only stand out from the crowd but even exceed our customer’s expectations. As testers, we often encounter requirements such as “The system must be user-friendly.” What does this mean? And, more importantly, how do we test against this vague notion? Join Julie Gardiner as she presents usability testing techniques to help evaluate system efficiency, effectiveness, and user satisfaction. Take back a toolkit full of usability testing techniques—heuristic evaluation, cognitive walkthroughs, focus groups, personas, contextual task analysis, usability labs, and satisfaction surveys—for your next testing project. Learn how to define usability goals and how to get your development team to take usability issues seriously. If you want to improve your confidence and skills in usability testing, this session is for you.

Unfortunately, those of us who struggle with complex problems for a living don't have time to keep up with the enormous amount of cognitive science research that could help us become better thinkers, better problem solvers, and better decision makers. Having devoted more than ten years to researching the fast-moving fields that almost daily reveal new information, Linda shares what she has uncovered—some of it surprising, some even counterintuitive. She summarizes the research and provides concrete tips for improving your individual, team, and organizational abilities. Most of us sit all day, believing that concentrating without moving, in a room with no natural light, drinking too much caffeine, after our usual night of less than six hours of sleep is the way to get work done. Linda offers ways to incorporate movement, take a break, change focus, brighten our environments, think better, and be happier. Learn the latest tips for boosting your problem-solving power.

Your shrinking project deadlines are increasing the need for automated tests—but, simultaneously, reducing the time available for writing them. The system requirements are continually changing. The implementation is changing. You spend more and more time maintaining old tests, leaving less time to write new ones. The tests take longer and longer to run. And when they fail, the problem is as likely to be in the tests as in the system. What’s a developer to do? Dale Emery and George Dinwiddie share hard-won lessons learned from their decades of software development and test automation. Discover the factors that make automated tests maintainable, expressive, informative, fast, reliable, and repeatable. Practice achieving these qualities in hands-on exercises. Apply new techniques and your existing software development expertise in new ways. Take home powerful principles and practices to meet the unique challenges of test automation and to help your project deliver sooner with greater confidence.

Many organizations have achieved agility at the team level only to be unable to achieve it across teams. The Scaled Agile Framework (SAFe) provides both a vision and method for how to achieve this. SAFe is the first documented framework that can be used to scale agile throughout an organization. It is a combination of lean, kanban, and Scrum—lean to provide a context for an organization, kanban to manage the flow of projects, and Scrum to provide agile at the team level. Beginning with an introduction to lean and kanban, Ken Pugh explains why they are required for agile at scale. Ken then describes the framework of SAFe—specifically how it creates a structure to manifest the behaviors required for agile at scale. In particular, learn how to coordinate your organization’s portfolio, programs, and projects. Ken concludes by discussing when it is advisable to use the framework and when a more emergent method is preferable.

Are you having trouble getting people in your organization to agree on a path forward? Is collaboration sometimes more like a contest to see who can yell the loudest? Is it difficult to get customers to give you the information you need to create a product charter or unambiguous requirements? Achieving meaningful collaboration with a diverse group of people can be very difficult. Bob Hartman and Michael Vizdos shares their experiences with Innovation Games®, collaboration exercises that dramatically improve the way people work together. You’ll practice with exercises that are easy to use, fun, and encourage working together in a structured fashion. This structure guides successful collaboration, helping participants stay on track and avoiding non-productive, free-for-all discussions. Learn how to choose the best Innovation Game for each situation. Leave with an understanding of how and why structured collaboration with intellectual games is one of the most productive ways to help people work together toward a common goal.

We have opportunities to coach people all the time. Much of what we see as coaching is actually undercover training. Real coaching is richer—offering support while explaining options. In this interactive session, Johanna Rothman invites you to explore how to coach, regardless of your position in the organization. Teaching is just one option for coaching. You have many other options, depending on your coaching stance. You may select a counselor’s stance if you are managing up or a partner’s stance if you are a peer. You might even select a reflective observer’s stance or a technical advisor’s stance, depending on the situation. We will explore what to do when you see opportunities for coaching but you haven’t been asked to coach. Bring your coaching concerns, whether you are coaching onsite, or coaching at a distance, coaching one-on-one, or coaching teams. Let’s learn and build our coaching skills together.

Formula 1 drivers don’t just drive faster than you—they drive differently. Accelerated Agile uses different rules, based on the core principles of agile but taken to another level, to deliver in hours and days what regular teams can only achieve in weeks or months. Accelerated Agile is for experienced agile practitioners who are frustrated with the pseudo-science of agile planning and estimation, the social pressure to automate where it doesn’t add value, the artificial commitment of sprints, and the unwelcome surprises that still derail projects. Learn new techniques that enhance and replace existing agile practices, many of which are completely counter to current agile doctrine. Discover new techniques for development and testing, operations, automation, and team dynamics, as well as working with legacy systems and integrating with third parties. Using these techniques, you and your teams will deliver business solutions faster than they thought possible.

This is not a tutorial for beginners!

Many teams have a relatively easy time adopting the tactical aspects of agile methodologies. Usually a few classes, some tools introduction, and a bit of practice lead teams toward a fairly efficient and effective agile adoption. However, these teams often get “stuck” and begin to regress or simply start going through the motions—neither maximizing their agile performance nor delivering as much value as they could. Borrowing from his experience and lean software development methods, Bob Galen examines essential patterns—the thinking models of mature agile teams—so you can model them within your own teams. Along the way, you’ll examine patterns for large-scale emergent architecture—relentless refactoring, quality on all fronts, pervasive product owners, lean work queues, providing total transparency, saying no, and many more. Bob also explores why there is still the need for active and vocal leadership in defending, motivating, and holding agile teams accountable.

Testability is the degree to which a system can be effectively and efficiently tested. This key software attribute indicates whether testing (and subsequent maintenance) will be easy and cheap—or difficult and expensive. In the worst case, a lack of testability means that some components of the system cannot be tested at all. Testability is not free; it must be explicitly designed into the system through adequate design for testability. Peter Zimmerer describes influencing factors (controllability, visibility, operability, stability, simplicity) and constraints (conflicting nonfunctional requirements, legacy code), and shares his experiences implementing and testing highly-testable software. Peter offers practical guidance on the key actions: (1) designing well-defined control and observation points in the architecture, and (2) specifying testability needs for test automation early. He shares creative and innovative approaches to overcome failures caused by deficiencies in testability. Peter presents a new, comprehensive strategy for testability design that can be implemented to gain the benefits in a cost-efficient manner.

The business analyst (BA) role seems conspicuously absent from most agile methods. Does agile make the BA role obsolete? Certainly not! But how does a BA exploit the short cycle times and collaborative nature of agile methods? Drawing from the principles of lean product development flow, Steve Adolph introduces five principles for the agile BA—Open the Channels, Chart the Flow, Generate Flow, Lean Out the Flow, and Bridge the Flow. As a communicator, the BA must Open the Channels and Chart the Flow to align all stakeholders. BAs can leverage traditional tools such as use cases to Generate Flow and feed user stories to fast moving agile teams. However, large backlogs of stories are wasteful, so lean principles are applied to Lean Out the Flow. Finally BAs may need to Bridge the Flow between more traditional elements of the organization and its agile teams. Whether you are a BA new to agile or struggling to find the right fit in your team, join this highly interactive session to “get your flow” going.

Are you an agile practitioner wanting to take your agility to the next level? Are you looking to gain real value from agile instead of simply more talk? Even though many are using agile methods, not all are seeing big returns from their investment. David Hussman shares his experiences and describes a short assessment that identifies both strengths and weaknesses in your use of agile methods. Creating an assessment helps you examine the processes you are using, why you are using them, and if they are providing real value. This assessment guides you through the remainder of the tutorial, helping you tune your current processes and embrace new tools—product thinking, product delivery, team building, technical excellence, program level agility, and more. Leave with an actionable coaching plan that is measurable and contextually significant to your organization. If you want to promote real agility—or lead others to do so—come ready to think, challenge, question, listen, and learn.

Agile is now mainstream, but many companies continue to struggle. When agile is adopted, common issues occur in every organization: getting people to try agile, selling agile to management, learning how to do efficient standup meetings, fitting planning into a short window, and running effective retrospectives. When you add in scaling issues, different development styles, and outsourcing, your simple agile adoption just gets more difficult. In this highly interactive (no slides) introductory-to-intermediate session, Brian Button presents the tools you need to get started and be successful with agile. Using Scrum to manage the session, you will learn the value of prioritization and how to do it, why timeboxing works, how to create a release plan using team velocity, and more. As you are learning these techniques, Brian answers your questions to help ensure your successful agile adoption. Get started on the path to success with agile in this immersive experience.

Every large software project is unique—each with its own complex array of challenges. When projects get into trouble, however, they often exhibit similar patterns, and succumb to risks that could have been anticipated and prevented—or detected sooner and managed better. Common responses to the problems—blaming, deferring action, or outright denial—only make things worse. Payson Hall reviews a dozen patterns he has observed over and over again on troubled projects during his thirty-year career: trouble with subcontractors, challenges with project sponsors, friction within the team, perils of interfacing with adjacent systems, issues with data cleansing and conversion, and more. Payson shares the tools he uses to help identify the symptoms of common risks, reduce the likelihood of risks occurring, facilitate early detection of problems, and establish a foundation for helpful responses when problems arise. This session is designed for project managers, team leaders, project sponsors, and anyone responsible for building or rolling out large enterprise systems.

Planning is a tool and, like all tools, can be used for good or ill. Too much planning can be wasteful; too little planning can breed chaos. Successful teams gravitate toward “just enough planning.” Building on his years of coaching XP, Scrum, kanban, and lean, David Hussman pragmatically describes planning that promotes early and continuous learning. He details how to collaboratively create plans that allow teams to continuously measure, learn, and pivot. David covers roadmap planning, iterative delivery, dealing with adversity, and adapting your planning to provide the most value with the least process. He also discusses working with large programs, working across locations, the pragmatic use of tools, and helping people learn to ask essential questions, answered by concrete evidence that is iteratively produced. If you are tired of people talking—or preaching—about processes but producing little real value, David’s approach will leave you satisfied and ready to pump new life into your team’s planning.