Agile Coaches' Corner

This week, Dan Neumann and Justin Thatil are joined by Rich Hundhausen for the second part of a deep conversation about Nexus. Rich is a software developer, Professional Scrum Trainer, and co-creator of the Nexus Framework for scaling Scrum.

In this episode, they dive deep into how to deliver value in the form of a working integrated increment of product, the role of the Integration Team, and the characteristics of each Nexus Event. They share valuable stories exemplifying how Nexus works for an improved scaling experience.

Key Takeaways

• Scale Scrum is still Scrum (plus additional features).

• The Nexus Integration Team is not in the original Scrum framework.

• The Integration Team is actually the Nexus’s Scrum Master. This team is responsible for ensuring that Scrum is followed as established in the Scrum Guide and that its work is effective.

• The Integration Team works in a Scrum way by coaching, facilitating, teaching, and mentoring, but not hands-on (unless absolutely necessary). The Scrum Team’s Developers do the work.

• The Integration Team does not do the integration, but it is accountable for it.

• Integration can mean lots of different things.

• Integration means solving any kind of dependency.

• The Nexus Integration Team does not have to meet daily but only when required.

• Everyone on the Integration Nexus Team has a daily job on the Scrum Teams and/or is the Product Owner, so when something does not go as planned, they bring it to the attention of the Integration Team when possible.

• The Nexus Events:

• First Event: Nexus Sprint Planning. This event aims to take another look at the upcoming work to ensure the organization of Teams and consider any last-minute changes. Big Room Planning takes place during this stage. All the planning at this moment is only for the current sprint (never beyond that). The output for the Nexus Sprint Planning is the Nexus Sprint Backlog for each Team, and the goal is to make any dependencies transparent to mitigate them daily.

• Scrum of Scrums: Scrum Team members are allowed to talk at any given moment.

• Second Event: The Nexus Daily Scrum. It is a Scrum of Scrums that occurs before the Daily Scrum. At this mandatory event, dependencies and integration issues are discussed.

• Third Event: The Nexus Sprint Review is where Stakeholders give feedback on the done increment but in a big room event. This event is the time to share feedback on potential cross-team work.

• The Last Event: The Nexus Sprint Retrospective. This event is an opportunity for the Scrum Team to inspect and adapt how they work, first through a pre-meeting with the representatives, then Teams have their individual retrospectives, and after, representatives meet again to make transparent any new experiments or improvements so the bottom-up intelligence can then be shared with the other Teams.

• There are around 60 complementary practices to Nexus (but none are new).

Mentioned in this Episode:

The Nexus Guide

Listen to “Continuous Learning: Professional Scrum Facilitation Skills Training with Patricia Kong” and “The Nexus Framework for Scaling Scrum with the Scrum.org Team”

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, your hosts, Dan Neumann, and Justin Thatil, welcome an external guest, Rich Hundhausen, software developer, Professional Scrum Trainer, and co-creator of the Nexus Framewokr for scaling Scrum. This episode is the first of two parts, in which they discuss the features of Nexus and when and how to implement it.

Listen to this episode for a description of Nexus, how it started, and why it was developed. Rich, Dan, and Justin also dive deep into the definition of scaling, what is considered done, and the Nexus goal. Stay tuned for part two!

Key Takeaways

• Why do we have a Nexus Scaling Framework?

• Rich started working with Ken Schwaber, co-creator of Scrum, in 2009. Together, they created Scrum.org, “The home of professionals.” They later became interested in Scaling according to the Scale Agile framework.

• Are you really in a situation where you need to scale?

• Rule number one when scaling is “Don’t.” Let your Team tackle the problems first. Always start small and add as needed.

• What is Scaling?

• Scaling is simply one product owner and backlog and multiple Scrum Teams. Everything you learned about Scrum for a single Team still applies at Scale with the Nexus. Additional features, such as the exoskeleton, are required for scaling.

• The number one reason to build Nexus was for dependencies on different areas (not only technical). Refinement has been a proof practice at single-team Scrum, and at Nexus, it has become a required event called Cross Team Refinement.

• What is the definition of Done?

• Everyone at Nexus is a creative person, and these people are motivated when they have space to implement their creativity. All Teams should have autonomy, purpose, and the ability to master their actions. Each Scrum Team can have its definition of done, but it has to stay on top of the unified set of items that the other teams share.

• The Nexus Goal: Do everything you committed to in the product backlogs.

Mentioned in this Episode:

