Speed.

It's been a driver in our industry before it was even an industry. The more Agile becomes more mainstream, the more we think it's part of the package. Books are out promising that certain frameworks can deliver twice as much in half the time. And yet, teams still struggle delivering what's expected of them.

Once I started asking people of all levels of leadership what they thought speed would give them, it allowed me to develop some experiments around those expectations.

Please join me for a case study where we discuss the need for speed, the origins of that desire, and the ways it manifests itself into deliverables. My desire is for the audience to take away some powerful learning into their places of work. Only by understanding the expectations around speed can we reset them into an environment built around trust and support for motivated individuals.

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.

We all know how people use design thinking to create better products and deliver delightful experiences to our users. However, design thinking can be an excellent tool to use for organizational change. In the case of organizational change, our product is the change that we are trying to drive, and our customers are those people who are impacted (internally and externally) and have to live with that change. In the same way that design thinking puts the user front-and-centre for products, it can be used to put people in the organization front-and-centre. In this talk we will discuss how design thinking works and, as a case study, how we have applied it at Scotiabank to help drive adoption of the Bank’s NPS customer insights into building solutions that serve our customers. In that program, previous internal processes were ineffective in pushing relevant data to delivery teams at the right time. Using a Lean or Agile approach would have provided some benefit, but taking a design thinking approach uncovered an array of useful insights to make the whole process more purposeful. Learn from this example to explore how you might incorporate design thinking to drive greater effectiveness and relevance for your team’s body of work.

The popularity of Functional Programming is booming! Are you still wondering what all of the fuss is about? Come to this session and find out! This is an introduction to the power of functional programming. It covers functional programming's basic concepts, and shows you how functional programming will make software simple, elegant, easy to test, and lead to cleaner code. I will share my experiences learning, so you can avoid some of the pitfalls. So if you enjoy coding, love clean code, then you should start learning Functional Programming right now.

Description:

I see that a lot of organizations use metrics in inappropriate ways to measure teams. At the heart of these metrics, nine times out of ten, are velocity and story points. These metrics lead to a lot of mistrust, fear, and bad technical practices. This talk will focus on shifting the focus to diagnostic metrics.

 Before shifting focus to diagnostic metrics, we need to understand what inappropriate metrics are. When questioning teams about why their velocity was lower from one sprint to another, teams are more likely to inflate their estimates to avoid questions in the future. This is one of my scenarios. We will explore this case and my other top-ten based on the 165 teams I have interacted with. Focusing on one metric does not provide a balanced view of the team.

For balance, I promote five metrics. The combination of metrics balances each other. These five metrics are lead time, quality, happiness, agile maturity, and business value. Focusing on these five metric areas can be used as a diagnostic tool to help teams grow and support coaching. During the session, we will use my Excel-based tool and visual model to simulate this balance.

When you push shorter lead times (how fast) on a team with a lower agile maturity, the first thing to change is quality, followed by happiness and then the delivery of value. Conversely, if a team focuses on TDD, the first thing to change is quality, followed by agile maturity, reduction in lead time, and increased delivery of value.  

Teaching teams to harness data in a positive way will help them to flourish.

Products are not Projects — simple.

A project is:

"a set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations."
"What is a project? definition and meaning". BusinessDictionary.com. Retrieved 2016-04-19.

Product development cannot be constrained to "certain cost" and products do not have a prescribed end date...so no "fixed period". So long as the organization finds innovative ways to meet market demands, the products they develop will evolve.

So, why all the projects?

I teach Scrum — it's a process framework that has been used to manage complex product development. Yet:

• ~55% of the people in my classes are "Project Managers"
• ~90% work daily in "project teams" (sic)
• and ~0% are ready to let go of Project Charters!?

Project charters in a complex problem domain create an illusion of safety, certainty, and confidence, but are wholly inappropriate in most organizations represented at this conference for one simple reason: the nature of our work is complex and therefore it is not possible to predict a "set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations".

