Retrospectives are the core of agility. And yet they are the scrum ceremony that is most frequently skipped. Many teams like the idea of the retrospective but find them boring, or worse ineffective.

This talk aims to re-energize retrospective facilitators and participants. Starting with the basics: "what's a retrospective and how do you run one?", this talk reveals 7 secrets that lead to more engaging, more effective retrospectives.

You'll learn:

* The best way to ensure your retrospectives lead to real change

* The "pledge" everyone on your team should take before participating

* How to know who to include in each retrospective

* The single most important thing you can do to keep your team engaged during the retro

* And much, much more!

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.

Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Outcomes are the big picture that acts as an anchor for whole efforts and which is continuously broken down into more and more detailed backlogs. The onion metaphor that is popularly used in agile planning (Cohn’s Planning Onion) can be used to describe the evolution of backlogs. Building an initial backlog is much like peeling through the layers of an onion to get to the core. There are many mechanisms for developing and maintaining the detailed backlogs, including asking, observing, showing and all sorts of hybrids. Using the onion metaphor, techniques for developing and splitting user stories are the second layer of the onion. However, before getting to the center of the backlog evolution onion, composed of features, epics, and user stories, we need to understand the big picture. 

 Presentation:

Provide an overview of storytelling in a business context and a lean change canvas framework.

Exercise

The room will be broken into teams (aisles will be used if auditorium seating).  Each team will be seeded with a common product change scenario. Based on the scenario the teams will be asked to tell the story of the change and capture the story on a small change canvas.  The exercise and session will culminate in by sharing ideas and lessons learned.

(Note the longer workshop would break the changing canvas into epics and stories)

A well-facilitated large-scale Planning event (such as a SAFe PI Planning) can leave you feeling energized and more confident in your team and your direction. Poorly facilitated events have the adverse effect and can leave you feeling like you’ve just been run over by a Mack Truck.

There is not a lot of guidance from SAFe on how to facilitate this critical event from their website, other than an example agenda and program board. This session will focus on how information radiators and other visual tools can make a tremendous difference in increasing engagement and collaboration amongst teams in order to orchestrate a thoughtful plan with high confidence.

We will show battle-tested ways on how visuals are critical to...

• increase collaboration across teams
• reinforce development practices & standards
• track team progress through the day
• highlight dependencies
• increase the confidence vote
• motivate teams to strive for success

Participants will leave this session with some visual tools and tips they can immediately put to use in their designing their next PI Planning or ANY large-scale planning event.
“There is no magic in SAFe… except for maybe PI Planning” - SAFe authors

The talk covers three start up players who scaled quickly within the Indian food tech industry in the year 2015. It draws out a common factor between the marketing strategies of the three enterprises. This common factor is then fine tuned into a KPI as it is used to analyze and measure the strategies based on data. The entire process draws it’s inspiration from Agile methodologies and the respective ceremonies held as part of Agile. These include ceremonies like retrospects and just in time reviews. The talk focuses on how a product owner/manager can contribute to the marketing/sales department of a huge enterprise/product.

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. 

Traditionally, project managers are told to optimize scope subject to constraints on time, cost, and quality. This is embodied in the expression, “better, faster, cheaper—choose two.” The phrase has become a rhetorical distraction to effective project management. It presumes a magic bullet; if you can precisely balance the constraints you will be successful. In reality, the triple constraint poses a calculus problem that has no tangible solution.

The project box introduces a new and better paradigm for describing the interaction of time, cost, quality, and scope for many software projects—particularly Agile projects. The project box simplifies the calculus of managing the project constraints:

• Duration is set,
• Scope is time-boxed and negotiable,
• Quality is both time-boxed and imperfections are expected, and
• Cost is proportional to duration.

The project box represents a paradigm shift for managing software projects. It recognizes the primacy of time and reorients the other dimensions accordingly. To traditionalists, the project box provides a new worldview for managing time, scope, quality and cost. To Agilests, it provides a better representation of their principles and replaces the inverted triangle.

To read the full article: https://www.scrumalliance.org/community/articles/2015/november/the-project-box-evolving-beyond-the-triple-constra

Lego games and similar simulations are a fun, engaging way to introduce Agile concepts.  However, they require non-trivial effort to setup and clean and don't really work for distributed participants.  This will be a discussion and demonstration of Agile simulation game using Minecraft.

Alternate title: "Everything you wanted to know about User Stories but was afraid to ask"

"User Stories" have become the de facto standard way of breaking down work in Agile software development.  However, many practitioners (and even nominal teachers) succumb to common errors and misunderstand critical points that distinguish effective practice.

This is a presentation of my efforts to create a more detailed look into patterns around User Stories and other aspects of work breakdown within Agile software development.