Agile Coaches' Corner

With just days before the new year, your host, Dan Neumann, figured it’d be the perfect time to discuss New Year’s resolutions! Many people set New Year’s resolutions, but the problem is: they don’t keep them. Some research even says that only 8% of people actually achieve the goal they’ve set out for. Many of these goals don’t even reach a two-week shelf life before many people give up

On today’s podcast, Dan Neumann is joined by his collaborator, Sam Falco! Today they will be comparing a product-focused approach versus a project-focused approach and highlighting some of the major differences. They also cover how to apply a product mindset to a project-focused organization and offer some key tips on how to effectively implement either!

 

Key Takeaways

What defines a project-based approach?

A defined start and a defined end

Success is defined at the beginning by doing the project within scope, budget, and within the estimated time and to deliver on that

Check off the tasks and get to the end

This approach works best in best-practice or turnkey solutions where a defined process is always going to give you the same outcome

The focus is on completing tasks

What defines a product-based approach?

No defined beginning and end

Starting with an undefined want or need

Delivering in increments

Instead of asking, ‘Did we do all the things?’ success is defined around user adoption and user retention as well as revenue increases and/or cost savings

Think of the three Vs: Vision to Value to Validation (these three Vs are also aligned with the three pillars of empiricism [which is what Scrum is based on]: transparency, inspection, and adaptation)

With more complex work like software development, a product-based approach tends to work the best (as you will generate less waste and be able to change course as needed)

Focused on achieving outcomes

What exactly is a product?

Anything that can be put out into the market and could satisfy someone’s needs or wants

Something that will generate a benefit for the producer of the product (whether that is revenue, new customers, cost savings, etc.)

Once that value is created, you want to release frequently and get feedback from the consumers of the product

The mindset of product and some additional key pieces of information:

Creating a sustainable pace (don’t bombard people with updates nor release too infrequently)

A product mindset can be applied to a project-focused organization

Remember: mindset is not just the way we think about something; it’s thinking that drives our actions (so you can still be in a project environment but have a product mindset)

Getting a working piece of software into the hands of your customers every sprint rather than defining everything upfront

 

Mentioned in this Episode:

Agile Coaches’ Corner Ep. 56: “Scrum and Agile Q & A with Christy Erbeck”

The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, by Don McGreal and Ralph Jocham

Relentless Forward Progress: A Guide to Running Ultramarathons, by Bryon Powell

How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas W. Hubbard

Agile Coaches’ Corner Ep. 27: “Deep Dive on Scrum Values with Sam Falco”

Sam Falco’s LinkedIn

 

Sam Falco’s Book Picks:

Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell

Thinking, Fast and Slow, by Daniel Kahneman

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

On today’s podcast, Dan Neumann is joined by his collaborator, Sam Falco! Today they will be comparing a product-focused approach versus a project-focused approach and highlighting some of the major differences. They also cover how to apply a product mindset to a project-focused organization and offer some key tips on how to effectively implement either!

Today on the podcast, Dan Neumann is joined by a return guest, Christy Erbeck! Christy is a Principal Transformation Consultant at AgileThought and Certified Dare to Lead™ Facilitator. She has over 25 years of experience in domestic and international consulting; training and coaching; and working in both software development and non-product-focused environments, including manufacturing (discrete and process), distribution, and sales and marketing.

In this episode, they’ll be taking a look at a couple of different areas on the theme of agile by reviewing some questions from Quora.com! They start off discussing sprint retrospectives and how to make them more creative and fun; later shifting to discussing frameworks and which are appropriate where; and then lastly, they take a look at agile vs. waterfall.

 

Key Takeaways

“How does a Scrum Master make the sprint retrospective more creative and fun?”

Allow room for creativity by creating a safe environment through structure

Slowly introduce new ways to run the retrospective so the team can look at their work and interactions differently

Get to know your team — the better you know them, the better you can adapt the retrospective to fit their needs

Use a method such as the Sailboat Retrospective to get the team outside of their regular 3-question retrospective

Try the ‘Genie Retrospective’ and ‘The Four Ls Retrospective’ (and don’t be afraid to customize them to make them your own, either!)

