Agile Coaches' Corner

This week, Dan Neumann, your host, is joined by Christine Bush. In this episode, Dan and Christine embark on an insightful exploration of Disciplined Agile, a domain in which Christine is certified. They unravel some of the intricacies of Disciplined Agile, addressing its profound impact on organizations.   Throughout the episode, you’ll gain a general understanding of what Disciplined Agile is, learn more about the six distinct life cycles that define this approach, and discover how they contribute to organizational growth and success. Tune in to today’s show and gain valuable insights that will guide your organization on its journey towards continuous improvement and enable you to navigate the ever-evolving landscape of Disciplined Agile.   Key Takeaways What is Discipline Agile? It is a tool kit rather than a framework. Discipline Agile meets the organization where it is. Discipline Agile finds the best ways of working for each organization. The six life cycles in Disciplined Agile: The Agile Life Cycle: A Scrum-based Project Life Cycle. The Lean Life Cycle: A Kanban-based Project Life Cycle. The Continuous Delivery: Agile Life Cycle. The Continuous Delivery: Lean Life Cycle. The Exploratory (Lean Startup) Life Cycle. The Program Life Cycle for a Team of Teams. Within an organization, different life cycles can be used by other business units. Disciplined Agile focuses on: What is the team? What does it need? Christine dives deep into the Agile Life Cycle. The work is primarily for organizations looking for enhancements or new features. An Agile Life Cycle allows users to Identify, Prioritize, and Estimate. It is essential to analyze your context in Disciplined Agile. The spiral diagram is one tool provided by this tool kit that considers the team size, geographic distribution, compliance needs, and technical and domain complexity. It is necessary to evaluate technical complexity.   Mentioned in this Episode: Find more about Disciplined Agile at Project Management Institute Learn about DAC Certification (Disciplined Agile Coach)   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 is joined by his colleague Justin Thatil to explore POWER Start, a great strategy to help you plan, structure, and run your meetings effectively.   In this episode, Dan and Justin dive deep into the structure of POWER Start and the fantastic benefits that result from using it as the most effective tool to make meetings productive and, even sometimes, the way of knowing when an event needs to be canceled.   Key Takeaways What is POWER Start? It is a formula that was created to allow people invited to a meeting to have the right frame in order to have a productive session. POWER: Purpose, Outcomes, WIIFM (What is in it for the attendee?), Engagement, and Roles and Responsibilities. POWER start is the formula for the host of the meeting to communicate to the folks who will be attending the event about the most important aspects of it, for example: How is the Team going to be engaging? What is the purpose of the meeting? How they will be contributing to it? PURPOSE: Knowing the purpose of the meeting is crucially important, which also lets you know why someone is invited to a particular meeting. Knowing the purpose of a meeting means understanding the reason why people are getting together. OUTCOME: The outcome is explicit, and it refers to what could be deliverable. What are we trying to achieve as a result of this meeting? Sharing this information helps the assistants to prepare for it and be able to anticipate what the session will be like. WIIFM (What is in it for the attendee?): This section contains the benefit that each of the attendees can expect from a particular meeting. Sometimes there is a concrete reward. It can also be a reminder that there is a bigger purpose to what each of the attendees is doing. You can engage and propose solutions; it goes beyond the idea of being lectured by someone. ENGAGEMENT. How does POWER Start engage the participants?  The meeting’s host need to puts into practice facilitation techniques. Sometimes staying concentrated is not that simple! Using the proper engagement tools is vital. ROLES and RESPONSIBILITIES: What is expected from the attendees of a meeting? A Scrum master is expected to exercise the art of participation so members are encouraged to be engaged in their roles. After the meeting: The “after” should be based on the outcome you had set for the meeting. What are the actions that I need to take after the meeting?   Mentioned in this Episode: The 5 AM Club: Own Your Morning. Elevate Your Life, by Robin Sharma   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, Ola Tunde joins Dan Neumann to explore the innovations on SAFe, which just launched the 6.0 version.   In this episode, they talk about the new features of SAFe 6.0, including new strategic themes. Dan and Ola Tunde dive deep into the benefits and advancements this latest version of SAFe offers Teams and Organizations.  Key Takeaways Strategic Themes that SAFe presents:  Strengthening the Foundation for Business Agility Empowering the Agile Team even in their responsibilities, giving decision-making authority to the Teams. Accelerating value flow: How does a Team identify the bottlenecks? What is slowing down the value of delivery? Enhancing business agility with SAFe across the business Building the future with AI, Big Data, and Cloud Delivering better outcomes with measure, grow, and OKRs How does machine learning fit into SAFe 6.0? SAFe 6.0 gives exposure to AI. SAFe 6.0 enables and promotes the uses and practices of AI. SAFe 6.0 focuses on measurements on every level before scaling. Velocity is not what we should measure. SAFe 6.0 empowers the Scrum Master but also holds it accountable. A Scrum Master must help with the improvements of Flow by using metrics. A Scrum Master must support the solutions in delivering each iteration.  SAFe 6.0 will help organizations hire more quality than hiring bodies.   Mentioned in this Episode: Become a Professional Scrum Trainer  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 is joined by Mike Guiler to discuss the benefits of Agility, including employee satisfaction, predictable delivery, and speed to market among others.   Key Takeaways: Agility leads to employee satisfaction since every Team member is connected to the purpose of the work. Sustainable pace is enabled by Agile Methods Agile done well eliminates the “death march” Deliver slices of value  Deliver the most valuable items first Agile delivery is not “all-or-nothing,” enabling us to decide what we can release without Predictable delivery is mostly assured with Agile, and even when the mark is missed it can be adjusted back in a brief period. Reduction of Waste The Increment is inspected frequently We learn from what we deliver You can stop and pivot when going down a path that is not what the customer needs Make change easier Validate assumptions early Reduce Risk  Don’t build the whole thing before we deliver it Reduce risk by gradually exposing your features to users versus an “all-or-nothing” release Incremental deliveries reduce risk by validating assumptions. You get real customer feedback. Speed to Market Deliver the right things, reduce waste, and get a slice delivered! Do not expect that your developers will “code faster” Faster Return on Investment Generate revenue with small slices Decide when to stop investing further in a product When you decide to transform your business outcomes, you need to consider the benefits you are striving for when you make decisions within your organization. Keep the end goal in mind at all times. We want to be efficient instead of effective. Collaboration works wonders; a Team is more resilient and efficient when collaborating. Some people are not ready to work in a Team; they need space and time to gradually start feeling more comfortable with teaming. Scrum is often perceived as having a lot of meetings when in reality, the meetings required are the minimum necessary to keep the Team aligned toward achieving the common purpose.   Mentioned in this Episode: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren Ph.D., 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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

