Agile Coaches' Corner Dan Neumann at AgileThought

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to share their continuous learning journey. They have been exploring the book Project Retrospectives written by Norman Kerth, and today, you will listen to them discussing chapters 3 to 5, where they dive deep into the role of Retrospective facilitators.  They compare Norm’s guidance against their own experience and reflect how practices presented are still be relevant today as retrospectives are more widely practiced in the industry.
 
Key Takeaways
Retrospectives: Internal or external facilitators?
You can be present without necessarily having to share your opinions and thoughts. 
An external facilitator for a Retrospective is not part of the Team but can be a well-informed outsider.
In the Scrum framework, very often it is the Scrum Master who facilitates the Retrospectives, but it does not have to be this way.
There is a conflict between a full contributor on the retrospectives and a facilitator, which is why an external facilitator can be significantly valuable.
Should Managers be in a Project Retrospective?
Managers must be allowed to be present at Retrospectives, but their involvement needs to be regulated.
Engineering retrospectives take time and effort.
Sometimes, the same feedback is received during several meetings, which is why it is important to plan retrospectives carefully considering Team Styles, the way the questions are brought forward, and any characteristics that can come up after thoughtfully observing the Team’s dynamics.
Identifying the most important topic for the Retrospective must be brought forward by the Team. The best achievement is when the Team expresses its needs as a result of the effective work of a facilitator (as opposed to someone dictating what the Team’s interest or need is).
 
Mentioned in this Episode:
Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth
 
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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
 

This week, Justin Thatil, your host, welcomes Mike Guiler and Anitra Pavka. Today, they address the product discovery phase and some of the challenges the engineering Team usually faces while identifying what they will build and which special skills will be required to perform the task effectively. Also in this episode, they explore interviewing techniques and usability testing.
 
Key Takeaways
Interviewing users is universally helpful.
Interviewing users is so important that it should be done every week.
We need to be informed, and the only way to do this is by talking to the users.
Before the interview begins, you need to make sure you know what you want to obtain from the conversation. A discussion guide might help to lead an interview and make it more consistent.
Focus on allowing people to keep on talking.
Engage in the conversation with active listening skills 
Open-ended questions are ideal for promoting a deep conversation.
Fall in love with solving the problem and avoid fixating on a particular solution.
Put an effort into understanding the underlying motivations to solve a particular problem.
The organizational culture needs to promote the Discovery and Delivery Teams to talk to the customer and get feedback.
Encourage small experiments that try to address a problem from a different perspective and use a different tool to solve it. If the experiment is successful, the new approach could be applied to other matters.
Usability testing:
Was the product easy to learn? Was the user able to get through the product efficiently? Were there errors along the way?
Search to find out answers to questions about value.
You can use moderated and unmoderated usability tests to get the feedback the Team seeks.
Share the findings across the Team. They can influence how they approach the following prototype and evolve the solution.
 
Mentioned in this Episode:
 
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 Podcast@AgileThought.com or on X (Formerly Twitter) @AgileThought using #AgileThoughtPodcast!
 

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to discuss the journey of a Project Manager shifting to fill the Scrum Master accountability. This episode mainly focuses on those Scrum Masters who are newer to this accountability and have a Project Management background. In this episode, they explore what happens when a Project Manager is assigned Scrum Master’s accountabilities which can develop differently depending on the person’s expertise and ability to learn and embrace Agile principles.
 
Listen to this episode to learn about the main aspects of a successful transformation.
 
Key Takeaways
It is common for the Project Manager (PM) to assume the role of the Scrum Master.
Scrum Masters who come from Product Management can incorporate their expertise in the process of shifting to Agility.
Product Managers often know a lot about the business domain.
PMs often have good relationships with the Team, which are crucial to initiating a transformation towards Agile.
You can’t easily hire for the business domain knowledge or the relationships.
It is often easier to have current staff learn a new way of delivering value.
A plan must be set in order to manage expectations between the development Team and stakeholders.
Many non-Agile do not know who the stakeholders are
Effective Scrum Masters will connect the team to the Stakeholders
The Scrum Master must ensure that the entire Scrum Team is engaged with its stakeholders, showing the development of software and articulating the plan. 
The Scrum Master does not need to take ownership of the relationship with its stakeholders but should empower the Team
How do we create more and better channels of communication with stakeholders?
Project Managers often see success as being on time and on budget.
As a Scrum Master, being on time and on budget is not enough; the most important thing is delivering the business outcome.
Status reporting is another area where PMs must work in transitioning to Scrum Masters.
When an Agile Team operates well, progress should be transparent.
Even status reports could become less valuable if the entire Team works together and is aligned, working with Sprint Reviews and information radiators.
 
