Agile Coaches' Corner

This week on the podcast, Dan Neumann is joined by his collaborator, Sam Falco! Together they’re going to be tackling three Scrum-related questions that they dug up on Quora

Joining Dan Naumann today is AgileThought colleague and return guest, Sam Falco! Sam is an Agile Coach and Certified Scrum Professional with an extensive background leading Agile development teams.

 

Today they’re discussing under-promising and over-delivering: the what-not-to-dos for Scrum teams, their leaders, and the business they work for. Every now and then when Sam is teaching Scrum or coaching people on sprint planning he’ll say, “Select what you think you can do.” However, a lot of beginning Scrum teams will bite off more than they can chew because they’re way too optimistic. He often cautions to dial it back and then will hear the phrase in return, “Oh, we get it! Under-promise and over-deliver.” But that is as much of a lie as, “Sure, we can get that done,” and then not delivering. Businesses pick up on this dishonesty and it creates a tumultuous relationship between the development team, the leadership, and the business.

 

Tune in to get Sam’s key insights on how to build trust between the team and the business, the to-dos and not-to-dos for scrum teams and leadership, his cautions for new scrum teams and leaders, and his advice and actionable steps for building a healthy relationship between the team, the leader, and the business!

 

Key Takeaways

“Under-promising and over-delivering” and other unhealthy Scrum team mentalities perpetrated through the team or through the leadership:

• When the business fears that the team is under-committing or sandbagging the estimates they’ll create stretch goals for the team (which are often unhelpful)
• Theory X: The belief that people will not perform unless you force them to do so; that workers are lazy so you have to put systems in place to keep them working
• If the leader is making crazy demands, the team is going to end up overcommitting or sandbagging

What healthy Scrum teams and leadership looks like:

• Theory Y: Assembling together the people who want to help you accomplish your goals, give them the barometers, and then letting them do it
• They have an established sprint goal
• There is collaboration between the development team and the product owner
• The product owner and development team are collaborating to come up with product backlog items that are aligned with the sprint goal
• The leader or business does not drive the team as hard as they can to get as much as they can (which can lead to sandbagging)

Sam’s cautions to new Scrum teams and leaders:

• New Scrum teams need time to learn what they can do
• New Scrum teams tend to overcommit and add way more than they actually can do
• Dial it back a notch as a team — you can always add something later if you find you go through something too fast

Sam’s principles for successful teams:

• Technical excellence enhances agility (if you are always providing a done increment, you are always in a position to release and always in a position to pivot or change direction)
• A professional Scrum team that really observes Agile principles and values will be the most successful at knowing exactly what they can accomplish and being able to deliver on it

Actionable steps for building a healthy relationship between the team, the leader, and the business:

• Realistically forecast what you know you can deliver
• If you are on a development team and you’re using Scrum, give honest estimates and have the courage to say, ‘No, we will not commit to doing more than we can do.”
• Follow the three pillars of Scrum: transparency, inspection, and adaptation
• Establish a sprint goal that is meaningful between the business and the technology team
• Do enough planning during the sprint planning to build a credible forecast
• The business should be asking for the ‘what’ that they want, and as the technology team, give them some alternatives as to ‘how,’ then collaborate together to figure out the best option
• Have a well-established definition of ‘done’ that everybody understands, agrees to, and adheres to
• Never sacrifice your quality goals
• Use the ‘fist to five’ to vote on how confident the team feels on accomplishing a set goal
• As you go through the sprint, be honest with where you’re at
• In sprint review, discuss how problems were solved as well as the difficulties that were encountered (because stakeholders need to know that this is not magic)
• If you did not deliver, that should be the subject of your sprint retrospective

 

Mentioned in this Episode:

The Agile Manifesto

Three Pillars of Scrum

Fist to Five

 

Sam Falco’s Book Pick:

Bad Blood: Secrets and Lies in a Silicon Valley Startup, by John Carreyrou

 

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 Dan and Sam are discussing under-promising and over-delivering: the what-not-to-dos for Scrum teams, their leaders, and the business they work for. Tune in to get Sam’s key insights on how to build trust between the team and the business, the to-dos and not-to-dos for scrum teams and leadership, his cautions for new scrum teams and leaders, and his advice and actionable steps for building a healthy relationship between the team, the leader, and the business!

For this week’s episode, your host Dan Neumann is shaking things up! He’ll be answering some of the frequently asked questions that often come up in his work as well as some miscellaneous questions on Quora on the themes of Agile and Scrum.

 