“Shu, Ha, Ri” Episode of The Agile Coaches Corner.

Dan Pink’s books and TedTalks

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, Dan Neumann and Justin Thatil are joined by Erik Lindgren to discuss scope creep, a term that everyone working in software development knows well. The expression refers to adding further features or functions of a new product, requirements, or work that is not authorized.

In this episode, they dive deep into the challenge of managing timelines and budgets and how frequently a Team can find itself off-track, which is undoubtedly an uncomfortable position. Erik, Dan, and Justin discuss the importance of prioritizing properly, including possible improvements and requirements. Scope creep can be a learning opportunity waiting to be embraced by the Team!

Key Takeaways

• Scope Creep in an Agile environment:

• In an Agile setting, new ideas must be added to the backlog for them to be prioritized. Once in the backlog, it is necessary to decide whether it is a high priority or not.

• The stakeholder and client must know about the additional items so they can contribute to the Team in deciding what needs to be included and what can stay out. The involvement of the stakeholders can often be challenging for Agile Teams.

• What is the most valuable idea to be implemented now? The fact that some ideas are not prioritized at a particular moment does not mean they won’t ever happen; they can take place at a different time.

• Keeping open communication with stakeholders can sometimes be a challenge.

• Often, Teams don’t want to feel “exposed,” which is why they withhold certain information.

• Teams must share vital information with the customer; they can only tell what is essential for them.

• The “all or nothing” delivery threatens adequate time and budget management.

• A Team must focus on delivering new increments of value while balancing the inclusion of innovative features.

• Wanting to achieve everything on the backlog and additional items might be unrealistic; something must come out.

• Scope creep can be avoided with collaborative delivery. It can be a learning experience for the Team!

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, Dan Neumann and Justin Thatil discuss Agility: How do you know if you truly are in an Agile environment? In this episode, they explore the meaning of Agile and the different features that make this framework unique, including Creativity, Teamwork, Mindset, Continuous Learning, and Psychological Safety.

Key Takeaways

• Does Scrum allow creativity?

• The Scrum framework was designed for complex situations where creativity is necessary since there is no “one right way” to solve a problem.

• What does it really mean to be Agile?

• Agile: Able to move quickly and easily. In the Agile framework, this is a constant guideline; the decisions must flow quickly and easily.

• Autonomy is crucially important. Teams need to be self-sufficient to deliver value.

• Inspecting and adapting the plan is necessary since a budget needs to be respected.

• Agile Teams deliver value throughout the process.

• Agile is about an actual team working on an actual problem (thinkers and doers are not working separately on finding solutions).

• Agile mindset vs a fixed mindset:

• Agilists learn by doing rather than over-analyzing before taking action.

• Every Agilist is part of a Team working towards a goal, not a solo player.

• By attending their daily Scrum, you can tell if a team is only Agile by name. They always work as a team rather than as individuals doing their jobs.

• Alignment! What is really the Team’s approach?

• What is the business opportunity the Team is trying to reach?

• Effectively managing budgets can enable Agility

• Continuous improvement:

• There is no lifetime commitment to a particular decision. Instead, adjustments are made according to the needs.

• Value progress over an attempt to design for perfection

• Encourage ongoing learning

• Psychological safety needs to be modeled within the Team, and a context of continuous improvement allows space for speaking up and accepting failures to readjust the course of action.

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, Justin Thatil is joined by two of his Agile colleagues, Mike Guiler and Mariano Oliveti, to discuss the tiredness and frustration that can sometimes be caused by following the Agile process. Some organizations can even be convinced that Agile did not work for them; how can this wound be healed?

Key Takeaways

• Some organizations are sure that Agile didn’t work for them.

• Sometimes, these organizations tried some Agile ways but never started from the beginning.

• Was “moving faster” all the organization wanted? If you don’t adapt the values and behaviors, Agile will not be guaranteed to speed up the process. First, the organization needs to change its culture.

• These organizations might need to consider that Agile is a process, a hard process.

• Today’s transformations are different from what they were ten years ago.

• Benefits of Agile:

• Many organizations need help with accountability, while Agile proposes an excellent method to ensure it.

• Agile is a way of approaching organizations to figure out what they can do for them based on their current needs.

• Agile is the approach that assists an organization in transforming its culture into a long-lasting, durable one with self-managing teams that achieve the desired outcomes.

• Doing Agile vs. Being Agile:

