Good retrospectives (you know, the ones that actually lead to real change?) rest on three pillars:

* people,
* process, and
* follow-through

What makes retrospectives so difficult is that if any of these three pillars starts to crack, it's very difficult for the retrospective to be a success.

Ultimately, getting the right people in the room, utilizing a good process to facilitate the conversation, and following-through on the learning outcomes depend on having an organizational culture that encourages learning, transparency, feedback loops, and continuous improvement.

If this sounds like your company already, then great! This talk is not for you.

For everyone else, join me to explore how effective retrospectives can break a downward cycle of disillusionment and malcontent and transform you and your team into engines of learning and growth.

There seems to be some confusion (not to mention strong opinions!) about when to use Scrum vs. when to use Kanban. At times purists on either side have drawn the lines and set up camp in an almost warlike approach, making it difficult to wade across the middle battlefield of information without stepping on metaphorical land mines or getting peppered with judgmental opinions, rhetorical quips or social media blasts.

In this session we will explore a case study of a department within a financial institution that is currently experiencing a transformation to Agility using both Scrum and Kanban. By the end of the session I will provide evidence of meaningful actions the department has taken and outcomes they have achieved to help move their team and organization ahead on a path to greater Agility.

When the people of an organization embark on their quest for increased agility, they are essentially begin working on the opposite side of a paradox that has been ignored. Often times, though as they take their journey, they begin experiencing the downside of now ignoring the the traditional, control-based approach and there is an outcry to revert. A dilemma is created.

What are these paradoxes? Well, the first four you encounter are described in the Agile Manifesto’s values. If one could have both sides of the “over” statements easily, we’d take them. Successfully maximizing the appropriate upsides of each side of these values while minimizing the downsides becomes a swinging pendulum to manage. This becomes key to leading others in your organization. If you are a manager, team leader, or executive trying help your organization get traction, then this session will provide some new insights into how to balance change with stability.

These four values are just the start of the paradoxes that will emerge as you take your journey. This workshop will help you use a technique called Polarity Management to help manage the upsides and downsides of this balancing act so that you can lead people effectively. Once out in the open, dilemmas created with a swing one way or another become easier to handle and perhaps can even be avoided.

Building the right thing and building it quickly! How about building it the right way?

"Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday’s code.” – Dan Salomon

Is your delivery team delivering Spaghetti code, all complex and tangled up? Want them out of bed on a Monday and working on Lasagna code, all structured, well defined and layered?

Starting out introducing Agile engineering practices is difficult. What is it? Where do you go? How do you start?

In this session Agile Engineering practices, concepts and philosophies will be introduced. Through structured exercises, attendees will demonstrate the following agile engineering practices:

• Test Driven Development (TDD)
• Pair Programming
• Continuous Integration
• Refactoring

Through this highly interactive hand on workshop, you will learn the concepts and develop an understanding of Agile engineering practices in a playful way without touching a single piece of code.

Target Audience: Scrum Masters, Agile Coaches, Executives, Managers, Agile Leaders and Scrum Teams.

Do you want people to feel part of a group/team or part of an activity? Then ensure that they are included and engaged. Do you find facilitating a large group of people unmanageable, people disengage? Try Liberating Structures with your teams and organization.

Liberating Structures, created by Keith McCandless and Henri Lipmanowicz, covers a set of easy to learn, yet powerful ways to collaborate as a team. It makes it possible to build the kind of meeting that everybody looks forward to attending and participating. Liberating Structures encompass microstructures that promotes collaboration and trust. It is known to foster lively participation in groups of any size, making it possible to truly include and unleash everyone.

Participants learn how to use these microstructures to simplify scrum meeting outcomes, help teams collaborate and become more productive.

Are your retrospectives more ranting session than anything else? Are the outcomes seldom actionable? Are people quiet and it feels like only a select few always speak? Sounds familiar...if yes, this session will equip you to truly get measurable results from retros. This session will give you tips and tricks on how you can meet people on their journey and coach them to become a better team player. It will also provide guidance on how a team can continuously improve, and still keep it interesting sprint after sprint after sprint. Let's coach to make retros more "doing" sessions, and help teams truly embrace the spirit of continuous improvement. Make retro your friend and not foe!

From the diary of a fat coach comes the story of how Agile transformation is like reducing weight. She is sure that you have been on some diet at some point of your life, may be you are on one as you are reading it. Are you curious about how it links? During the session we will go through various similarities and shifts which are needed to gain success in both. We will also explore how the common pitfalls are also similar. Coaching both is an ART and calls for humanizing continuous improvement and transformation.

Once upon a time, in the not so faraway land of Corporatedale, was an organization called WeWin. The King of WeWin had an impeccable strategy to conquer the world, until he stumbled upon a mighty challenge of soldiers whose heart did not align to King's vision. The soldiers enjoyed the merit of the present and did not believe in a change. The culture of the army was eating the strategy.