Read Agile Retrospectives: Making Good Teams Great, by Diana Larsen and Esther Derby for further insights on what makes a great retrospective

Seed the data for the retrospective

Check out TastyCupcakes.org, FunRetrospectives.com, and Retromat.org for further ideas for creative and fun retrospectives

“How do we convince clients to use agile methods?”

Share case studies and stories from your own experience that illustrate the benefits that come from it

Explain the “why”

Meet them where they’re at

You can’t convince them; you need to help them uncover their own reasons for why they would want to adopt it so they can sell themselves on it

Dig into what isn’t working for them right now that agile would solve

Do a lot of listening about what their problems are

“What is the advantage of waterfall over agile?”

There is a time and a place for waterfall, depending on the project

It can be a great approach to solving a problem and getting a product out the door for simple projects that have a clear checklist

Remember: you can still apply an agile mindset to a waterfall project and an organization can use both approaches successfully

 

Mentioned in this Episode:

Christy Erbeck

Quora

Sailboat Retrospective

Genie Retrospective

The Four Ls Retrospective

Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen

TastyCupcakes.org

Retromat

FunRetrospectives.com Stacey Complexity Model

Cynefin Framework

JordanRaynor.com

Relentless Forward Progress: A Guide to Running Ultramarathons, by Bryon Powell

 

Christy Erbeck’s Book Pick:

Master of One: Find and Focus on the Work You Were Created to Do, by Jordan Raynor

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Today on the podcast, Dan Neumann is joined by a return guest, Christy Erbeck! Christy is a Principal Transformation Consultant at AgileThought and Certified Dare to Lead™ Facilitator. She has over 25 years of experience in domestic and international consulting; training and coaching; and working in both software development and non-product-focused environments, including manufacturing (discrete and process), distribution, and sales and marketing

In today’s episode, Dan Neumann is joined by Steven Granese, the Vice President of the Transform Practice at AgileThought! As the VP of Transform Practice, Steven leads a team of the top Agile Coaches, DevOps Consultants, and Product Consultants in the United States.

 

Together, Dan and Steven will be exploring the ‘why’ behind Scrum and examing the question of why organizations and teams should be using Scrum, in the first place. Steven often sees that the clients he’s working with lose focus on the ‘why’ behind Scrum or don’t even know what it is, to begin with! With these clients, there will be a lot of focus on the mechanics of Scrum and the framework itself (i.e. the ‘how’) without a deep understanding of why they’re using Scrum, what problems they’re trying to solve with Scrum, and what their purpose is for working with sprints with iterations. In this episode, Steven addresses how organizations can shift their perspective from a ‘how’ mentality to a ‘why’ mentality as well as many of the misconceptions and incorrect uses of Scrum (so you can be sure to avoid them!)

 

Key Takeaways

Why it is important to focus on the ‘why’ behind Scrum rather than the ‘how’:

The ‘why’ helps the team and organization understand what problem they’re trying to solve with Scrum in the first place

Focusing on the ‘how’ (such as: “How do we execute Scrum?”) leads to organizations applying Scrum incorrectly

Understanding the ‘why’ leads to a deeper understanding of why they’re using Scrum, the problems they’re trying to help solve with it, and what their purpose is in working with sprints and iterations

The ‘why’ behind Scrum and where it makes the most sense to use:

In conditions of high uncertainty

In environments of high uncertainty

Incorrect ways Steven sees Scrum being applied:

As opposed to building a working increment of their product, getting feedback as they go, and adjusting their sprint-to-sprint plan based on the feedback (which is the heart and soul of the ‘why’ behind Scrum), they’re not allowing feedback into the process — therefore losing the ‘why’ in the process

Breaking up work into milestones instead of sprints

Treating the sprint demo like a sales pitch and not letting the customer experience the demo for themselves

Techniques and tips for achieving the ‘why’ behind Scrum:

Recognize that the market moves fast, there’s a lot of uncertainty in the world, and that the customer’s needs are changing very quickly

Match the way you think about your work and deliver your work to that uncertainty (which allows you to move faster)

Stop overplanning and just start working

Put increments of the product into the customers’ hands and start getting their feedback

Get back to the basics and simply focusing on two weeks at a time

Measuring the right metrics (“You get what you measure”)