This week, Dan Neumann is handing his role as a host to Buyi Kalala and Mike Guiler, who are leading today’s episode. Gerardo DeLaFuente and Eric Lindgren join them to discuss information radiators for leadership.   In this episode, they explore how information radiators influence a Team’s performance and the delivery of value when going from one engagement to the next. They also dive deep into the benefits and challenges of using these tools and list which tools are best, to begin with.   Key Takeaways What are some of the best Agile engagement tools? These tools provide excellent visibility of the work in different stages, from conception to delivery. This information will give us a good way of understanding how the Team is performing. Value Generator: Some metrics can be used internally or when you are delivering a system to customers. Sierra and Jira are great tools for the Team to update their work and show different types of progress (a feature, a sprint, a release). These tools require less time to manipulate the data. DevOps. How much value are we creating and delivering? One of Agile’s advantages is that all the work can be shown. Using radiator information tools is a great way to obtain feedback and ensure the Team is on the correct path, make a turnover, and apply the necessary changes to adapt. Leaders benefit from using engagement tools in several ways. Leaders can decompose the work associated with features epics and highlight when the Team is expected to deliver the value related to the product goal by communicating that through a big information board to communicate with Leaders and Executives; this way, delivery dates can be anticipated. How can a Leader explain the facts behind the metrics? First, explain how the tool works (How many sprints at a given velocity?). The number of sprints will increase while more unexpected situations arise in the process. What type of information radiators are good to start with? Burn Down chart shows what you have planned for the sprint and the progress towards that goal. Burn Ups Charts can be used at the feature level because it shows the total backlog and the progress toward meeting it (and how much the backlog is growing). Flow Diagrams are used to manage flow stability. DevOps provide the ability to build dashboards that help identify velocity, lead, and cycle time. Is there anything that prevents Teams from capturing information within a tool? First, the Team needs to know how to update the information. The Team needs to work with the parameters and make adjustments while advancing the work. The Team has to be self-accountable to make all the necessary changes. Without the complete set of data, you won’t get an accurate anticipation of the upcoming process. Explain to the Team why these tools are beneficial. Team members focus on delivering products, which is why they feel administrative work is a burden and a waste of time. Scrum Masters need to be great communicators, explaining to the Team members the reasons to use these tools and also the benefits resulting from using them.   Mentioned in this Episode: Check articles in Scrum Alliance and Scrum.org.   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 is joined by Buyi‌ ‌Kalala‌ to talk about the Scrum Master role and the misconceptions associated with it.   In this episode, Dan and Buyi address the personality types that seem more effective/successful in the Scrum Master role.   Key Takeaways What do Scrum Masters really do? There are a lot of misconceptions regarding the roles of a Scrum Master. A Scrum Master guides Team members to find a more effective way to deliver work, improving what they do and ensuring they follow Agile principles. Teams are diverse, and each Scrum Master is responsible for navigating different cultures, terminologies, and approaches. A Scrum Master must observe the Team when they formulate their plans and go through a daily Scrum, seeing how they deliver value (which could be complicated in a highly remote work environment). Personality types, training, and experience that match better with the Scrum Master role. Some great Scrum Masters happened to be teachers in the past, and most are also parents. Experience is as important as certifications for a Scrum Master. The Scrum Master Certification needs to come from a reliable source, but it is just a stepping stone; putting the knowledge into practice is fundamental. There are a lot of ways to deliver value, but there are some practices that certainly benefit the Scrum Master in the implementation of the process. A Scrum Master needs to give to get, this is fully relational, and the foundation to really build a good relationship is trust. Diversity enriches a Scrum Master’s work. The role of a Scrum Master is all about presenting and delivering value to the Teams and building high-performance forming Teams.   Mentioned in this Episode: Become a Professional Scrum.org Trainer   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 is joined by his colleague Mike Guiler to talk about Teams. Dan and Mike explore the four types of Team topologies and the three different types of interactions among them. They also dive deep into how to design effective Teams and how to help them grow so they can move at the speed of the customer.   Key Takeaways Why is a Team more than just a group of people? Sometimes you can see a collection of people, not really a Team. It is impossible for everyone to talk to everybody; the Team structure supports effective communication. A Team must have the power to make decisions, which is called bounded autonomy. A Team has autonomy and uses its expertise to decide the most appropriate decision at a given time. A Team can choose what it considers the right tool at a particular moment. Team Topologies: Four different types of Teams: Stream-aligned Team: aligned to a flow of work from (usually) a part of the business domain. This type of Team is a lot like a Scrum Team. Enabling Team: enables a Stream-aligned team to overcome impediments and can also notice missing capacities. This Team allows the stream-aligned Team to keep growing. Complicated Subsystem Team: where significant mathematics/calculation/technical expertise is required. Platform Team: a collection of other Team types which provide an exciting internal product to accelerate delivery by Stream-aligned Teams. Three different interaction modes between Teams: Collaboration: It is about working together for a designated time to discover new things (APIs, practices, technologies, etc.). X-as-a-Service: Defines the scenario when Team A provides, and Team B consumes something “as a Service.” Facilitation: It happens when a Team helps and mentors another Team.   Mentioned in this Episode: Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais “What is a Thinnest Viable Platform (TVP)?” User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton and Peter Economy   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!  