The misalignment was cancelling out the efforts. Everyone was busy, but nothing was happening. The kingdom looked upon the King of WeWin to perform a miracle. One fine day, a switch flipped and they realized that the magic lay in each one of them, and it was up to them to create the environment they craved. This led to strategy and culture joining hands with the power of self-organized autonomous teams. From that day forward, the army of soldiers marched on and went on to conquer their world.

If the story sounds similar to your own, come join the session to discover the story of how to Flip the SWITCH!

Myth: "Agile teams don't document."
Truth: Some of the best documentation we've ever seen comes from Agile teams.

Agile Engineering practices have revolutionized the ways in which documentation is treated and produced. In high-stakes environments with heavy compliance and audit requirements, a dangerous tendency toward exhaustive documentation is common. This workshop provides direct guidance and simple tools to help a document-heavy workplace think differently about documentation.

I have developed this workshop to help an organization reframe their understanding of documentation with respect to knowledge work in complex environments so that they may eliminate unnecessary artifacts and simplify/automate others.

Participants learn the “Skills Matrix” technique for getting a new Agile team started and for getting established teams to leap to the next level of capability. This technique has been used for decades at Toyota to create a team development plan in a collaborative, visual way.

ELEVATOR SPEECH:
“We can’t make decisions or agree on priorities. So, we have the same meeting over and over. Literally, the same meeting.” If that could be said about your workplace, this interactive session is for you. Learn simple strategies and ideas for meetings that matter - those you run or those you attend.

SUMMARY:
Too many bad meetings. That's one of the most common sources of workplace whining. Today, especially in software development and delivery, our work is too complex for one person to make all the decisions or know all the answers. Everyone's contribution is needed. So, we have meetings. And some are a painful mix of frustration and boredom. When we can’t make decisions or agree on priorities, we have the same meeting over and over.

When we're the one hosting the meeting, there are lots of facilitation techniques we can employ to keep the discussion on track, on topic and on time so we can reach good decisions and plan effectively. But what if it's not our meeting? What can we do when we're not in charge?

Join Sue in exploring some simple techniques you can use at your next meeting to make the experience better for you - and for others who attend.

INFO FOR REVIEWERS:
This new talk is inspired by several years of leading the workshop, Facilitation for the Agile Workplace, accredited by ICAgile. Learners often wonder, "What about the meetings where I don't have control?" It draws on communication and facilitation techniques I've used in a long career in business and tech. Sources will include "Mining Group Gold," "Facilitating with Ease," "Liberating Structures," and "Leading Geeks."

It's an interactive session with an element of play - a simple board game with dice and cards.

By the time of TAC, I will have presented this session at PRDC Deliver and will have had an opportunity to tweak it, based on that experience.

Every organization is struggling with the issue of how to reconcile project management and agility. This is a serious challenge for the project management community who often doesn't understand what agility is, particularly within the context of an established organization. This can also be a serious challenge for agile practitioners who may not appreciate the potential value of management. We need to work together.

Project managers have a lot of important skills and knowledge to bring to an agile team if we help them to do so. At the same time they also have some mindset and cultural issues to overcome, something that they may also need help with. In this workshop we will identify the real value that an existing PM can bring to an agile team and explore how they can move into new agile roles to do so.

A rant, with evidence, on why electronic tools in general, and JIRA in particular, are anti-Agile. Participants will use the Agile Manifesto to evaluate the electronic tools they are currently familiar with. JIRA is used as a case study.

NOTE: Scrum asks us to have courage. The Agile Manifesto asks us to value individuals and interactions over processes and tools. I hope the organizing committee will consider this proposal despite the risk that it might offend some tool vendors. If we can't speak freely about our experiences with tools, we will fail as a community.

In today’s challenging workplaces, organizations need to continuously focus on delivering value to the customers. Challenged by competition from all over the world, changing technology, increased diversity of the workplace and customers, organizations need to adapt their practices and behaviours. In this session, we will focus on Product Owners and the ownership impact on the business. Also, we will discuss the shift to a product oriented organization and the specifics this approach introduces.This will be done using real life examples and applied, simple yet captivating exercises to find the owner inside you.

One of the first actions organizations follow after deciding to jump into an agile transformation is assembling an agile team. To come with the "team" a hiring process begins. The hiring managers rush to pick the people following a generic profile of the ideal members.

After some time the selected candidate decides to leave you earlier than expected, generating high levels of stress across the project to was he/she was allocated. In other cases the organization is “forced” to keep the person as part of the team even though the performance of the employee is not the desired because of the person’s replacement process can be very complex.

In this workshop, we will share some tips to find the “perfect fit” for your organization. Furthermore, we will learn the power of asking the right questions at the right time so that your organization can get the right fit for your team.

