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.

As many organizations have adopted agile development and are starting to undertake a DevOps transformation to complete the lifecycle, it is not always easy to keep traditionally alienated back office practitioners engaged. In fact, many organizations go about engaging developers, testers, operators, ... in a way that does not align with the spirit of DevOps. Many enterprise DevOps transformations fail because of this very reason, this session will inform the audience of what it takes to create a strong and sustainable movement within an IT organization in today's world where people who perform different functions that are seemingly at odds can come together in the spirit of improving how work is done and delivered.

The speaker will approach the topic from an anti-patterns perspective, highlighting the symptoms of transformation failure from structural, procedural, and strategic angles and discussing alternative approaches to enable DevOps transformation success.

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.

Increasingly Agile adoption has focused on how to operate larger enterprises with agility, and run larger and larger initiatives, at scale.

In many cases, organizations have turned to explicit agile scaling frameworks to address their needs to coordinate increasingly larger efforts to deliver value in a way of that does not sacrifice feedback and self organization . Often these frameworks attempt to address the complexity that comes with large scale by adding extra process and procedure. Prescriptive advice is prescribed in the form of additional roles, stages, gates, and methods. This approach to scaling bears more than a little similarity to the heavy weight methods of the past, but in this case merging agile terminology with much of the same framework bloat and bureaucracy we have seen in the past.

As a a result adoptees struggle to understand how to fit these frameworks to their context, and seasoned coaches struggle to wrestle out the good bits.

During this session I will discuss a different approach to scaling agile, one that places an emphasis on both mindset and practice. I'll pay particular attention to the topic of leadership, organizational design, and the role management has to play in designing a system of work that allows larger efforts to work with an agile mindset without being forced into a one size fits all process framework.

A key part of the discussion will be to showcase how core agile methods and techniques can be extended and expanded to successfully manage coordinated agile deployments that range from hundreds to thousands of FTEs. I'll present these techniques by using real examples of agile deployments I have been a part of during my work with ScotiaBank's agile journey.

Key Scaling Practices covered will include:
- The design components required to structure your organization based on demand
- How to continuously de-scale your organization
- "Get Out Of the Boardroom" style governance and leadership
- Operational cadences and Impediment Escalation Flow
- Managing the flow of value at the Business Technology Asset level
- Moving the conversation from stories to domains
- Streamlining finance and budgeting to align to the agile mindset

I hope to illustrate ways that both management and knowledge workers can select techniques that allow them to scale agile as needed to support ever larger initiatives without succumbing to a one size fits all framework that does not adapt constant change.

When Agile first came on the scene it was premised around putting the customer first. But, over the years its focus has evolved and the general perception of Agile today is that it’s mostly a tool for delivering software. Agile’s original focus was mainly on developers and testers, but it never really contemplated design thinking as a discipline. Design thinking, which has been around for decades but is only recently having its ‘moment in the sun’, compliments agile beautifully in that it focuses on trying to solve the right problems for the right people. Design thinking allows us to iterate and test assumptions before too much coding and production-readiness is done, which helps ensure the team is investing in the right things at every stage. It really provides a focus on innovating rather than simply burning down a backlog. In this talk we will discuss different ways to incorporate design thinking into the agile process. You will learn how to yield benefits from bringing these two practices together – most importantly how to best serve the users of the product or service you are delivering. At Scotiabank, we’ve been using these fantastic tools in combination for over a year. It is a journey, and although we haven’t completely solved everything yet, there are a lot of lessons we have learned that can be applied elsewhere.

We are about launch our latest feature to the eager public, when suddenly we get the call all developers dread: The Site is down! Our business is pressuring us to quickly come back up, but we can’t even find the problem! We pick up the red phone and call Karen, "The Site Whisperer." She calmly spends five minutes typing, and announces that she found the problem, and everything is back to normal. Where would we be without Karen? How can we get these skills on the rest of the team, so anyone can work the magic she does?

It turns out that troubleshooting is a learnable skill. Join Shawn as he explores the Science of Troubleshooting. This workshop will examine what is happening during effective problem solving. It will examine types of scientific reasoning, and explore how we are using them to solve problems, sometimes without even realizing what we are doing! Participants will see how, by using scientific reasoning and experiments to build and test hypotheses, they can greatly increase the effectiveness of their troubleshooting and debugging. By making the process explicit even consummate problem solvers can improve how they approach and solve problems. Using the awareness gained attendees can guide others to improve their problem-solving skills.

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.

In today’s fast paced world, we in the Agile community have gotten better at organizing and prioritizing work. We have learned how to focus on high value and eliminate waste in our processes. And yet so much of Agile these days is focused on how we move work from an idea to production while ignoring or undervaluing how to build high quality working software. Our focus is on how to hold retrospectives, collaborate with product owners, and hold daily standups but very little attention has been paid to how we write and test code. This puts your business at risk.