I get frustrated with code that is sprinkled with poorly named classes, methods, and variables.

Whenever I work on a team or coach a team, I put a lot of energy into choosing good names and sensitizing my teammates to the power of naming.

I've noticed that developers spend most of their days reading code rather than writing code. I suspect you've noticed too. Creating understandable code is a high leverage activity for any team. And naming is where I start.

The core of the session is an example that illustrates the process and power of choosing good names. The example comes from a recent project. There will be code.

I will connect the example to specific techniques and patterns for choosing good names and share resources that you can use right away.

My goal for this session is to sensitize you to the power of naming.

Cultural change in any organization or team is admittedly one of the most challenging processes. However, any team or group of people can be empowered to find insights and a way to address cultural issues with the techniques of "Popular Theatre" - described as theatre for the people, by the people, with the people. Participants will be taken through the simple steps of identifying challenges/problems, role-playing and creating scenes that provide a window into the issue, where everyone looks at it together and suggests steps and solutions. These scenes become a rehearsal for reality.

• Note cards and stickies? Everybody scoffs at them!
• Jira? Evil!
• Trello? Sucks!
• Pivotal, Rally, Blossom, Asana, Basecamp, Sprintly? Argh!

The problem with every tool is actually simple: they solve for someone else's problems...not yours. Few aspects of the modern workplace receive as much attention and create as much controversy. Let's explore how "Agile Tools" impact our work.

Join Jon & Matt on a journey of enlightenment and witness their transformation from "Command and Control" to "Servant Leadership". Through their journey, discover the tips and tricks that helped two budding tech workers discover, embrace and live the Agile values. Discover common pitfalls and the resources that are available to help you overcome them.

As many in our industry are learning, becoming and living as a Scrum Master is no easy task. Scrum Masters come from many different disciplines - sometimes from outside of the technology space all together! Becoming a Scrum Master requires self-guided learning, coaching, experience, and, (most importantly) failure.

Jon & Matt will walk through their own journeys and make stops along the way to discuss the failures they experienced as well as the resources and materials they used to continue on their journey. They will also touch on what's next: Potential career paths for scrum masters, and how existing Scrum Masters can continue their own agile journeys

Deliver slower. Spend more money while you deliver that software. Go ahead and take your time, we can wait for that new functionality….. Said no customer ever!

It would be hard to deny that our world seems to be moving faster than ever.

There is more than one way to deliver faster. One is to incrementally get things in front of your customers rapidly. Another is to make sure we do not waste time building the wrong thing. How does Continuous Delivery address these concerns and at the same time help us eliminate many of the risks inherent in software development?

Join Cheezy as he brings his years of experience on how this is done in different environments and contexts. In this talk you will learn how Continuous Delivery is done right and why you might want to consider it for you company.

Confused about Continuous Integration vs Delivery vs Deployment? Not sure how to take the next step towards Continuous Deployment?

In this session, Nayan will remove the confusion around the "Continuous" terms. He'll then show you how to go from Commit to Production with no manual steps, while remaining confident that your production system remains stable. We will do this with a variety of open source tools -- from traditional build & integration tools to modern deployment environments & monitoring. You'll leave the session inspired and ready to build your own Continuous Deployment Pipeline when you get back to work.

The Titanic was going 42 km/hr when an iceberg was spotted dead ahead. I imagine there was a wild scramble to do something to save the ship. I often wonder if they had rearranged the deckchairs, as I’m sure the outcome would have been different. As crazy as this sounds, there are many organizations who rearrange the deck chairs and can’t figure out why their transformation continues to fail. Adding more process, firing leadership and coaches, planning for efficiency, throwing more money at the problem and so much more. None of which helps the situation, and if anything speeds up the inevitable.

In times of change, your response to the problems you will encounter can make the difference between success and failure. During this session, you will learn The Responsibility Process^TM, and you will start to understand and know how your response to problems is creating your reality. You will also start to understand how by creating an environment of shared responsibility, it is possible to avoid the icebergs (or at least survive the collision).