Agile Coaches' Corner

This week, Dan Neumann is joined by Quincy Jordan, who is a Director, Innovate-executive advisor, and a recurrent contributor to the Agile Coaches’ Corner. Today Dan and Quincy are exploring a very interesting topic often brought up by organizations: Which team is the Rock Star Team?   In this episode, you will hear about how to identify the best team, avoiding common mistakes such as measuring teams on their velocity or delivery rates, and also, how to understand what an organization really wants when they ask for the best team.   Key Takeaways Which team is the rock star team? It depends! But first, ask yourself which problem you consider you will solve with an answer to that question? Is the best team the one that delivers the most? Not necessarily; you need to keep on asking questions such as: Why are they producing the most? Does it have a healthy culture? Is the whole team working or is there one person doing it all? Remember that volume of output does not dictate value. It takes time for a team to function well; we are human beings, not robots!   What are the drivers behind the question from organizations asking for the best team? Organizations want to know how to invest, what to look for in terms of return, and how to save. Organizations might be looking to reward teams the right way.   What are some classic ways in which organizations try to measure a team’s productivity? Velocity is a way of measuring a team’s performance but it can easily get dangerous. A rock star team uses velocity to improves itself. A team that improves in diminishing the number of carryover stories keeps on getting better. A great team hits the sprint’s goal and counts with some level of consistency. Volatility: How is the team’s velocity changing from sprint to sprint?   Possible impediments for a team. Is the team really challenging itself? A rock star team challenges itself, if they are achieving the goal too early it can be a sign of them not pushing themselves enough. Watch out that the metric does not become the goal. Not always the top people will make the top team.   Mentioned in this Episode: God Is My CEO: Following God’s Principles in a Bottom-Line World, Larry Julian. Learn more about Quincy Jordan   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 a guest from outside of the Agile Coaches’ Corner, Mike Dionne, who is a Scrum Master and Coach, to explore some of the valuable work he has done with teams from a coaching standpoint.   In this episode, Mike shares how to make work fun and attractive so people would hate Fridays and love Mondays. Mike dives deep into the crucial importance of participation, collaboration, creating a safe environment that fosters vulnerability, and how to promote self-propelling and self-organizing teams.   Key Takeaways How does Mike make things different, beyond Scrum events? If you make things fun, people will want to go to work on Monday, Participation is key: You need to want to be part of the team. Start with a ten-to-fifteen-minute exercise that is fun. An Agile Team needs to be a game where everybody can win. We all succeed or we all fail; communication and collaboration are at the core of a healthy team. A team has to be real. Vulnerability is only possible in a safe environment. How to enable self-organization in teams? Self-propelling is the core of a self-organizing team. Form a team, make it a good team, and bring work to it. Avoid just forming a group of individuals for a certain job, they might never become a team.   Mentioned in this Episode: Mentor: The Kid & The CEO, by Tom Pace with Walter Jenkins Mike Dionne on Linked-In   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, Director of the Innovative Line of Service at AgileThought. In this episode, Dan and Quincy dive deep into the topic of metrics, especially in the aspects that should be taken under special consideration while running an Agile Team. These Agile experts go through different areas in which metrics can be applied such as:  Velocity and why leaders tend to be interested in it,  Number of stories, testing, and how much ahead is healthy for a team to be,  The value of tracking points per person in a team, and  The Acknowledgement piece: giving credit should be a result of delivered value.   Key Takeaways Value, metrics, and how they relate with velocity There is a common struggle in applying metrics to a work that has already been valued. What is the real intent of velocity? How can velocity help the team? It can be pervasive to apply velocity in the way Frederick Winslow Taylor suggested. Putting output over the outcome is the opposite that an organization needs to do. The most important is what the team achieved and that it is valuable to the organization and its customers. Velocity and its interest in leadership Leaders tend to compare teams’ velocities. A team’s velocity depends on its composition and its expertise in the actual work that they are doing. A team may appear to go slower but that might be due to how complex the tasks are they were assigned. Instead of going after the metric of velocity, it is more efficient to check how consistently a team is doing its job. Velocity can be used to anticipate when new capabilities can be expected. Pay attention to how the stories are carried into a sprint. Comparing the number of stories that were tested in a sprint versus the last sprint can be tricky. There is a problem in pushing things through without testing them. Each sprint is almost considered its own project. Pay attention to an unusual number of stories that are completely refined and fully ready in the backlog. Have you planned up too far? This can be a problem since things might change in the meantime. It can be frustrating to have a lot of work done that will never be used. Can tracking points per person have a healthy value? If points have been tracked per person, that information shouldn’t get through the team. Do not share those metrics across the board, they belong to a one-on-one conversation. Ask yourself: Is the team making increments of value as the product backlog levels? Is the product built and tested? People seek credit; acknowledgment is important. Team encouragement is crucial to remain as enthusiastic as possible, but getting credit for an outcome that hasn’t been properly achieved is dangerous. Teams need to get credit for delivering what was intended to be delivered, not just for doing the work. (Users and customers don’t really care about the work, they only care about the value that is being delivered).   Mentioned in this Episode: God Is My CEO: Following God's Principles in a Bottom-Line World, by Larry S. Julian   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 two Agile colleagues, Sam Falco and M.C. Moore. In today’s episode, they are taking a little trip back in time to explore the impact Frederick Winslow Taylor had on modern work. Taylor has been called the father of Scientific Management and his thinking pervades the way teams work today.   In this episode, the book The Principles of Scientific Management and its principles are explored in comparison to the Agile modern ways. You will hear about effectiveness, interactions, trust, productivity, creativity, and accountability, among other valuable concepts that today are seen and approached in significantly different manners as a result of the evolution and progress in this field.   Key Takeaways The Principles of Scientific Management was written by Frederick Winslow Taylor and published in 1911 Taylor had a special disdain for working people that showed in his writings. How is Taylorism showing up today in modern management?  Overemphasizing Agile metrics The use of certain nomenclature Work smarter and harder. Productivity depends on the company to manage not the people who are actually doing the work. What motivates people? The ability to be autonomous about the work To have mastery and purpose Give people the goal and let them figure out the “how.” Trust in workers is crucial and they need to be motivated by their managers; if they receive fulfilling work to do they will have the way to get it done Agility vs. Taylorism Agile considers interactions more important than processes and tools, while in Taylorism the system is all that matters and must be first. M.C. More shares a real Agile example where an individual was very motivated to grow and expand in a company that didn’t offer an opportunity for that at that point, so instead of letting him leave, the organization created a new space for that worker to thrive. Decentralizing decision-making down to the level of the Agile Team is a break away from Scientific Management. Taylorism wants to separate people from decision-making as much as possible, exactly the opposite of what Agile teams aim for. Companies are supposed to attack the system when it is broken, not to try to manage the individuals. It is really hard to be creative when you are being micromanaged. Taylorism uses results for accountability while in an Agile team everyone is holding each other accountable for the work as one of the Agile principles says: Build projects around motivated individuals, give them the environment, support their needs, and trust them to get the job done. How does an Agile Team manage innovation and new ideas? The biggest challenge in knowledge work is that you are doing something that has never been done before New good ideas should diffuse across the team; that does not mean everyone should be doing the same but they should try them and see if they make sense with each team’s local context.   Mentioned in this Episode: The Principles of Scientific Management, by Frederick Winslow Taylor Drive: The Surprising Truth About What Motivates Us, by Daniel Pink Humanocracy: Creating Organizations as Amazing as the People Inside Them, by Gary Hamel and Michele Zanini Project Gutenberg: Books by Frederick Winslow Taylor   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 three of his AgileThought colleagues, Carlos Romero, Justin Thatil, and Mariano Oliveti to talk about different cultures and how they impact agility.   In today’s episode, you will hear about the concept of power distance and how it differs in different cultures with real examples of how organizations work in several countries around the globe. These three experts also share their knowledge regarding the diverse levels of uncertainty avoidance in different cultures and how it impacts agility.   Key Takeaways Different Cultures and their tendencies Power distance is the degree to which the people who are called “lower” on the ladder expect there to be a gap between them and those who are higher on that ladder. Power distance varies in different countries. If there is a high power distance in an organization, modeling challenging behaviors is a good way to shorten the gap. Encouraging experimentation on the team is another way of reducing the power distance. Uncertainty avoidance talks about “a truth”; a “right way of doing something” in some cultures which results in avoiding uncertainty. One clear way to determine if a team is trying to avoid uncertainty is that developers can take a long time to do their work, as a consequence of trying to go through every detail instead of seeing the overall structure. A spike is useful for those cases when a team is not sure if something will work, someone builds something quick and just tries it out, being an efficient way to alleviate uncertainty. Diversity matters! Building empathy in the teams to encourage respect for different approaches and tendencies. Applying Agile and Scrum values consistently is necessary. Don’t focus on the problem itself but rather on coaching the people.   Mentioned in this Episode: Carlos Romero Justin Thatil Mariano Oliveti   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 Brian Pivar, Senior Director of Data and Analytics at The Kraft Heinz Company. There is a lot of Agile in the software community and Kraft Heinz is one of the companies practicing the Agile way.   In this episode, Brian shares extensively about his career at Kraft and how he started the digital revolution in the organization, promoting a culture change and encouraging different ways of functioning through Agile. Brian dives deep into his approach regarding recruiting and developing talent, as well as emphasizes the importance of following solid leadership principles that he details during this thoughtful conversation.   Key Takeaways Brian describes how Kraft got into the Agile world Brian joined Kraft three years ago to lead the Data and Analytics section with the goal of bringing analytics to a more legacy company. The first two years they had a waterfall approach, hearing the organization’s needs and prioritizing the top ones while building a strong data foundation and team. One year ago, Kraft started the Digital Revolution journey and part of it was starting to run Agile in the digital organization. Now ten pods are running Agile with over 100 people,  and Kraft is planning to double these numbers in one year. There is a plan to extend Agile to other sectors of the organization. How did Kraft get support for the timeline they proposed? The board of directors was the one supporting the migration to become a more digital organization from the beginning. There is a five-year road map, if you try to rush the process it won’t be successful. What are the aspects where alignment is needed? How to enable a team to respond to a local context? Some of the staff have the technical knowledge and they are learning more about Agile in the process, through meetings and effective communication. All the conversion to Agile and digitalization was done virtually, based on collaboration among staff, not always following Scrum. Listening to every idea is crucial to know what will and won’t work for a team. How does Kraft enable a unique culture? Brian was hired to enable a culture change. Brian protects his team by stating how they will perform in a different way than the rest of the organization, following solid leadership principles in micro and macro levels: 1. Family first. 2. Hiring develops the best. 3. Big bold bets. 4. Let builders build. 5. Best idea wins. 6. Ownership. 7. Learn and be curious. 8. Lead by example. 9. Validated learning. At Kraft, they built a structure for builders, from an Associate Data Scientist to Data Scientist, Senior Data Scientist, Staff Data Scientist until Principal Data Scientist, this last one being a highly regarded position. They are also making the transition easier for those who want a pivot in their careers. Recruiting and developing talent Brian’s five-year plan includes making Kraft be seen as a tech company, not just a CPG company. Hiring young talent and developing it within the organization once the company has hit a steady stage. The culture is impacted by people working from their homes and not in an office with all the teammates, and Kraft adapted to these new circumstances through a buddy system.   Mentioned in this Episode: Kraft Heinz Company Brian Pivar Your Next Five Moves: Master the Art of Business Strategy, Patrick Bet-David   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 Sam Falco are together to talk about sprint duration. A common question is “How long should my sprint be?” followed by the classic consultant answer… “It depends.”   Today, Dan and Sam are sharing the definition of sprint and how you can decide the right length of a sprint for your team. They explore different sprint durations, from less than a week up to a month, and how to pick the one that benefits everyone on the team.   Key Takeaways What is Sprint in Scrum? Sprints are the heartbeat of Scrum where ideas are turned into value. The whole idea of a Sprint is to create a done increment. All of the work that a team needs to do has to take place inside of the Sprint. All of the work that needs to be done to get to the product goal has to be done in Sprints. Scrum is not a task management system. Is there a supposed length for a sprint? According to the Scrum Guide, a Sprint can be 'up to one month long,' in spite of the common idea of 2-4 weeks. The scope can vary in a sprint, as long as the team is aware of their sprint goal. Balancing flexibility vs. stability The Leave-you-alone principle: A Sprint is an agreement between stakeholders and the Scrum team, where the first party agrees to leave the Scrum team alone to do what they require them to do. One of the principles behind the Agile manifesto is the idea of sustainable development, the sponsors, developers, and users should be able to maintain a constant pace indefinitely. A business can shift entirely at the end of a sprint, but within the sprint let the team work towards a goal. If there is an urgent need to change, the sprint can be canceled, which is tremendously costly and needs to be avoided if possible. Different levels of projects determine different sprint duration Do not forget that a team’s priority is to deliver early and continuous software delivery. Dan and Sam share examples of ten three-day sprints and one-week sprints to achieve more focus on the goal. Two-week sprints are the most common ones but it might not be a good length for everyone in all domains, especially depending on all the stuff that needs to be done. Automated testing is a great way to save time. A three-week sprint does not align with the 52-week calendar, what should you do with the extra week every month? Defying the tyranny of the calendar can be fun and motivating. The month sprint can be tricky if the client, thinking that there is plenty of time, starts asking to add or change elements. Ask yourself: Does your team need more time to innovate? Are you cutting quality as a result of rushing towards the goal? Pick the shortest sprint length possible for your team to start with since you can always relax that a little later on the journey if it needs to be that way.   Mentioned in this Episode: Scrum Check “Episode 34: Sam Falco on Understanding the Definition of Done in Scrum” The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning Out of the Crisis (The MIT Press), W. Edward Deming   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 a first-time guest on the podcast, Seth Jacobs. He is a Sr. Director of Experience Design at  AgileThought.   In this episode, Seth talks about technical excellence, from a design language and design system pattern to help the audience understand how these systems and patterns can be started and used, as well as the implications of evolving them over time.   Key Takeaways What is a Director of an Experience Practice? The role of an experienced practice director is to approach design from an architectural level, how the design teams work together, as well as contemplating what has been delivered. A Director of an Experience Practice supports teamwork.   Where are some of the places where technical excellence really pays off from an agility standpoint? Documentation has a huge role on the technical side, how they are taking them and how they are being shared among the team. The Storybook is a way of having the collection of components or controls that are used in an application, that becomes a visual library for everyone across the teams to use.   How is standardization balanced to avoid getting stuck? The design system is really the collection of several different things including a component library, and how all these components are arranged into patterns. The benefits of the design system are clear when all teams have a shared understanding of what patterns need to be implemented in which cases.   How is the feedback received from people who are working from the design patterns in order for them to continue to evolve? It depends on the size of the teams and how they are structured. Agile Thought counts with a core team that works with the designers and through the design thinking process, to then feed these processes on the other teams.   Why are the elements of a design system so valuable? How do they pay off? One of the biggest payoffs is for the users. It makes sure that consistency is being preserved. Seth talks about different design language tools.   How should organizations react to changes? Go back to the original user’s journeys and the goals of the user to see what kind of potentially systemic effects that change could have. Remember, the most important thing is how much value you can bring to the business or the user.   Mentioned in this Episode: Learn more about Seth Jacobs   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 Nicole Scheffler who is an Engineering Leader from VMware. Nicole has some passion projects around the Tech Diva Success collection, including podcasts, books, and courses, all with diversity as their main component.   Tech is a field that is not particularly diverse and that is the reason why in today’s episode, Nicole is sharing the meaning of diversity, inclusion, and equity and what that might look like in the workplace from an organization to an individual level.   Key Takeaways What do diversity, inclusion, and equity mean? Nicole shares an analogy: Diversity is being invited to the dance, inclusion is being able to dance and being asked to dance when you are there, and equity is the feeling that you belong there. Progress happens when everyone has a voice and is being heard. Psychological safety and culture building is crucial in an organization. Innovation is another pillar for success. How are companies handling diversity? Design thinking is a great way of practicing inclusion. Most organizations have diversity on their radar, but there is a need to make sure that they are not just “checking the box.” Organizations need to do a statistical analysis to determine where diversity is broken. Ask questions, if you don’t ask, you won’t know. What does sharing perspectives look like? Don’t assume someone’s role. Nicole shares some valuable examples. What can teams do independently from the organization? Ask yourself if you are judging a woman differently than you do with a man, are you being fair? Good leaders take seriously the job of creating psychologically safe workplaces. What can you do to promote diversity and inclusion? Speak up and share resources. Evaluate if you have unconscious bias. Make sure that your team knows what is available. Be an ally and speak up when something is wrong.   Mentioned in this Episode: Pillars of Success, by Nicole Scheffler Purl, directed by Kristen Lester and produced by Gillian Libbert-Duncan   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 a recurrent guest, Adam Ulery, to talk about the importance of aligning strategy with execution as a necessary step to reach the top-level vision at an organization. The lack of alignment between strategy and execution is often seen among leadership teams and portfolio management teams and is manifested in program and delivery teams as well. This deficiency is mostly perceived as a symptom, not realizing that is the root cause.   In this episode, Dan and Adam discuss some of the root causes of the lack of alignment, they share strategies to organizations that are lacking alignment, and they dive deep into how to measure if a company is moving closer or farther from its strategy in order to enable accountability in every sector of the organization.   Key Takeaways What does the lack of alignment between strategy and execution look like? The team is not sure what to work on. The team feels it is not getting clear direction on the objectives. Heads of organizations might not be in agreement  There are serious consequences as a result of the lack of alignment between teams; one of them is having too much work in process (since the team is not rejecting the job that does not strictly align with the organization’s vision). The Root Causes for lack of alignment: If there is no strategy it is impossible to align to it. Having a strategy that is not coherent, clear, well written, or there isn’t an understanding on how to execute on it. The leadership team doesn’t have a clear understanding of the strategy. Sometimes strategies are too broad or too complex to be meaningful. Undermining the strategy by executives that don’t agree with it. The strategy is not communicated effectively. How to begin aligning strategy and execution? First, the organization needs to create a strategy if it doesn’t have one.  If there is a strategy, make sure it is clear or clarify it. Ask yourself: Are we committed to this strategy? Are we executing it? Understanding the deviations from the strategy is part of becoming accountable. Celebrate those who show behaviors that prove an alignment with the strategy. How does an organization measure if they are moving closer or farther away from the strategy to help enable accountability? Establish value-based measures and consistently use them. Pay attention to key results, not to the activity. Reinforce the collaboration between verticals and horizontals. A periodic inspection is necessary. What can somebody closer to a team level do in the absence of a clear strategy? Ask questions, be curious, talk openly about this in a productive way. Make visible that there is no alignment between strategy and execution.   Mentioned in this Episode: Listen to Episode 138: “Strategic vs. Tactical Decisions and Actions with Adam Ulery”   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!