In his coaching, Dan often finds that there are a lot of misconceptions, questions, or themes that continuously come up. Throughout this podcast, he’s hoping that the selected questions today will add some value to your own practice! Some of the questions include: “What resources would be good reading for an Agile Scrum Master,” “What is a road map in Agile,” “In practice, does waterfall planning ever accurately predict (or guarantee) completion dates for tasks and projects,” and more!

 

If you have any questions you’d like to ask for yourself, you can email them to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

 

Key Takeaways

What resources would be good reading for an Agile Scrum Master?

Agile Project Management with Scrum, by Ken Schwaber (Very approachable for those even brand new Agile and Scrum)

Anything by Mike Cohn, including his blog on Mountain Goat Software

Essential Scrum: A Practical Guide to the Most Popular Agile Process, by Kenneth S. Rubin

Listen to this podcast, of course! You can tweet or email in your own questions to have them answered in a future episode

Always be sure to ask others in-person what they suggest and also to just simply pick up books and resources in whatever current challenges you may be facing

For team dysfunction, check out the book: The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni, as well as his follow-up book: Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators

If you’re interested in building your skills as a coach, read: Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins

One of the opportunities for Scrum Masters to really help their teams is in facilitating effective retrospectives — in Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen, they lay out a five-step framework for an effective retrospective *Dan considers this a must-read!

Dan’s final tip: always keep learning

Can a product owner change a sprint backlog any day?

The product owner’s role is to optimize the product backlog for value

Hopefully, the product owner is participating during the sprint, but really the sprint backlog is the domain of the development team, and one would not expect to see them changing the sprint backlog day-in and day-out

The product owner’s role is in the product backlog and to accept items as they are being delivered in the sprint, to clarify questions, and to make sure that sprint goal is achieved

The sprint backlog will usually change throughout the sprint but it would be done in collaboration with the scrum team always keeping the sprint goal in mind

What is a road map in Agile?

A road map is simply a plan on how to get from one point to another

Part of the mindset and approach to Agile road maps is really realizing that we’re not able to predict the future to a high degree of certainty or very specifically and that we need to be able to respond to change

In practice, does waterfall planning ever accurately predict (or guarantee) completion dates for tasks and projects?

Does it ever? Yes, there are times when waterfall or highly predictive planning can accurately predict completion dates for tasks and projects

The scenarios or conditions under which it happens tend to be those that have a high degree of certainty about the capabilities that are needed

If you have a team that’s done a particular type of development before with technology that they’re using again and really well-understood requirements, waterfall planning can accurately predict dates for tasks and projects

The less certainty there is, that’s where waterfall planning breaks down

 

Mentioned in this Episode:

Quora

Agile Project Management with Scrum, by Ken Schwaber

Mike Cohn’s Amazon Book Page

Mike Cohn’s Blog on Mountain Goat Software

Essential Scrum: A Practical Guide to the Most Popular Agile Process, by Kenneth S. Rubin

The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni

Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators, by Patrick Lencioni

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

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

Agile Coaches’ Corner Episode: “Creating Effective Retrospectives with Sam Falco”

The Agile Manifesto

Quora Questions:

“What resources would be a good reading for an Agile Scrum Master?” Asked by Alex Shaw

“Can a product owner change a sprint backlog any day?” Asked by Mohammed Saiful Alam Siddiquee

“What is a road map in Agile?” Asked by Maxime Sauvaget

“In practice, does waterfall planning ever accurately predict (or guarantee) completion dates for tasks and projects?” Asked by Alan Pita

 

Dan Neumann’s Book Picks:

Essential Kanban Condensed, by David J. Anderson and Andy Carmichael

Making Work Visible: Exposing Time Theft to Optimize Work & Flow, by Dominica DeGrandis

 

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!

For this week’s episode, your host Dan Neumann is shaking things up! He’ll be answering some of the frequently asked questions that often come up in his work as well as some miscellaneous questions on Quora on the themes of Agile and Scrum

Today’s guest is Chris Lucian, the Director of Software Development at Hunter Industries and co-founder of the mob programming movement! Chris is passionate about the advancement of software craftsmanship and machine learning. He seeks the continuous improvement of himself, his family, his company, and his community. He believes that we can explore the unexplored potential in all things when looking at our processes with automation and creativity in mind.

 

In this week’s episode, Chris joins Dan to discuss mob programming. He shares the origin story behind mob programming, what it is and how it is utilized and dispells some of the general misconceptions around it. Chris also highlights many of the key benefits of mob programming and explains some of the best practices!

 

Key Takeaways

Key takeaways from the origin story behind mob programming:

After getting hired into an organization he was shocked by how everybody was working separately in cubicles and soon developed mob programming

