Agile2019

Abstract:
"How to we associate T-shirt sizes of epics to get a date?"
"How many of these features can we get done in H2?"
These are common questions that cause lots of pain in product development. Commonly people turn to labor intensive approaches such as planning poker of massive epics which are no more reliable than a guess.
What if we could answer those questions reliably without having to estimate every story or even break them all down from the epics.
Come learn how to use reference class estimation to work out the overall size of large scale efforts before you do a single story breakdown.

Learning Outcomes:

• Audience members will learn how to use historical data to accurately size large-scale product development efforts.
• How to effectively communicate the impact on these sizes to the probability of delivery within the needed timeframe.
• How to communicate these things effectively and visually to teams and stakeholders.

Attachments:

• Agile2019SizingMonteCarlo.pdf

Abstract:
Popular opinion is that teams should be product-based ("Products not Projects"). This idea makes sense if you build products but not if your business model is project-based work for clients. What if your projects create products for clients? The product and project models need to work together.
I'll review project and product models to identify the key elements of each, and show how they can be combined to best meet the needs of clients and teams in a mixed project/ product world. I'll show how to use the research done by the #noprojects folks to improve projects and figure out how to apply a product mindset to get the best of both models. I call it #whenprojects.
Join me as I share my experience of discovery, realization and leading change.

Learning Outcomes:

• Product management concepts for project teams
• How to introduce new ideas to a team
• How making small changes can make a big difference
• How to turn negative ideas into positive actionable steps (from #noprojects to #whenprojects)
• How to identify and combine parts of two seemingly conflicting models (project and product)

Attachments:

• Product or Project - Susan Almon .pdf

Abstract:
Barco Demetra aims to support dermatologists in detecting skin cancer sooner. It is a transformative medical device that helps them to work smarter and faster. At least, it is now. Two years ago, Demetra was still in the conceptual phase. During this fast-paced product development track, including both hardware and software development, we gathered our own learnings on the good, the bad and the ugly."
At the start of the project, there were many unknowns. Along the way, we tackled those unknowns whilst handling what seemed like conflicting priorities. Only via many interactions with dermatologists and deep insights into their workflow, we managed to design an optimal solution. The result is a tailored software app for the hardware device, that collaborates with a web frontend, orchestrating all data in the cloud."
New constraints posed new challenges but also created great opportunities: only through ruthless and decisive product discovery, hard prioritisation, early customer feedback and established development practices did we manage to timely deliver a solution that can potentially save lives. Our constant state of uncomfortable excitement confirmed we were on the right track.
We will tell this story from our product management point of view and demonstrate how we achieved the right circumstances for building customer confidence, the roadmap and the product.

Learning Outcomes:

• “What’s the verdict, doctor?” Integrating user research and testing in agile product development
• Creating the right circumstances for continuous product feedback, handling continuous scope changes and conflicting priorities
• Forming and adapting the release map and product backlog accordingly
• Different development teams, sites, time zones… Managing all cogs in the wheel.
• Building stakeholder, delivery and early-adopter confidence: get to a state of uncomfortable excitement
• Developing an end to end solution for medical devices

Attachments:

• Agile 2019 - Barco Demetra - Agile Under Pressure - Shipping a medical device in less than two years (cleaned).pdf

Abstract:
The product owner role was introduced in Scrum in 1993. So, the role has been around for ~25 years. Yet, still we struggle with the nature of it. Is it simple or complex? Is it inward or outwardly facing? It is about backlogs and stories or something more? And is ‘ownership’ the whole point?
In this talk, Bob Galen will be sharing his 4-Quadrants model for what effective (good) product ownership looks like in the real-world. It will start with balance, because the role is so broad and deep in its nuance. The essence of the 4-quadrants says that there are product, project, analyst, and leadership parts to the role. We’ll explore each in turn and talk about cross-connecting each area. We’ll also explore the partnerships that are key to success.
And finally, we’ll even explore product ownership at-scale, which is its own can of worms. So, we’ll help with that too. You’ll leave this session certainly understanding what Product Owner Excellence looks like and how crucial it is for team success.

Learning Outcomes:

• Introduce the 4-Quadrants of Agile Product Ownership as a framework for skills, responsibilities, and expectation management.
• Deep dive into each of the quadrants and explore that aspect of the role; wrapping up with quadrant interactions.
• Finally, explore Product Ownership at-Scale and the challenges associated with it.

Attachments:

• What does Good Look Like - The 4-Quadrants of Product Ownership, v1_compressed.pdf
• 4-Quadrants of Product Ownership worksheet.pdf
• 
  
  • 
    

Abstract:
Most organizations still rely on some form of a roadmap. The traditional roadmap, however, fails to meet the needs of modern product delivery teams. A good roadmap should allow for agile practices such as daily standups and planning. They should create high visibility and transparency, operate with low overhead, and provide the right information to the right people at the right time.
In this talk, Chris will share how he’s implemented a Roadmap Wall. He’ll show how to incorporate the roadmap components into a highly visible and actionable format. The roadmap wall has multiple benefits and will:

• give leadership and executives visibility into how their decisions influence features, story backlogs, and priorities
• leverage delivery teams to understand technical feasibility tradeoffs
• provide options for satisfying competing customer needs
• demonstrate a clear picture of how business objectives link to customer needs

To realize these benefits, Chris will leverage a variety of familiar tools. He will show you how to use a kanban system to manage business objectives and OKRs, utilize priority queues, and incorporate WIP limits. You’ll learn how using an opportunity canvas and opportunity solution tree clarifies the customer’s need. He’ll show you new ways to use story maps when detailing features, improving communication and planning.
In the end, you’ll walk away with a new method for visualizing your product roadmap, giving your team better decision-making abilities.

Learning Outcomes:

• Learn how to build a simple kanban system for managing business objectives and OKRs
• Use an Opportunity Canvas to build alignment and identify risks
• Create an Opportunity Solution Tree and learn how to map objectives to customer needs to product features
• Utilize an Opportunity Solution Tree for creating product options and making tradeoffs
• Use feature level Story Maps to meet schedule and budget concerns as well as improve collaboration between delivery teams and the business

Attachments:

• 2019-08-07 Agile2019 - Roadmap Wall.pdf

Abstract:
It is extremely difficult to say no - we all know this! However, an essential part of a Product Owner’s role is being able to determine what features will provide the most value to the customer and prioritize those features over others. Being able to say no when necessary is key for Product Owners to successfully build a product that will provide the most value to their customers. Still, many Product Owners find it extremely difficult to say no.
In this session we will talk about why it is so difficult for people, especially Product Owners, to say no. We will discuss the importance and power of the Product Owner’s ability to say no when necessary. We will then learn and apply a variety of techniques that anyone can use to help make saying no easier.

Learning Outcomes:

• Discuss why it is psychologically difficult for people to say no
• Discuss reasons why a Product Owner may find it difficult to say no and the importance of being able to say no
• Learn techniques that anyone can use to help make saying no easier

Attachments:

• Just Say No.pdf