Don’t just use Scrum to measure the team; use it to measure the flow of the entire system

Focus on getting really quality feedback from your customers

“Begin with the end in mind.” — Stephen Covey

Through receiving high-quality, real feedback from a sprint demo, really listen to the feedback and adjust the plan and fix problems accordingly

Understand where the market is headed (and differentiate between what the customer wants and what is actually needed) by building something and putting it in their hands to get feedback

Fail fast to learn fast

Build in thin slices and get feedback as you go — you will learn a ton about what users actually need and also save time by not building unneeded features

Misconceptions about the Scrum framework:

That Scrum is really about product delivery (“Scrum is just as much about discovering the solution as it is about delivering the solution” — Steven Granese)

Scrum and other Agile frameworks are seen as a delivery mechanism (as opposed to a mechanism to discover what the customer actually needs)

That you have to use Scrum (if you already know exactly what you need to build and there’s no uncertainty then there’s no need for the iterative nature of Scrum)

 

Mentioned in this Episode:

Steven Granese

Stephen Covey

“Wagile” (Waterfall Agile)

 

Steven Granese’s Book Picks:

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, by Gene Kim, Patrick Debois, John Willis, and Jez Humble

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren, Jez Humble, and Gene Kim

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

In today’s episode, Dan Neumann is joined by Steven Granese, the Vice President of the Transform Practice at AgileThought! As the VP of Transform Practice, Steven leads a team of the top Agile Coaches, DevOps Consultants, and Product Consultants in the United States

This week on the podcast, Dan Neumann is joined by Che Ho! Che Ho is leading an agile transformation for the County of Santa Clara, California. He also recently got certified as a Scrum Master Professional through Agile Alliance. And, fun fact: He’s also a martial arts instructor for Wing Chun! He’s been studying it since he was 10 and has been teaching it now for 20-odd years.

 

Speaking of martial arts, the topic today directly relates to it! Shu Ha Ri is a concept that comes from Japanese martial arts’ kata (AKA forms) and is a fantastic tool for Agile coaches in their approach to agile adoption. In this episode, Dan and Che Ho are completely breaking down the concept of Shu Ha Ri to make it just a little more tangible.

 

Key Takeaways

What is Shu Ha Ri?

• ‘Shu Ha Ri’ is not levels, nor is it a self-contained stage that you go through
• The description of Shu Ha Ri comes from Japanese martial arts’ kata (AKA forms)
• Shu Ha Ri is similar to a pyramid; each phase supports one another and one cannot exist without the other
• It’s simply a way to look at a maturity level which can help with agile adoption

Breaking down Shu Ha Ri:

The ‘Shu’ phase:

• Shu is when you first start learning (it’s essentially like learning the alphabet and how to put things together)
• Where you learn the ‘why’
• The time for getting comfortable with the rhythm of things

The ‘Ha’ phase:

• Ha is about playing with the techniques and stringing them together in your own unique way
• You can begin to personalize within the framework
• You can move off script as the framework is internalized
• Motivation comes to light at this phase

The ‘Ri’ phase:

• Ri is the ‘ultimate mastery’ — it’s described as the phase where the form no longer matters (it’s a ‘formless form’)
• It’s more of a lifestyle — it becomes so ingrained in you that it just becomes the way that you are rather than something that you do
• The activity becomes organic
• Through this, you create ways that are uniquely yours and you can become playful with it
• A lot of experimentation can signify a ‘Ri’ level of maturity
• Ri is when you become so comfortable with what’s going on that it just becomes you; and you’re free to innovate, create, and experiment

How to address resistance to Shu Ha Ri:

• Firstly, don’t take it personally — as Che Ho says, “They’ve honed their habits over decades to get to the success where they’re at now — so of course they’re going to resist changing it!”
• Address the ‘why’ for the change
• Remember: it takes time
• You can only get so far studying by yourself but a coach helps you get great
• A study group can be a form of coaching if they are focused and have their intention set for growth and change

Che Ho’s key takeaways:

• Shu Ha Ri is a way to bring people to the same understanding
• Be sure to have patience with the change
• Celebrate the small wins along the way
• Instead of trying to achieve something, Shu Ha Ri should become an internalization and part of your being

 