After implementing mob programming, their quality went through the roof and their cycle time went from a year and a half to twice a day and they stopped getting bug reports from production

What is mob programming?

A software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer

This approach relies on face-to-face and side-by-side communication, team alignment, collaboration, and whole team involvement

What are coding katas?

The intentional practice of your coding craft

Practicing together by writing code through games such as the Tic Tac Toe Game and the Bowling Game (linked below)

Helps to build a habit or reflex out of coding

Misconceptions around mob programming:

When multiple people are working on a single piece workflow it will cost more for the company

It is a waste of time to implement for the ‘simple stuff’

The benefits of mob programming:

Paired programming helps mitigate risk from siloing and provides an increase in quality

High-bandwidth learning

The code moves all the time

Really optimized for flow efficiency with less time being spent on waste activities like bug fixes

Removing impediments becomes really fast

A higher consciousness of experiments on the team to run about how to make things better and faster

Mobbing on the simple stuff incentivizes programmers to make all that simple stuff go away permanently

Physical cost-wise, four cubicles costs more than a single mobbing station with a high-end computer and two 80” screens

Standup meetings become eliminated because the team is already aligned

Group consciousness is constantly being developed

Psychological safety and feedback becomes necessary through mob programming (which are critical components to a successful team)

The codebase keeps moving forward and nothing gets in its way

Mob programming best practices:

Dedicated learning time

Do frequent retrospectives

Don’t just ‘try’ something; frame it as an experiment (regardless of the outcome, it provides invaluable learning)

 

Mentioned in this Episode:

Chris Lucian

Hunter Industries

Mob Programming

Agile Manifesto

Woody Zuill

Agile Coaches’ Corner Ep. 28: “Misconceptions and Interpretations of ‘The Agile Manifesto’ with Arie van Bennekum”

Mob Mentality Show (Youtube Channel)

Tic-Tac-Toe Kata Game

Bowling Game Kata

Twitter @ChristophLucian

Google Study on the Top 5 Traits of Successful Teams

Conway’s Law

Companies that are Mob Programming

Mob Programming RPG by Willem Larson

Trello Board — Software Profession Resources

Harvesting Mob Programming Patterns (A publication taking a look at the mob programming patterns discovered by IBM and LendingHome)

Scrum Gathering Tokyo 2019: “Learning to Experiment” (Chris’ Keynote) 

Agile Coaches’ Corner Ep. 5: “Exploring an Experimental Mindset with Adam Ulery”

Linda Rising

 

Chris Lucian’s Book Pick:

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!

In this week’s episode, Chris joins Dan to discuss mob programming. He shares the origin story behind mob programming, what it is and how it is utilized and dispells some of the general misconceptions around it. Chris also highlights many of the key benefits of mob programming and explains some of the best practices!

Today’s guest is Jenny Tarwater! Jenny is a Collaboration Coach and owner of Blueshift Innovation, as well as the co-organizer of the Lean Agile KC Conference and Agile Game Night. On top of that, she is also the International Program Director for Launching New Voices for Women in Agile.

The focus of today’s podcast is going to be all about the new Women in Agile initiative, Launching New Voices. As an expert on the topic, Jenny explains what the initiative is all about, how it is making a difference in the space, and how they are helping new voices step up and share their stories and experiences. She also highlights many success stories and the kinds of outcomes they have seen from the program and how you can get involved for yourself!

 

Don’t miss this week’s episode to learn about how Launching New Voices is empowering new speakers and providing powerful experiences for them to grow and succeed!

 

Key Takeaways

 What is ‘Launching New Voices’ initiative?

They are shedding light on new voices who are showcasing new ideas

They are lowering the barrier for entry for those who have a message or a story  to tell through providing a better onramp to that stage

It is an effort to break outside the traditional networks

A chance to step out of the safety of your network and into new communities

A program that gives service to the new voices that are being launched and provides new experiences for them

A way to increase diversity and inclusion

How Jenny is helping these new voices become more comfortable through Launching New Voices and Women in Agile:

Through providing classes and training on public speaking for those new to speaking

By providing opportunities and experiences for new speakers (specifically, giving them an opportunity to speak at the Women in Agile 2019 Conference and through pairing them with an experienced mentor)

Success stories and outcomes from bringing new voices forward:

Reignites the passion of the mentors and new voices alike

The proteges become very recognizable

Gives new voices incredible opportunities for networking as well as new speaking opportunities

Provides multiple pathways to continue to foster these new voices after they speak at the conference

Where to learn more or become a ‘new voice’ yourself:

If you’re a protege or mentor, you can sign up on WomeninAgile.org to learn more