Mentioned in this Episode:
Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group), by Marty Cagan
Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth
 
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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
 

This week, Dan Neumann and Justin Thatil are joined by their colleague, Mike Guiler. In this episode, they explore how a Product Manager shifts from just management to leadership and how this transformation influences the role. Dan, Justin, and Mike discuss tools and strategies, including OKRs, Story Mapping, and Hackathons, among others.
 
Key Takeaways
Product management must study the market and users, becoming customer-centric and ensuring it is still viable for the business at the same time.
It takes more than one individual to effectively perform the discovery function. It's a Team effort (Product Designer, Product Owner, and a Technical member).
Discovery and design sessions are opportunities for Teams to unlock the art of the possible.
The Team has to learn from rapid feedback while ensuring steps are taken to not hurt organizational reputation.
A Product Manager must first understand how to help the Team approach a particular problem. A great way is to identify OKRs (Objectives and Key Results) and focus on the target market the Team is going after. Once the Team is aligned, the job can be done.
A Product Manager sets an objective for the Team and allows them to work autonomously toward reaching it.
Story Mapping: A Product Manager’s ally on the journey to product discovery.
Story Mapping is an easy way to frame what the Team is trying to achieve and the tool that might be the most efficient for that purpose.
Story Mapping can also help identify the target persona for which the Team is building a particular feature.
There is tremendous value in having the Team involved in Story Mapping and, as a result, immersed in and knowledgeable about the problem at hand.
Hackathons are a great way to keep a Team motivated.
Allow the engineers to explore; you will keep them engaged and motivated.
 
Mentioned in this Episode:
Fall in Love with the Problem, Not the Solution: A Handbook for Entrepreneurs, by Uri Levine
Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group), by Marty Cagan
 
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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
 

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to continue the conversation that started in the last episode, where it was discussed how organizations can support their Managers. This time, they explore how Managers can help their Teams to shift to a more Agile approach.
 
In today’s episode, Mike, Justin, and Dan dive deep into the reasons managers must be prepared to accompany their people in changing to Agile, sharing information, and asking the right questions to ensure the Team’s involvement.
 
Key Takeaways
When an Organization is shifting it is crucial to know what was the Perceived Value Proposition made by the Manager.
A Manager as a Leader wants his Team to be informed and involved in the upcoming changes.
A Manager must trust and value his Team’s opinions.
A Manager must be willing to share information as well as show curiosity about his Team’s points of view about the Organization and its objectives.
A Manager needs to support and empower Teams.
In the Agile Method, words matter. There is significance in the different frameworks and mindset that come with Agile.
A Manager needs to invest in creating amazing relationships with both the business and the technology sides of the organization.
A Manager fosters communication and connectivity among all levels of the organization.
Clarifying the roles, responsibilities, and what it means to be successful is a crucial part of a Manager’s obligations.
“Leadership is communicating people their worth and potential so clearly that they are inspired to see it in themselves.” — Captain David Marquet
A leader helps their Team to upscale, so they are not stuck with the tools they already have to rapidly create value, which needs new tools, mindset, and engineering approaches.
 
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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
 

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to explore how organizations can better support their managers. In this episode, they discuss two adoption patterns, the grassroots and the top-down approach, and the distinction between being a Manager and a Leader.
 
Key Takeaways
The grassroots adoption pattern and the top-down approach in an Agile Organization:
Grassroots starts at a Team level.
The top-down approach begins with the boss.
If an Agile Team is self-managing: What does a Manager do?
A Manager must decide whether he wants to be just a Manager or a Leader because these are different roles. Leaders set clear objectives; they are not so focused on the daily chores but on the higher business-valued conversations. A Leader cares about how to build the environment.
A Manager needs to work his way to becoming a Leader and less about assigning tasks to Team members. A leader’s work should come from a mentorship place, sharing his knowledge and experience for the Team to explore (instead of being told what to do).
An Organization can support a Manager embracing Leadership and becoming a servant leader.
A Leader evaluates options and consults them with the Team; a leader does not impose practices. Communication is more valuable than processes and tools.
The organization must have a plan in mind but check first how the Team responds.
A Leader’s job is to establish the vision, shifting away from the “how.”
While the Team is busy executing the hypothesis, the Leader is thinking about the next step.
The Alignment of OKRs is vital for an Organization.
Ensuring that OKRs match the plans for the product and what the business wants to achieve is fundamental for companies. This way, everyone knows what’s most important.
How role descriptions are set up (performance reviews, salary adjustments) can influence the leader’s job.
 
Mentioned in this Episode:
Who Moved My Cheese?, by Spencer Johnson
What Got You Here Won’t Get You There, by Marshall Goldsmith and Mark Reiter
Team of Teams, by General Stanley McChrystal
 
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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!