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.

Have you heard people talking about Test Driven Development (TDD) but never tried it? Now is the time to try! This session will lead its participants through a programming challenge. Don't worry, it's safe. We're going to do a technical version of "follow the leader," where you will do the programming by following along with the session's facilitator. We'll debrief the exercise at the end. Please do bring a laptop or be willing to pair up with someone who does.

We will use the Python programming language, and PythonAnywhere web-based environment to avoid setup and configuration activities. You do NOT need to know Python (or any programming) to participate.

Agile practices have done a magnificent job of speeding up the software development process. Unfortunately, simply applying agile practices to testing isn't enough to keep testers at the same pace. Test automation is necessary to support agile delivery. Max Saperstone explores popular test automation frameworks and shares the benefits of applying these frameworks, their implementation strategies, and best usage practices. Focusing on the pros and cons of each type of framework, Max discusses data-driven, keyword-driven, and action-driven approaches. Find out which framework and automation strategy are most beneficial for specific situations.

Other than using specific frameworks as examples, the presentation is framework agnostic, really focusing on capabilities of different types of framework, and how those might or might-not fit your company's/software's needs. In the talk, 5 different types of frameworks will be discussed: Record/Playback (Linear), Modular/Structured, Data Driven, Keyword Driven, Action Based, and of course the combination of these as Hybrids.

At the end of the talk, depending on questions, and how much time we have left, a slide with a long list of specific testing frameworks is displayed, and an open discussion of who has used what, and what has/hasn't worked for them is had.

If you are new to test automation or trying to optimize your current automation strategy, this session is for you.

While the IT side of this F500 financial services client has been practicing agile development for years, the business side is still, in some cases, more waterfall and traditional in its approach to requirements and releases.  In this experience report, we will hear from Associate Vice President Charlie Kennedy of Nationwide Insurance on how we have accelerated business-side agility by:

• Re-organizing from functional silos to Product-Based Value-Stream Teams
• Redesigning the business requirements process to achieve a continuous flow of MMPs into the teams
• Utilization of Big-Room-Planning techniques to create alignment across a wide set of stakeholders and dependencies
• Design of a Product-Manager-to-Product-Owner fan-out concept to achieve omni-channel digital delivery
• Design of a portfolio-level visitation system to track the flow of MMPs across multiple investments simultaneously

In the last five years there has been a tremendous surge in the volume of Federal procurements calling for lean and agile solutions to complex problems.  In spite of this, many of these same Government agencies still cling to traditional waterfall models of delivery.

How do we embrace lean and agile principles while delivering under these constraints within large-scale Government agile software delivery initiatives? 

What agile approaches can be effectively used "out of the box" while others may need to be tailored to address legacy Government processes and operating environments? 

In this talk I’ll walk through each of the seven Lean principles and unveil how -- on two Federal Government scaled-agile engagements -- specific lean-agile processes and approaches were tailored for program delivery success, while remaining compliant with agency mandates.   

What every Product Manager needs to know about scaling Agile

 Product managers play a crucial role in a scaled Agile organization. But what does it truly mean to play this role? Product Owners sit with the scrum team and make the day-to-day decisions that fundamentally shape your products. Product Managers want to make sure the reality of the product direction is in line with what the market needs, but don’t have the time to sit with 10 scrum teams. What is the role of the Product Manager in a scaled agile organization and what role should PMs be playing in defining, executing, and commercializing an organization's product offering? How can Product Managers effectively manage and communicate the product roadmap when hundreds or thousands of stakeholders are involved?

Are you sometimes overwhelmed by the never-ending stream of Agile teachings you’re supposed to know and have at your fingertips to address every possible situation in the proper Agile way?

Sure, Agile is a “mindset” and you’re supposed to “own your process” but the reality is, that’s not how we teach or learn or usually even talk about Agile. Instead, we are bombarded with ever more retro formats, technical practices, prioritization techniques, facilitation tips, and other snippets of wisdom that we should all know before we can be considered good Agilists. And if your job title is Scrum Master or Agile Coach, the range of things you’re expected to master only expands.

In this session, Mathias Eifert will share how he found his footing in a vast sea of loosely connected Agile rules, processes, techniques and tools by recognizing that a small number of fundamental concepts can help with finding answers that are “good enough” as a starting point to tackle most new contexts or problems. Together, we will examine how many established Agile approaches can be traced back to these essential concepts and hopefully help each attendee a little further along on their journey from rules-based Agile to fundamental understanding.

Scaling Agile is easily misunderstood. Scaling is the term we often hear used to describe using Agile methods with large enterprises.  Larger enterprises often deal with bigger and more complex problems than small ones. They have more employees, subcontracting companies, different business units, more processes and a strong culture that defines how things are done. At the same time, they need to be able to deliver results in an ever-changing business environment. They need to be Agile but the bigger the company, the bigger the challenges are for scaling Agile. 

Scaling frameworks available in the market today are maturing quickly and provide a variety of choices. Like the Agile Manifesto, these frameworks are based on principles, and they vary widely in the specificity of the recommended approach.

In this session, we will compare how two scaling frameworks, LeSS and SAFe, address the challenges of agility at scale.  We will talk about how these two frameworks align, coordinate, and manage dependencies across multiple teams to maintain consistency and agility at scale. 

Skeptics may say that it is too hard to bring User Centered Design (UCD) into the Agile process, but when the two worlds collide you get the benefits of both.  UCD can improve your game by ensuring that your focus stays on delivering product value and that teams produce working software that end users will actually use.  During this talk you will hear from experts with both Agile and UCD experience who will share stories and examples of how their teams have successfully integrated the two practices and what challenges they have faced along the way.  In addition, you will leave with three tools that you can use to integrate UCD into your projects today.

Do you have a person hanging around your agile team who is responsible for training clients or end-users on a product or service you are developing?  (Or, maybe you are a learning professional (a trainer, instructional designer, e-learning developer, or curriculum designer) embedded with an agile team?) Who are they? What do they want? What can they do for your agile team? Leveraging insights from learning professionals working with agile projects, this session will explain the role of a learning professional; offer some potential benefits of having a learning professional embedded on an agile team; and offer some practical tips for a successful relationship between agile teams and learning professionals.

My name is Dottie Swanson and I’m a Skeptic …

I began my career as a software developer and grew into a Project Manager role. I thrived on the control – I could dictate delivery dates to my team without debate. They were always so quick to appease me by immediately getting to 90% completion without a hitch. They were such good soldiers by never allowing scope creep and always sticking to the requirements. Sure, there were big surprises near our delivery date, but that’s normal, right?

Then a client asked me to take a Scrum Master role on an Agile program. I was sent to a CSM course where I spent the entire two days with my arms crossed and a giant pouty face. The program kicked off and we started “failing” early, my soldiers were retreating and sabotaging Agile. My client still wanted Gantt charts. My inner cynic hit rock bottom and I felt overwhelmed – how is this ever going to work? Since the client was requiring Agile, I had to reset my thinking, seek help and get the team onboard. Once I began to embrace Agile, I was able see that the PMBOK and Agile are not mutually exclusive.

Today, I am still in recovery and require Agile on all of my programs.

Join this session to hear my experience as a skeptic and my journey so that you too can transform to an Agilist.