• Doing Agile is about going through the motions and checking the boxes, but, for being Agile, it is critical to change the culture.

• There has to be a need for change in the Organization, otherwise, Agile would not work.

Mentioned in this Episode:

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

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, Dan Neumann and Justin Thatil are joined by an external guest called Rich Visotcky, President and Founder of Joint Insights, who is passionate about creating shared understanding. Rich is a Professional Scrum Trainer with Scrum.org.

In this episode, they explore the topic of cultural impact on transformation. We work in and for organizations that include several different cultures; this imposes challenges, resistances, successes, and opportunities to be seized, as well as other strategies to be used for better performance and communication while on the path of transformation.

Key Takeaways

• It is essential to know what is foundational for each company and how it has contributed to its success.

• Leadership can be the drive to success, but it is the culture that guides the Team to achieve its goals.

• The first step for transformation is to find what the organization truly values.

• Making changes doesn’t mean losing who we are.

• Sometimes, it is necessary to take risks.

• The fear of doing something wrong can keep a Team from trying new paths.

• Self-management cannot be prioritized at the expense of accountability.

• Self-management does not mean anyone can do whatever they want.

• A Team needs boundaries (but not too many).

• A Team’s success can be found in the balance between self-management, accountability, and well-executed boundaries.

• Changes need to be aligned.

• Leaders must communicate why the changes are important and back them up; they must often highlight what they are working towards. The company’s values must be used and reminded throughout the entire change path.

• There can be two or three simultaneous initiatives to avoid confusing people with many variables.

• Conflict is inherent to the process.

• Attributes for a company to be truly Agile:

• Cooperation.

• Speed of decision making.

• Engaging in Trials.

• Empowerment.

• Technology adoption.

• Simplicity.

• Knowledge sharing.

• Innovation focus.

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, your host, Dan Neumann, is talking about a prominent topic: are the times of remote working about to end? Today, he is solo hosting this episode to assist you in navigating this new trend and successfully surviving these changes.

In this episode, Dan discusses hybrid work and the trend of returning to in-person work. He shares some strategies to help Teams thrive in this new work scenario. Things are changing rapidly in this evolving landscape, and several companies require their staff to return to the office; listen to this episode and get some valuable ideas on adapting and succeeding in this ever-changing world.

Key Takeaways

• The pandemic brought the remote working environment as a solution to many problems.

• For many companies, remote working was not a choice; it was a matter of business survival.

• Some benefits of remote working are time and money savings, freedom, and flexibility. Also, companies can attract more talent remotely.

• The ability of companies to innovate was hindered by remote work.

• Tips to work better in a hybrid environment:

• The benefits of a hybrid working environment are the flexible location to perform a job and the possibility of choosing which hours someone would decide to work. These aspects imply both synchronous and asynchronous communication.

• There can be a communication barrier between the in-work and remote workers; more spontaneity occurs in the office. Lacking non-verbal cues of remote communication can affect its effectiveness (video can help, but it is undoubtedly less accurate than in-person communication).

• Remote work promotes more isolation, less communication outside of the direct work area, and fewer additions of new members to Teams.

• Being onsite increases the opportunity to connect more to people in general, including those not strictly in our areas of expertise.

• There is a need to establish explicit Team norms (Make them visible!).

• When hybrid communication occurs in a Team, you must explicitly make room for the remote worker.

• What are your Team’s agreements regarding responding to messages?

• Good calendar hygiene is a factor that enables good remote communication.

• Communicating clearly how a decision will be made can be challenging in a hybrid working environment.

• Decisions are not made arbitrarily; ensure what will be decided and how.

• Use mirroring for collaborating with the Team.

Mentioned in this Episode:

Business Insider: “The remote work era may be coming to an end — if companies can afford to keep their offices open”

“How Remote Work Affects Our Communication and Collaboration”

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, Justin Thatil, your host, welcomes Quincy Jordan and Pamela Dukes, Olympic Athlete and Agilist, who engage in a thoughtful conversation regarding how these two areas of expertise intertwine and how the abilities applied to professional sports enhance her role as an Agilist.

In this episode, you will learn about Pamela’s journey as a professional athlete, the lessons learned, and the challenges that brought the knowledge that enriched her experience in the Agile arena.

Key Takeaways

• Pamela shares her most significant lessons as an Olympian and Hall of Fame athlete:

• “What got you here will keep you here.” You don’t need a Herculean effort to go on; you just have to stay consistent.

