How do you measure a project's success?  Traditional project management defines success as delivering the baseline requirements on-time and within cost.  These measures are constraint-based.  Some agile projects define success when the backlog is empty and the burn-down chart has hit zero. I call this measurement, velocity-based. Velocity, when used to measure success, pulls us back into the gravity well of constraint-based measurements.   Is there a better way? Can we escape velocity? Shouldn't we measure the success of a project based on some value delivered to someone?  Such a measure would be value-based. Enter impact mapping, a value-based approach to measuring project success.  This talk is about the impact of impact mapping, why you should use it, and how you can use it to measure a project's success so that you are delivering true value to the end-user and not just a collection of user stories.

We firmly believe that automated testing puts the "A" in "Agile". Without an effective suite of automated tests your ability to be truly agile (that is embrace change) can only be based on the hope that your latest change doesn't have unintended consequences. Additionally, without automated tests, you are missing a vital component in getting feedback into the development team's hands. In our travels, we have encountered many organizations that are struggling with automated testing. These organizations are successfully adopting many Agile techniques but are failing when it comes to automated testing. We frequently hear "Automated testing just doesn't work for us" (eerily reminiscent of the days when we would hear, "Agile just doesn't work for us"). From our experience addressing their challenges, we have identified anti-patterns common across these organizations. These anti-patterns look like they should work, but are in fact doing more harm than good.

This talk is about those anti-patterns. We have given those anti-patterns a name and a face to help organizations understand why they are not getting the benefits from automated testing that others are. We describe several anti-patterns, such as the "Ice Cream Cone", the "Monolith", the "Sunk Cost". We explain why these anti-patterns appear to be good solutions, what makes them attractive, and why they do more harm than good. We talk about the right approach and draw on our experiences helping organizations adopt a robust automated testing strategy that instills confidence and provides fast feedback to the development team. We explain what benefits from automated testing the anti-pattern is preventing. 

We think we understand that awkward teenager.

Many experienced testers will claim exploratory testing expertise, but too few have ever written an exploratory testing charter, and even fewer have applied a heuristic in that charter. We think we understand exploratory testing just as we think we understand teenagers, because “we have been there”. However the reality is that many of the words currently used in exploratory testing are foreign to us and we feel awkward about our lack of knowledge. The goal of this talk is to give people experience writing and executing exploratory testing charters, creating mind maps, and applying exploratory testing heuristics.

The talk is intended to introduce people to the exploratory testing techniques described by Elisabeth Hendrickson in her book Explore It! with some added material from the work of Cem Kaner and James Bach.

Great systems require active, capable Product Owners.  Functional innovation is not possible without their commitment and involvement in the project.  Too often in government contracting, the Product Owner is an Absentee Owner.  Agile Development teams often seek out tools and techniques to create great systems, however too frequently what is holding them back is the lack of an engaged Product Owner. Teams in this situation must face the elephant in the room if they desire to build a system that brings positive change in efficiency, productivity, quality, usefulness, and adoption.  This talk shares solutions I have used for challenges I see again and again on government contracts.

The talk begins with some introductory material on the problem, its causes, what I mean by functional innovation, and why this is required to build great systems.  I describe four challenges with Product Owner engagement that are not unique to government contracting, but that I see recurring on projects: committing staff, procurement practices, role ambiguity, and absentee ownership.