Join Cheezy as he talks about how we often miss the target in our “Agile Implementations”. Instead, he will challenge us to focus on technical excellence as the true Path to Agility. His lightweight approach for teams to deliver software with Zero Defects strips most methodologies down to their bare essence. This allows teams to focus on what is really important - rapidly delivering working software to customers. If you’re ready to take the next step in your agile journey then you won’t want to miss this talk.

Agile teams are always working to discover how they can work best together. By exploring Dr. Howard Gardner's Theory of Multiple Intelligence, we can discover new ways of understanding our teams. With this understanding, we can better adjust how we work to improve teams.

Many organizations flatten management structure when they transform to agile. It soon becomes obvious that important activities done by managers are still needed.  A community can fill these gaps. They can provide morale, governance, learning, and mentorship, recruiting and hiring, mutual support, coordination, sharing, innovation and more!

Unfortunately few companies manage to create a strong community. Even fewer empower that community to fill these gaps. This means they are missing the ultimate benefit of community: a strong, empowered community can transform the organization itself!

Join Shahin and Shawn in this interactive session to explore communities in organizations. Examine the benefits of building great communities. Learn how to spark the community, and how to support it as it evolves. Hear stories of communities empowered to improve the organization. Learn how to make a community into a driver of positive change.

Ever been in a situation when the Product Manager comes and asks for “a couple of small changes that are high priority” and the team says “They’re kind of big. Which one do you want first? Really, really!”.  “I want them all! As soon as possible.”.

There are many directions one can go from here. One can work harder or work smarter. While you probably know ways to work harder, but let’s explore ways to work smarter.

In this talk Ardita will share techniques that she has used which produce good results. She will talk about Product management, technical backbone, collaboration and how all to get Product managers and teams “singing” together in harmony and with focus.

How do you coach leaders in an agile transformation? How does coaching this group differ from coaching on an agile team? How do you coach Leadership as their peer? Agile is always thought of as being ‘down in the delivery layer’ of organizations. But, for us to be truly successful in embracing agility, we need to be more inclusive of all decision makers in the organization. That starts at the top. There are lot of cultural elements and tools that need to be changed across the organization. This requires dedicated change agents to be positioned within the environment of senior leaders to help them embrace agility in their everyday and strategic decision making. Most people want to do the right thing – it’s all about coaching so that, in the moments where our intentions and our decisions are tested by the status quo, we can help our leaders evaluate their choices. This means being a constant influencer, mirror and educator. And, it means sometimes you have to let things go. Successfully coaching leaders through agile transformation requires very purposeful influencing. In this session, we will discuss how to help bring senior leaders along an agile change journey as well as the primary challenges you are likely to encounter along the way and proven mechanisms to help you push through.

Most important factors in any Agile transformation is the ability to react and change quickly, which are most often associated with startups than large enterprises. To really win and transform an organization there are core elements that need to be mastered and executed at the culture level. We will cover these elements and provide you real use cases where transformations both succeeded and failed to meet their potential to prove the relationship

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.

These days, almost every organization is showing interest in Agile. We seem to have all the ingredients for effective transformations: well-known practices, detailed processes, ever-improving tools, extensive literature, myriad certifications, and many consultants. How is it, then, that so few organizations are truly agile?

Gil Broza, author of “The Agile Mindset” and “The Human Side of Agile”, thinks that one particular ingredient has been overlooked in the mad rush to adopt Agile. In this session, he leads us on an exploration of that ingredient and its place in an Agile transformation.

Even as Scrum is increasingly adopted in a widening range of contexts, many business and technical leaders question the value of a Scrum Master. We believe that part of the reason for this is because this role has been often misunderstood by those who function in it. Sometime in the recent years, the focus of the Scrum Master role has changed from that of a leader (albeit a "servant leader") to a detached focus on story points and team dynamics, with little attention to the business outcomes that the team's work is meant to bring about.

As the role has been relegated to that of a “ship’s counselor” for the team, many business leaders are questioning the budget allocation toward the role as it has become less obvious how Scrum Masters contribute to achieving business objectives. Many organizations, therefore, attempt to do Scrum with either just a pro forma Scrum Master (e.g., the former team lead) or skip on this role altogether. Needless to say, both of the approaches prove problematic.

The goal of this session is to explore the current state of the Scrum Master in the enterprise and propose a refined definition of the role, detailing the competence areas key to the effectiveness of the role and describe precisely how Scrum Masters directly impact achieving business outcomes as an expert role that no team, and no business, can do without.

People are generally not great at understanding abstractions or novel ideas when we’re first exposed to them, but we’re pretty good at deriving abstractions or concepts given enough concrete examples. Including examples in requirements (whether that is by user stories, specifications or something else), will help teams understand the purpose of a requirement and lead to creative solutions.

Join Chris and Shawn in this interactive session, as they demonstrate why including examples is useful and what makes an example effective. Learn how adding a few examples can help illuminate the purpose of a requirement and how it helps start conversations into unexplored areas. Learn about the various tools and frameworks that support automating examples. See how team members and stakeholders can work together to develop examples that can lead to unexpected solutions.