Product Owner

SQL and MapReduce databases are great—when your data is well-partitioned and the same queries are run regularly. What happens when we don't know what we will want to know in the future? Graph databases are used in everything from Facebook to business intelligence apps. With nodes, edges, and properties to represent and store data, graph databases give us the opportunity to define the landscape as we learn more about our data. Using graph databases we can start at a location and ask for a description of where we are. This allows us to discover pathways and interesting data points that we might not otherwise have been aware of. Andy Palmer explains how you can discover the data landscape and bend it to your will with exploratory reports. Starting with the fundamentals of graph databases—using Neo4J as the tool—your skills with graph databases will increase through the day until you are able to explore and discover new gems of information for yourself.

Bring your laptop and try a big data tool.

On agile teams, testers can struggle to keep up with the pace of development if they continue employing a waterfall verification process―finding bugs after development. Nate Oster challenges you to question waterfall assumptions and replace a “test last” mentality with “specification by example.” Practice “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 guide development with concrete examples written in the language of your business. Start by joining a team for a humorous simulation of real-world issues and experience. Learn how specification by example helps build quality in instead of trying to test defects out. Progress to increasingly more realistic scenarios and practice the art of specifying intent with table-based and given-when-then formats. These paper-based simulations give you meaningful practice specifying concrete examples and will change the way you think about writing tests and collaborating as a team. This is not a tools session—no laptops required.

Free? Is anything free these days? Based on her experience working with organizational leaders and her research into what drives organizational performance, Pollyanna Pixton shares six ideas—and the keys to their effective implementation—to help assure the success of your agile teams. As a bonus, her suggestions won’t cost you a thing. Pollyanna’s first free idea is how to create a culture of trust—the keystone of open collaboration—within your team and organization. The second free idea is about ownership—how to give it and not take it back. Third is empowering teams to make decisions by helping them understand and internalize the project and product’s purpose and value. The number four idea is that you can only fix processes, not people, so invest your energy toward the correct target. Idea five is to match people’s roles to their passion. Her final free idea is that integrity does matter—and matters most. Explore with Pollyanna why each of these ideas is important and how you can adopt them on your agile team.

In the tradition of James Whittaker’s book series How to Break Software, Jon Hagar applies the testing “attack” concept to the domain of mobile and embedded software systems. First, Jon defines the environments of mobile and embedded software. He then examines the issues of software product failures caused by defects found in these types of software. Next, Jon shares a set of attacks against mobile and embedded software based on common modes of failure that teams can direct against their software. Like different kinds of software design patterns, attacks are test design patterns that must be customized for particular contexts. For specific attacks, Jon explains when and how to conduct the attack—and why the attack works to find bugs. In addition to learning these testing concepts, you can practice the attack patterns on devices containing mobile and/or embedded software―so bring your smart phones.

Numbers, models, and measurements are often used to describe. Just as often, they are used to persuade. Sometimes, they are used to intimidate. In order to avoid being fooled or bullied, testers must be able to examine information, claims, and evidence critically. They must apply critical thinking to their own observations, interpretations, and reports in order to avoid fooling themselves—or worse, their clients. Michael Bolton and Laurent Bossavit help you look thoughtfully and skillfully at reports, research, and common claims about testing and software development. Learn methods for analyzing those claims and a framework for evaluating them. Apply this approach to real-world cases and exercises, and refine your approach to collecting, assessing, and presenting data. Throughout, remain engaged as you look at the original data, assess the relationship between numbers and their representations, evaluate the methods of measurement and, in a nutshell, refine your current skills and build new ones. Caution: This workshop may interfere with your enjoyment of your daily newspaper.

 Transitioning to agile can be difficult—often downright wrenching—for teams, so many organizations are turning to kanban instead. Kanban, which involves just-in-time software delivery, offers a more gradual transition to agile and is adaptable to many company cultures and environments. With kanban, developers pull work from a queue—taking care not to exceed a threshold for simultaneous tasks—while making progress visible to all. Ken Pugh shares eight steps to adopt kanban in your team and organization. Ken begins with a value stream map of existing processes to establish an initial kanban board, providing transparency into the state of the current workflow. Another step establishes explicit policies to define workflow changes and engender project visibility. Because you can easily expand kanban to cover many parts of development, another step is to increase stakeholder involvement in the process. Join this interactive session to practice these key steps with hands-on exercises and take away an initial plan for implementing kanban in your organization.

Agile initiatives always begin with the best of intentions—accelerate delivery, better meet customer needs, or improve software quality. Unfortunately, some agile projects do not deliver on these expectations. If you want help to ensure the success of your agile project or get an agile project back on track, this session is for you. Jeffery Payne discusses the most common causes of agile project failure and how you can avoid these issues—or mitigate their damaging effects. Poor project management, ineffective requirements development, failed communications, software development problems, and (non)agile testing can all contribute to project failure. Learn practical tips and techniques for identifying early warning signs that your agile project might be in trouble and how you can best get your project back on track. Gain the knowledge you need to guide your organization toward agile project implementations that serve the business and the stakeholders.