In this episode, Eric Landes addresses the challenge of doing Continuous Delivery on a Scrum team. Many teams and organizations struggle with Continuous Delivery, and some think that in a Sprint there can be only one release. Or, they struggle with getting their Increment good enough to be “potentially shippable.” What’s a Scrum Team to do? Check out our public Scrum training courses if you want to attend Scrum training. Key Takeaways: The 2020 Scrum Guide talks about Scrum teams creating multiple increments within one Sprint. Now the Scrum Guide is encouraging frequent releases. Which makes my DevOps-focused heart sing! What does this mean to your teams? In my opinion, aiming to deliver to production frequently helps your team focus on quality. The Scrum Guide does not specifically say to release to your customer. Potentially shippable is the term, but I encourage teams to aim for customer feedback through frequently releasing to production! If the team makes releasing to Production part of their DoD, they need to figure out what that means in their organization. How do they ensure high quality and safety for the product before it gets to the customer? For software teams, this would include thinking of automated testing and automated deployments. Teams that adopt these practices include that work when decomposing PBIs into your Sprint plan. This thinking helps the team focus on how they can automate other requirements to meet organization standards and remove bottlenecks to production deployments. For instance, if your organization has compliance policies, your team may be able to automate compliance verification. This can be done using third-party tools, or your team can customize the automation necessary for compliance verification. Discuss these options within your team. Help team members think outside the box for solutions. For organizations that have gates in place, like a change advisory board (CAB), talk through options that meet the requirements. For example, your CAB requires a list of new features that are being deployed. Use release automation to automatically create release notes and notify CAB members of the notes. Most of the time, teams object to continuous delivery based on organizational impediments, not technical ones! Keep this in mind as you encourage your Scrum team to self-manage obstacles. Show others in the organization better ways to ensure the quality and safety organizations strive for in production. Use PBIs to experiment with team members' ideas. As the Product Owner orders an experiment in the backlog and brings it into the Sprint, teams measure the experiment's impact toward continuous delivery. Continue to use the framework to your advantage to achieve Continuous Delivery. This is doable, teams, don't be afraid to use Scrum and Experiment toward Continuous Delivery!   Related to this Episode: A complete list of the current Scrum Training by AgileThought. 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 is joined by his colleague and friend, Adam Ulery, to talk about product backlogs.   In this episode, Dan and Adam explore the recent patterns showing interesting ways of using Agile terms, as it is an example nowadays that people call product backlogs the source of requirements for the Team, they discuss today the challenges that may arise as a result of this misinterpretation.   Key Takeaways What are product backlogs? And why they are not just the source of requirements. A product backlog is a list of all the things that will be needed for product development. If you consider product backlogs the source of requirements, then the only action that can be taken is to deliver them, not leaving any room for creativity or flexibility. No new alternatives seem to be welcomed if “the requirements” are already set. The product backlog often grows when items are added (this is one main distinction from a list of requirements). Where’s the commitment point? Adam advises differing that commitment point as far into the future as possible so the Team can make the best decision that they can. Don’t forget the learning component. We are building to learn, always trying to learn and to use that knowledge to inform what we do next. We always update our plans based on what we are learning. Do Teams have to have a hierarchical structure with epic and features? Adam explains how this became a trend over time. There is a need to organize the work to show to the client, but when encountering unexpected work that needs to be done, it does not need to appear in the user story format since it is simply not valuable.   Mentioned in this Episode: The Art of Prayer, Kenneth E. Hagin   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 is joined by Quincy Jordan. In this episode, Dan and Quincy discuss the current state of events for the Agile movement, they dive into an insightful discussion about what Agility really means and what the key elements are that make a sustainable transformation to Agile. Quincy and Dan share how Agile works when an organization is true to its principles, follows its manifesto, and embraces its mindset.   Key Takeaways Agile impasse point: People are trying to decide whether Agile works or is it just smoke and mirrors. Agile has proven outcomes with many successes across different organizations. Those who truly embrace Agile (its principles, manifesto, and mindset) have reached success. Transformation sustainability: Some organizations have undergone a transformation, but without thinking about how things will change due to it. Agile does not work as software you can install. Agile is not cookie-cutter. Agile requires collaboration and is also time sensitive. Every generation decides which practices are going to be continued and embraced and which aren’t. What happens when people are being “forced” into Agile? The outcome will change according to the environment. Is it a supportive Agile ecosystem? The collaboration of every member is needed for Agile to be successful. Some organizations are going to differentiate themselves as a result of Agile really working for them. People realize that Scrum is Agile, but Agile isn’t Scrum. Scrum is just one way, not the only way. What does fully Agile actually mean? It is probably just an expression, but it could either follow practices without following the true Agile meaning or without embracing the cultural aspect or behavioral changes. Always keep an iterative approach: Stop and reflect: What type of things do we need to change? What are the tools that could be used that were never tried before? It is essential to keep the retrospect in the Agile transformation, to actually retrospect on the Agile Journey. Some collateral Agile benefits: Noticing you have significantly fewer problems than the organization used to have. Noticing there are fewer struggles when people are coming back from vacation. Mentioned in this Episode: Coaching for Performance: The Principles and Practice of Coaching and Leadership, by Sir John Whitmore The Fifth Discipline: The Art & Practice of The Learning Organization, by Peter Senge   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!