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.

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?

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. 

Many of us having been heavily influenced by Don Reinertsen’s “Principles of Product Development Flow” and others who have advocated a focus on flow based optimization. Unfortunately, some of the key premises for optimizing flow are counterintuitive and counter to traditional practices. For example, the supposed benefits and the economies of scale with large batch sizes, or the belief that systems are optimized when the utilization of individual resources are optimized. Given these beliefs, how can we show in a simple and objectives way that these long held views and associated practices are actually counterproductive to our end goals? With games of course! This workshop will introduce dice games that demonstrate in a Scrum and Kanban context how small batches and a focus on flow vs. optimizing utilization leads to better team outcomes. Participants will be organized into teams of 4-5 people and play a game that simulates—in a fun way—the complexities of real product development work. Each team member will have an assigned skill that aligns with an activity type (e.g., analyst, developer, tester) in the team work flow. Each “story” to be worked will require varying levels of effort for each activity type. The dice provide the variability inherent in knowledge based work, with each roll determining how much “work” each person can accomplish in a fictional day. The quantifiable results of the game will demonstrate how a focus on flow can help lead to better team outcomes, providing attendees with a new tool for helping others understand why they should “go with the flow”.

Stop getting good at process and start getting good at business! This session is for anyone who is seeking practical, proven techniques to create a Lean Portfolio Management Office. Participants will explore the pre-requisites for a Lean PMO, the role of the PMO in agile delivery, and a high level overview of a Portfolio Kanban System that balances the speed of agile delivery with the accountability and transparency needed by organizations for complex programs.  Along the way, you will hear details of how a dynamic product company evolved to a people-centric, flow-based PMO.

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.

Organizations follow frameworks and playbooks and drive to achieve successful results in their Agile transformation.   As the organization and teams continue on their journey the challenges may seem to increase rather than decrease.   The larger the organization and the more detailed their software development life cycle the more arduous it is to make the shift.   This session discusses observations on five common misconceptions that slow an Agile transformation and the ability of teams to embrace the mind shift needed to be Agile.

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.