• The Team has to support each other. If you are not competing, you are busy cheering for someone else.

• Quincy, who also went through his athlete years, brings two of the most meaningful teachings he obtained from his coach:

• All the way through (you don’t stop until you are done).

• Run your race (stay away from comparisons).

• The Scrum framework mirrors the structure of College Athletics.

• The Head Coach was the Chief Product Officer, and his assistants were the product officers.

• The Scrum Master was the Team captain.

• The plans set for training could be weekly, monthly, or yearly, and once arranged, that was the guideline the athletes follow every day. Everyone knew the plan, but when circumstances changed, the plan was adjusted accordingly. These dynamics work similarly in Scrum; there are planned sprints and releases.

• At the end of each week, they would do competition drills where performance was tested (which looks like a sprints review) followed by a talk, reflecting on what could be improved (a lot like retrospectives).

• Get the lead, keep the lead.

• It is easier to do well and keep doing well than getting into a technical or cultural debt and getting out of it.

• Empower your Team:

• The success criteria should be how well you teach others.

• Practicing skill sharing is critically important.

• Leaders should walk away from the dangerous “hero complex”; a true leader teaches others how to do what they do.

• No one is particularly responsible; a Team succeeds and walks through challenges together.

• Each Team member has to do their part for the entire Team to reach the goal.

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, Dan Neumann and Justin Thatil are joined by Misi Eyetsemitan. In this episode, they discuss the future of Agile, the advantages and challenges they see, and how far the Agile Methodology has come in the last two decades since its origins when it was created to achieve better and more efficient software development.

Listen to this episode and learn more about where Agile is going.

Key Takeaways

• The Agile Manifesto was not created rigidly but was open for future updates.

• Agile evolves powered by the problems that exist today.

• The execution of Agile will remain applicable in the future.

• In the future, Agilists will have to revisit the basics of Agile.

• Future Agilists will have to know why they have chosen Agile and why they are leveraging Agile. Agile is never the solution but brings organizations to the solutions they seek.

• Agile requires to have a transformative mindset.

• What are some challenges in the future of Agile?

• It will depend on the response of the Agilists. Agile is not a one-size-fits-all kind of methodology. The principles of Agile can be applied in various ways to tackle different problems.

• Measuring the value an Agile Team delivers is still a challenge.

• The key is to keep the focus on value. There are many ways to quantify value delivery.

• It is difficult for organizations and Teams to identify the metrics to measure what success looks like.

• The future of the diversity of Agile Teams:

• Agile Teams will continue to be more diverse.

• Diversity will also be needed to solve more complex issues.

Mentioned in this Episode:

Learn more about Systemic Coaching

Check the courses offered by the International Federation of Coaches

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, Dan Neumann and his co-host Justin Thatil are joined by Hal Hogue, who has transitioned from an Agile Coach position to a Managing role and today shares the features of such a shift.

In this episode, Hal discusses his journey from working with managing engineers to becoming one of them. He mentions the particularities of both of these roles, the overlaps between them, and how these positions can work together to advocate for Agility and fast flow.

Key Takeaways

• What are Agile Coaches?

• The Agile Coach is a leader (just like the Manager).

• Agile Coaches are focused on letting others grow (individuals or Teams).

• Agile Coaches also serve as teachers. Coaches teach the true meaning of being Agile by living the values and principles specified in the Manifesto.

• Agile Coaches are change agents, helping organizations avoid becoming stagnant.

• The manager role is not defined in the Scrum Guide, but that does not mean it cannot exit.

• Manager accountabilities:

• A Manager’s first responsibility is to know about the people part of the Team.

• A Manager needs to know what motivates the Team and their aspirations. It requires a lot of active listening and asking questions. A Manager should set clear expectations and roles for the Team.

• The Team should clearly know the reasons why they do their jobs.

• There is a critical relationship between the Engineering Manager and the Product Owner. These two roles need constant communication, aligning goals not only for the product but also around quality.

• A Manager should not decide things for the Team but should take essential matters to the Team and let them be part of designing the solution by giving them options and tools; this requires a lot of trust in both directions.

• Managers can help with impediment escalation or performance issues.

• The Engineering Manager and Product Owner is a critical relationship, as well as the Manager and Agile Coach or Scrum Master.

• A leader must be a coach and a servant leader for the Team but also for the Product Owner.

• A Coach can help a Manager understand what Agility is, its principles, and its values.

Mentioned in this Episode:

Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais

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!