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!

(This talk was well-received in 2015, so we can do an updated version for 2016)

DevOps as a buzzword is gaining traction, but what does it really mean? Managers, non-techies, and developers-new-to-devops will get a guided demo of development automation. See all the cool tools in action - continuous integration, automated testing, cloud deployment, etc. More importantly, we'll walk through what they do, and why that adds value to a project. 

This talk will...

• Break down the buzzwords and define some key technical practices in plain english.
• Uncover the pain that leads teams to seek greater automation.
• Demonstrate a continuous integration pipeline working in practice via live demo.
• Diminish the knowledge gap between technical practitioners and managers/analysts/coaches.
• Level-up the vocabulary of non-technical attendees.
• Introduce practices to developers who don't yet work in an automated environment.
• Spark "ah-ha" moments to convert skeptics into DevOps believers!

By the way, all of the tools in the demo are some combination of free and/or open source. DevOps doesn't have to cost a lot.

Scrum is hard to understand, or so they say. But when we describe new topics in easy to understand language, suddenly it can all make sense.

We'll look at Scrum through the lens of Waterfall, to discuss how similar they really are if you think about the core concepts that make Scrum work so well and apply them to Waterfall in the right way.

We'll talk about how the first big hurdle isn't in changing the process, but rather in how you think about the process. This is particularly important because often we cannot change the process. However, we do have flexibility to operate *within* and *in addition to* the process, where we can inject tangible benefits, so we can create trust around the approaches, so we can get the support to move closer to pure Scrum.

This presentation will open your eyes to understanding how close you really are to Scrum if you just use this conceptual stepping stone.

Dream to Delight is the concept to cash value stream practiced with proven success across 4 industries: Utilities, Media, Banking and Mortgage. It is a set of 7 Highly Effective Ds: Dream, Discover, Define, Design, Develop, Deploy & Delight.

This session is about leading enterprise portfolios to agility through lean-agile transition. It talks about the journey highlighted as steps & activities taken at each “D” stage aligning to promise of agility: highest business value fastest to market with built in quality. I do highlight the importance of context and perspective and thereby the need of choices and options at respective “D” stages to increase visibility, transparency and thus improve accountability across the program.

It does seem to me “The Silver Bullet” applying the 7 Ds across four industries as a leap to Enterprise Agility, however I trust to raise awareness and agreement towards the importance of coaching and mentoring to impact and sustain agility in an organization with people and their mindsets still internalizing and going through their respective “J” curves of acceptance and adoption.

Organizations in the midst of a bottoms-up agile transformation can find themselves in a quandary. Even though some (or even all) teams may have adopted agile at the developer / program level, PMOs are often still required to plan, resource, and report on progress with almost no consideration given to the methodologies of the underlying work. 

What does an Agile Coach do anyway?  We already have Scrum Masters, why do we need a coach also?  We have only a few teams or perhaps just a single team; isn’t an Agile Coach a lot of overhead?

 These are excellent questions asked by many organizations and individuals.  They deserve good answers.

 In this talk, we’ll provide those answers and discuss how Agile Coaches can have a huge multiplier effect for any organization striving to transform, execute, or improve.  We’ll cover coaching both at an abstract level as well as the nuts-and-bolts day-to-day level.  Participants will leave with an understanding of what an Agile Coach can do for them and how to explain to others why their organization should have one.

Are you lazy like me and want a simple way to measure your team’s performance? The Kanban Method, which is sometimes referred to as the "Start with what you do now" approach to evolutionary change, offers a simple and easy way to start measuring and improving your team’s performance.

I will take you on a brief journey through three government teams that are using Kanban to define, measure, and improve their performance as well as their processes and quality of work. Throughout this talk, I will explain what Kanban is, show three different approaches I have used when implementing a Kanban system, help you know when your Kanban system is predictable and when it is not, and provide simple steps so you can start your Kanban efforts the next day.

Product owner provide requirements and its business value to IT which in turn works on building a solution. Usually the focus is geared towards building the correct solution based on customer’s requirements. But can we guarantee if the requirement and the business value provided by the customer is right? Does the product owner really know if their requirement adds value? We propose a shift in how the requirements should be processed. Instead of accepting requirements based on business value and customer’s need, we suggest a scientific method of evaluating a requirement to see if it really does add any value prior to adding it to the backlog. Most of us in our early school years might have studied in science the scientific method for asking and solving a scientific question.