For conference organizers, consider a Launching New Voices program at your conference

Email [email protected] or contact Jenny personally through her LinkedIn or Twitter

Other ways to get involved if you don’t have a Launching New Voices program near you:

Join or create a meetup — they’re a great way to present new ideas and experiences to a smaller group

 

Mentioned in this Episode:

Blueshift Innovation

Lean Agile KC Conference

Women in Agile

Women in Agile’s New Initiative: Launching New Voices

The Agile Alliance’s Women in Agile Initiative

Women in Agile 2019 Conference

[email protected]

Jenny Tarwater’s LinkedIn

Jenny Tarwater’s Twitter @JennyKCMO

Agile Coaches’ Corner Ep. 11: “#WomenWhoCode — Betty’s Tips for Breaking into a Male-Dominated Industry”

 

Jenny Tarwater’s Book Pick:

7 Rules for Positive, Productive Change: Micro Shifts, Macro Results, by Esther Derby

 

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’s guest is Jenny Tarwater! Jenny is a Collaboration Coach and owner of Blueshift Innovation, as well as the co-organizer of the Lean Agile KC Conference and Agile Game Night. On top of that, she is also the International Program Director for Launching New Voices for Women in Agile

This week, on the Agile Coaches’ Corner, your host Dan Neumann and his AgileThought colleague, Sam Falco, will be taking a look at the Product Owner role in Scrum! The Product Owner Role sometimes gets overlooked in a lot of discussions around Scrum — yet, they’re one of the most important, complex, and crucial roles. They’re the visionary behind the product. Primarily, their responsibility to the Scrum team is to maximize the value of what the development team creates.

 

Tune in to hear Dan and Sam’s conversation to get more insight into the incredibly important Product Owner role — what it is, the challenges of being one, the valuable traits and skills for a PO to have, and some of the anti-patterns around the role!

 

Key Takeaways

What is the Product Owner Role in Scrum?

• It is one of the three roles of Scrum (product owner, scrum master, and the development team)
• They’re the visionary behind the product
• They’re a crucial reason to why we have Scrum teams in the first place — they’re feeding the Scrum team the most valuable backlog items to turn into an increment of product every sprint
• The primary role of the Product Owner is to maximize the value of what the development team creates
• It’s important that it’s only one person; not a committee

Challenges of the Product Owner Role:

• Managing and representing the opinions and voices of the dev team and stakeholders by distilling them into a coherent product backlog that’s optimized for value

Valuable traits for a Product Owner:

• Someone with a distinct understanding of the market and a vision for a product that they want to bring into the world
• An entrepreneurial mindset
• Someone with very deep domain knowledge and business knowledge
• Understands the customers (or potential customers)
• Decisiveness
• Open-mindedness
• Strong leadership skills and the ability to motivate others

Important skills for a Product Owner to have:

• Domain and business knowledge
• The ability to write a good business proposal as well as a strong canvas that articulates to funders what it is you’re trying to accomplish
• A willingness to test your hypothesis and do market research
• Communication skills and articulating things in a way that makes sense to your development team
• Negotiation skills
• Having a well-crafted and well-ordered backlog
• Being able to define the sprint goal
• Being able to communicate the vision and having the organizational skills to put the backlog in a good order so the dev team, customers, and stakeholders always know what’s next
• Technical skills (though it is not a must-have, it is helpful for them to have an understanding of the technology they’re working with) — but be careful, a PO with technical chops can sometimes interfere with the dev team

Anti-patterns within organizations that are not setting up their Product Owner for success:

• Having someone without the right traits and skills in the Product Owner role
• Having a proxy PO stand-in for the real Product Owner, which jumbles the message and leads to “answer shopping”
• Having the role split into two people (where one becomes the ‘business’ PO owner and the other person becomes the ‘technical’ PO), which affects team self-organization and leads to uncertainty

Product Owner anti-patterns:

• Rigidity
• Disregarding estimates
• Product Owner is an ‘order-taker’; simply taking notes and doing everything that is said (which causes issues because they cannot articulate a clear vision)
• When a Product Owner is not valuing everyone’s opinions equally (and instead, giving more value to those who are loudest or had the last say)
• Presenting a release plan to stakeholders that is wildly at odds with what the dev team can accomplish and expecting the dev team to live up to that
• Unbalanced focus and either being too involved with the dev team or not enough
• Spending too much time with the stakeholders
• Only showing up for sprint reviews

 

Mentioned in this Episode:

Scrivener

User Stories

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

Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts, by Annie Duke

 

Sam Falco’s Book Pick:

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, by Alexander Osterwalder and Yves Pigneur

 

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!