Mentioned in this Episode:

Che Ho's LinkedIn Profile

Agile 2019 Conference

Wing Chun

Shu Ha Ri

Bruce Lee

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins

Alistair Cockburn

Kata

Woody Zuill

Agile Coaches’ Corner Ep. 45: “The Benefits of Mob Programming with Chris Lucian”

The Agile Manifesto

County of Santa Clara

Nonviolent Communication (Approach by Marshall Rosenberg)

 

Che Ho’s Book Picks:

Say What You Mean: A Mindful Approach to Nonviolent Communication, by Oren Jay Sofer

Resilient: How to Grow an Unshakable Core of Calm, Strength, and Happiness, by Rick Hanson Ph.D. and Forrest Hanson

Pocket Guide to Interpersonal Neurobiology: An Integrative Handbook of the Mind, by Dr. Daniel J. Siegel M.D.

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

This week on the podcast, Dan Neumann is joined by Che Ho! Che Ho is leading an agile transformation for the County of Santa Clara, California. He also recently got certified as a Scrum Master Professional through Agile Alliance. And, fun fact: He’s also a martial arts instructor for Wing Chun! He’s been studying it since he was 10 and has been teaching it now for 20-odd years

Recently, Dan received an email from a listener that posed an interesting question. In short, they said, “We’re doing alright every sprint and the business is doing alright too — we’re not really facing any competition. So, when the team asks, ‘Why should we continually improve?’ how can I help them through that scenario?” This is a great question! Though this team is stable, have been working together for a long time, and are doing well — they’ve reached a plateau.

 

When you dominate your market and you feel there is no competition there can end up being a serious lack of continuous improvement (especially if the barrier to entry is really high!) And it’s not totally unexpected that teams sometimes can get a little bit complacent — but it’s the Scrum Master’s job to challenge that. So, in today’s episode, Dan, and his collaborator, Sam Falco, will be answering this question and addressing how you, as the Scrum Master, can help remotivate your team to amplify what’s going well, shake things up, and make sure they’re all doing more of what they love!

 

Key Takeaways

Why should you continually improve?

In the case of competition (people may find an alternative to your company!)

Because there is always something you can look to improve (even if things are going well you can always amplify that)

How can you get your team to be interested in continuous improvement? What’s important to note as a Scrum Master or team leader?

Watch out for change fatigue (sometimes it’s good to simply celebrate stability)

Ask: “What could we try differently?” even if everything is going well (amplify what’s already going well!)

Hold timeline retrospectives (i.e. with the team, plot the events that happened over a period of time and list them from most positive to least to see what people are feeling good or negative about)

By looking back further than a sprint, you can do an exercise called a journey map for the last quarter (or as far back as a year) to look for trends

Find the things that are going to be good for your team (i.e. a compelling interest beyond just the financials of the company)

If some members of the team are bored with the work they’re doing, assign a new project or have them learn a new area of the business

Work with the Product Owner on the question of: “What could we do to delight customers? What are they asking for?” using the Kano model

Work with the Product Owner and coach them on the product road map/how to understand customer needs and creating more inspired product backlog items to fuel the motivation for continual improvement

Look for ways to tap into your team’s intrinsic motivation (if you have a long-standing team it may be important to find out what motivates each individual member of the team [which could be autonomy, mastery, or purpose, according to Daniel H. Pink])

Remember that you are looking for the intrinsic motivators rather than the extrinsic motivators (which are things like time off or financial rewards)

Try flipping the script; do your retrospective around: ‘What would destroy as us a team,’ ‘How can we mess up,’ and ‘What would make the next sprint a complete disaster?’

Identify somewhere that the team can go and lead the way by holding the vision and finding areas of improvement (i.e. lead more than serve)

Be sure to keep in mind that change and improvement can take a long time

Find a representative within the team of developers who is interested in continuous improvement to facilitate change, model the behavior, and lead through attraction

 

Mentioned in this Episode:

Kano Model

Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink

Moving Motivators Cards

Agile Coaches’ Corner Ep. 43: “The Importance of the Product Owner Role in Scrum with Sam Falco”

Agile 2019 Conference

Agile + DevOps East Conference

“The Experience Trap” – Harvard Business Review

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!