Join us and learn how to improve your hiring process and start enjoying the benefits of finding the right people in your organization.

How much of what we do requires courage to ask for what we need? How many times are you asked to make a team agile and the team or leadership is not ready? What stops teams from speaking up about what is upsetting them? Who has the courage in the room to speak up what needs to be said and to do what needs to be done?

Having the courage can be made easier once you have tools and are willing to be vulnerable to take that first step. Teams that can step into this courage are more successful and more productive.

In this talk, Joanne will explore what is needed in our teams and ourselves to bring the elephant onto the table and into the light for all to see. Once we make the elephant visible it can be addressed.

Using a variety of techniques such as team happiness, team agreement, safety checks, assumptions, clean language, retrospectives and self awareness (conscious leadership) you are able to take that step more courageously.

Courage will start with you and can make a difference to our lives and our teams. Do you want to explore more? Join Joanne.

A fundamental philosophy from the early days of Agile, and particularly of XP, is that teams should own their process. Today we would say that they should be allowed, and better yet, enabled, to choose their own way of working (WoW).

This was a powerful vision, but it was quickly abandoned to make way for the Agile certification gold rush. Why do the hard work of learning your craft, of improving your WoW via experimentation and learning, when you can instead become a certified master of an agile method in two days or a program consultant of a scaling framework in four? It sounds great, and certainly is great for anyone collecting the money, but 18 years after the signing of the Agile Manifesto as an industry we’re nowhere near reaching Agile’s promise. Nowhere near it.

We had it right in the very beginning, and the lean community had it right all along – teams need to own their process, they must be enabled to choose their WoW. To do this we need to stop looking for easy answers, we must reject the simplistic solutions that the agile industrial complex wants to sell us, and most importantly recognize that we need #NoFrameworks.

Elevator Pitch: From infancy, we’re rewarded for being smart. School reinforces our joy in having the right answers. But in an uncertain workplace that calls for experimentation, risk taking and continuous learning, our need to be right can hold us back. What if giving up that need to look smart is the smartest thing we can do?

Session Description: Almost from birth, we’re rewarded for being smart. Our formal education creates an addiction to being right and we’re ashamed (sometimes, even shamed by others) if we’re wrong. While it’s nice to feel smart when we get that A, certification or degree, a need to be right can be a handicap in a furiously uncertain workplace that calls for experimentation, risk taking and continuous learning.

The human brain craves certainty, or so the neuroscientists tell us. But in this changing world (VUCA anyone?) certainty is almost impossible to find. What if that’s OK? What if it’s OK not to know, not to have the answers? What if the smartest thing we can do is give up our need to be smart? What if, sometimes, it’s OK to be a little bit stupid? Can you imagine a future like that?

Join Sue in an interactive exploration of the value of not knowing, of being wrong, of making mistakes. We’ll do some playful experimentation with failure and practise shifting from “Smarty Pants” to “Curious Cat” for fun and profit.

Info for reviewers:
This is a new talk inspired by many years watching people – myself included – delay taking action, avoid trying experiments and wait to be told what to do because we want to “get it right” or avoid looking stupid. The point of the talk is that, when we’re creating products and services in today’s market, we can’t expect we’ll always know what to do. It’s impossible to have all the answers – and it wouldn’t be a good thing if we did. Curiosity and an appetite for experimentation are key attributes for today’s workplace - and fundamental in Agile work practice.

As well as personal experience gained over a long career in management and technology, content will be drawn from formal study in team coaching and from readings such as “Better By Mistake,” “Not Knowing,” and “Being Wrong.”

This session is interactive. It will be appropriate for anyone.

I'll have a pre-production version of the “Failure Toy,” designed to teach that it’s OK to learn from mistakes. (I won't be promoting it, just using it as an exercise.)

If you are a coach, your job is to facilitate change in your client’s thinking (beliefs and attitudes), emotions (more mindfulness and resilience) and behavior (creating new habits). Using brain based coaching which is an approach rooted in neuro science, in this talk you will learn the latest insights into how our brains works, and how you can use this knowledge to complement and amplify the principles and practices of Agile coaching to create more effective, powerful, and positive transformational changes for your client.

You may have heard about the #NoEstimates movement, and even #NoProjects. Both of those concepts challenge the assumptions behind two key aspects of delivering software. But what about the process itself? Do we even need approaches like Scrum, Kanban or XP - let alone SAFe, LESS, NEXUS, DAD - in order to be successful? Is following a pre-defined process helpful at all? Is there a simpler way to be effective?

This session examines the two key principles common to all successful software delivery approaches and builds out based on the experience of the participants. Like #NoEstimates and #NoProjects, the name doesn’t really mean to eliminate process altogether, but rather to build a process that works for your team, in your business domain, with your technology stack.