POPULARITY
In this episode, Dan Neumann is joined by a frequent guest of his and AgileThought colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and has been with AgileThought for almost three years. Together, they will be exploring when things are going so well that you just don’t notice that there are problems bubbling beneath the surface. They address what kind of problems show up when teams become complacent due to things going so well, how to spot these problems (and address them) before they start, and how to differentiate between when things are going “so well that you don’t notice” and actually being on the right path. Key Takeaways The problems that arise when things are going so well that you don’t notice that they’re not: When a Scrum Master is doing super well in their role, those outside the team or the leaders in the organization begin to question if they really need the role However, if you remove that Scrum Master when the team is doing great and maturing well, things will continue in a downwards trajectory (the same way a car does when a tire goes flat) It’s the classic scenario of “you’ve done your job too well” and others don’t realize how valuable and important that is Sometimes the role of Scrum Master role is switched up or rotated in a way that doesn’t fully fill it and the wheels eventually fall off When things are going well those who suffer from a hero complex lose the opportunity to be the hero anymore — this can lead to situations such as: When developers have an abnormal tolerance for tech debt (i.e. they are not paying as much attention to the quality of code or adhering to standards that are good for the team, which creates an abnormal amount of bugs that the team has to fix. Then, said developer jumps in as the hero) I.e. Firefighters lighting fires to put them out When things are going well there can be a tendency to start to question roles and processes (such as the Scrum Master role and the processes and organizational support that are in place to support the team/s) When things are questioned, it can affect not only the team/s, but it also affects the organization as a whole Both the team/s and the organization can become complacent if things are working so well How to avoid getting trapped in this way of thinking: Leadership should be constantly assessing whether or not they’re providing the right types of problems to solve The team should be asking themselves if they’re looking at the right problems to solve Is the team properly considering Horizons Two and Three if they are beginning to go down the path of the Three Horizons model? Shift from “How much faster can the teams go?” and “How much more stuff can they deliver?” to “Are we delivering the right capabilities?”, “Are we delivering things customers want?”, and “Are we continuing to experiment and innovate?” The wrong question is: “Can we get even more out of this team?” The right question is: “Can we make sure that we’re providing them with the right problems to solve?”; “Where can we, from a leadership standpoint, give more guidance to increase business value?” How to differentiate between a mature and a complacent team: Though they can sometimes look the same on the surface, a very complacent team will have far more carry-over stories than a mature team Ask: ‘How well has this team challenged themselves in terms of their own velocity?’ and ‘Are they taking it upon themselves?’ A more mature team would exhibit these types of these behaviors as opposed to a complacent team A more mature team makes time for continuous improvement and retrospectives whereas complacent teams make them cut them out or make them shorter Mature teams dig deep and find opportunities to improve Mature teams look below the surface and think more critically Mentioned in this Episode: Quincy Jordan AgileThought Careers Agile Coaches’ Corner Ep. 101: “Are Scrum Masters Expendable?” Three Horizons by McKinsey & Company Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr 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 you’re in for a treat (or trick)! It’s the Agile Coaches’ Corner special Halloween edition episode! Joining Dan for this spooktacular episode is frequent guest host, Sam Falco. Together, they will be exploring the Scrum treehouse of horrors! Throughout their careers, both Dan and Sam have both experienced their fair share of horrific Scrum experiences. So, what better way to spend Halloween than to share some bone-chilling Scrum horror stories? From failing your sprint goal to poor planning and beyond, come join Dan and Sam by the campfire to hear some Scrum horror stories that will leave you shaking! Key Takeaways Bone-chilling Scrum horror stories: A team that is not allowed to plan correctly A team that doesn’t understand the concept of the sprint goal being different from the sprint scope Failing your sprint goal! Planning a sprint to 100% capacity and then getting a new request by a customer last minute (which leads to a spiral of frustration, bad morale, inability to deliver, and eventually, a huge quality problem) When a team can’t cut scope and can’t cut time so they cut corners Disrupted work which causes bugs to begin to be let through When Scrum becomes a mechanism for developer abuse instead of a tool for the team/s to manage their work and deliver a higher return on investment Hearing: “I thought Scrum was just a way of churning through requirements in two-week sprints.” A bad culture built off ego and pressure A manager that berates the team and tries to control them through power and fear A manager that disrupts the team and creates a toxic environment with poor morale A system based on fear with an emphasis on simply wanting to “look good” and not in supporting a culture of safety Waterfalling through an 18-sprint project (with this, there is no room for improvement, adaptation, and iteration; the team/s can’t experiment their way to a valuable outcome because they’re simply being given a list of tasks to accomplish rather than being able to use their imagination and creativity to solve cool problems) Not to fear about these Scrum horror stories — there’s still hope! In most cases, a project is never unrecoverable; You can start building trust with stakeholders with just a little bit of openness (and by making sure to not point fingers or cast blame) Honesty breeds more honesty — be as honest and transparent as possible! Mentioned in this Episode: Dark Scrum — Ron Jeffries Live AgileThought Community Event: “Agile Heard Around the World” with Special Guests — Oct. 29th Challenger: The Final Flight (2020 Series, Netflix)Theranos 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!
Joining Dan today is his colleague and collaborator, Sam Falco, to discuss whether or not Scrum Masters are expendable. Is it possible for things to be running so smoothly that you’re working yourself out of a job as a Scrum Master? Is there anything left for a Scrum Master to do once best practices become team culture, the team is self-sufficient, and the organization reaches a high level of performance? Why or why not should an organization keep a Scrum Master around? How does the role evolve over time? Tune in as Sam and Dan answer all of these questions and more on this week’s episode! Key Takeaways Can or should a Scrum Master be trying to “work themselves out of a job”? The idea that they can work themselves out of a job is an inherently flawed concept as it arises from the common misconception that they’re only a team coach A Scrum Master can always serve an organization (as there is no such thing as 100% perfection; the goal post is constantly moving/evolving) Sports analogy: If a team is doing really well, you don’t fire the coach! The same goes for Scrum (you still need the Scrum Master to keep the team and organization at a high-level and help finetune their performance) Why is a Scrum Master necessary? To help the team and organization continually improve (there is no ultimate level of performance) What is perfect now, may change — there is no pinnacle; there is always room for improvement If you reach a plateau, more experiments need to be conducted and other areas need to be examined Even if everything seems perfect, it is important to stay on top of things and continue retrospectives, etc. Qualities of a high-performing Scrum Master that delivers continuous improvement and value to the team and organization: Help the entire organization embrace empiricism in what it’s doing; not just team development Make decisions based on sound data (through transparency, inspection, and adaptation) Teach about empiricism with the Product Owner, finding better ways to refine the product backlog, experiments to run, etc. Help the whole organization improve; not just the team Value outcomes rather than output Make sure that the whole organization is living the Agile values and Scrum principles Help the team and organization resolve problems themselves and remove impediments Don’t trade efficiencies for throughput (a bit of slack in efficiency is actually beneficial for higher throughput) Know that in any complex endeavor, there are many variables and you will never get everything correct; situations always change, so be sure to not be overly optimized and be willing to adjust and adapt How does a Scrum Master’s role evolve over time? Through innovation, experimentation, and creating new best practices Always have something to do, reevaluate, and ask yourself, “How can I be of service? How can I help? What can I do that’s useful?” Look at the overall system and figure out hidden/less obvious impediments Always find opportunities to further optimize within an organization Always find new ways to deliver value Mentioned in this Episode: Live AgileThought Community Event: “Agile Heard Around the World” with Special Guests — Oct. 29th Peerfit Cynefin Framework The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning The Goal: A Process of Ongoing Improvement, by Eliyahu M. Goldratt and Jeff Cox Clean Language: Revealing Metaphors and Opening Minds, by Wendy Sullivan and Judy Rees Humble Inquiry: The Gentle Art of Asking Instead of Telling, by Edgar Schein 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!
Ed Buckley is the CEO of Peerfit, a company that creates a streamlined way for people to connect their health dollars with fitness experiences people actually want to use. When COVID-19 hit, the company underwent a large restructuring process. Because of the unknown nature of the virus, the company needed something that could provide structure but allowed for flexibility later down the road. This is why Ed decided to work with AgileThought and consultant Christy Erbeck. In this episode, both Ed and Christy share their 90-day reflections on how agile has worked for Peerfit and what it looks like when decisions are made within teams and not from a sole leader. Ed himself shares how this restructuring has freed him up to think about the future of the company and how the 90-plus employees within the organization are managing the agile framework. Key Takeaways How AgileThought and Agile are applied in a business setting. What gets you here doesn’t get you there. This year you were forced to take a different approach. Christy, as an outsider, had to come in and really take a top-down approach to see where there was a duplication of efforts and how to streamline Peerfit more effectively. Ed had to reduce his staff by a significant amount due to COVID-19, he was going to lose some key players and needed to adopt a more “fluid” approach in discussion making. When you empower your people, you move faster. Reflections on how Agile has helped Ed’s business Ed feels free and can choose what actions to be involved with vs. letting his team handle it. Ed now has the opportunity to look forward instead of being stuck in his business and being the central point for making all the company’s decisions. Before, the company had very cleared departments or silos. AKA, the sales team, the account management team, etc. Now, they have three North-star teams and each team is attached to one north-star goal. How Peerfit restructured their team It was a messy process trying to figure out who should be on what team. Some team members were afraid that if they weren’t put on the ‘right’ team, they didn’t feel part of the organization. It is definitely a work in progress. However, Ed set up slack channels to help address concerns and keep people within the organization informed on upcoming changes. Clear communication has been key to helping everyone feel at ease and understanding who is on what team. In the beginning, the AgileThought team gave Peerfit a couple of options that they could implement and the pros and cons of each one. Mentioned in this Episode: Peerfit.com Ed Buckley (LinkedIn) Christy Erbeck (LinkedIn) 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!
Dan is excited today to be joined by his guest, Simon Holzapfel. Simon is the founder and Executive Director of Copper Beech & Company, where they provide financial literacy for high net worth families. He is also an educator, agilist, and learning innovator. He has dedicated his entire adult life to equipping young adults with the knowledge and skills they require to work, think, and live well. In this episode, they will be exploring the topic of the Teal movement, Agile organizations, and education during the pandemic. Simon thoroughly explains what the Teal movement is, why it is important, and what it looks like when applied to a variety of organizations. He also shares about a unique project he is a part of and what they’re doing to bring authentic agile to the world. Key Takeaways What is the Teal movement? A reference narrative for how the world of work is, how it has evolved, and where it is going It is a navigation tool to understand how you can achieve the next level Laloux (the founder of the movement) proposes that there is a concentric circle to how organizations have developed over time Red: Command authority, division of labor, power, fear, and chaos (examples: street gangs, mafia, tribal militias) Yellow: Hierarchy, stability, control, formal roles, long-term perspective (examples: traditional churches, governments, public schools) Orange: Competition, accountability, meritocracy, objectives, profit (examples: public universities, large corporations) Green: Delight customers, shared values, engagement, stakeholder balance, culture over strategy, empower (examples: Ben & Jerry’s, Southwest Airlines) — This is where agility tends to live right now Teal: The next iteration of agility into antifragile organizations, built around higher purpose, self-management, distributed decision-making, wholeness, and evolutionary purpose Laloux is not saying other colors other than teal is bad; he is saying that all of the other colors are instrumental and getting to where we are now — but they’re cruft Laloux recommends, as a society, we shed these other colors as best as we can Recommended further reading: Reinventing Organizations, by Frédéric Laloux Where this movement connects to different organizations: Teal education: Students are encouraged to ‘pull’ information into their lives rather than be pushed into learning (Examples: eduScrum, Montessori education) Teal manufacturing: self-organization, teams pulling in work (as opposed to work being pushed on to them), and bringing your whole self to work (Examples: Morning Star, Buurtzorg) What Teal organizations look like/involve: A healthy bottom line They are incredibly efficient at generating value Employees are far more productive because they are listened to, encouraged, and engaged They foster more active engagement which, in turn, creates better results and outcomes It’s not about no rules or no structures; it is simply a different set of principles (by and large, the agile mindset) Involves intent-based leadership Trust is incredibly important — without it, everything will fall apart Everything is visible and transparent (visibility is the trust builder) The leaders or teachers create a feedback-rich environment so that the employees/students can learn quickly About the BU Agile Innovation Lab: The goal: Bring authentic agile to the world (including college students by meeting them where they are with the interests that they have) They want to complement schools and not compete with them They are striving to create a more open ‘meta’ that creates more equity Authentic agility + trying to introduce more Teal structures Mentioned in this Episode: Simon Holzapfel’s LinkedIn Teal Model (Image) Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness, by Frédéric Laloux Boston University Agile Innovation Lab: Agile in Education Conference (Oct. 23rd–24th) Morning Star Buurtzorg Montessori Education Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David Marquet Willy Wijnands | eduScrum 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 co-host and collaborator, Sam Falco, to discuss the topic of professional Scrum. What does professional Scrum refer to? What is professionalism? What does a professional Scrum Master look like? What does it look like to practice Scrum professionally through principles and values laid out in The Scrum Guide? What does professionalism look like on a Scrum team? Sam and Dan answer all of these questions and more in this episode! Key Takeaways What does professional Scrum refer to? Ken Schwaber’s definition: “A professional is someone who works for money and follows the rules established for the profession. Professionals act and work according to standards where they exist. They also embrace and embody a set of ethical principles established by their profession.” Adhering to the rules set forth in The Scrum Guide The Scrum values fulfill the role of the “ethical principles” in the software development industry A mindset of professionalism and a commitment to a certain set of standards An emphasis on communication and empathy between business and development (so that you can ensure that you are delivering what the customer actually wants and can use) Professionalism includes really understanding why you’re doing the things that you are doing Examples of professionalism: If you are shooting to release a product to end customers by a certain date, how do you use the Scrum events, the sprint planning, the daily Scrum, and the sprint review within the sprint timebox to make sure that you’re on track? In the sprint review, identify which adjustments and decisions are needed, and iterate Important notes about doing Scrum professionally through The Scrum Guide: It’s not just about having the roles, artifacts, and events in place; you also need to be cognizant of the rules that bind these three things together Commit each sprint (as a team) to a goal, not a scope When a sprint goal is a laundry list of things to do it can become overwhelming — it is much better to commit to a goal and negotiate your scope as you go throughout the sprint Focus on delivering on the goal; delivering on the value It is important that the organization gives the Scrum team(s) space to be professional “Professionalism is not just for the Scrum team, just as the Scrum values are not just for the Scrum team; they’re for the organization to live and make space for.” The responsibilities of a professional Scrum Master: They are responsible for coaching the Product Owner, the team, and the organization on how to use Scrum in an effective way The Scrum Master should not be a glorified administrator The Scrum Master should be working with the entire organization to help it achieve business agility and valuable outcomes rather than just lots and lots of output Look for ways in which the organization is inhibiting your team’s further growth and success Look for the areas and opportunities in the organization for further agility Aspects of professionalism on a Scrum team: Strong collaboration (i.e. the Product Owner and the team need to collaborate, and the Scrum Master needs to collaborate with the team, the Product Owner, and the organization) “What does it mean to be a professional Scrum developer?” It’s more than “I’ve got my work done” The team should not be working siloed At the daily Scrum, the team should be collaborating on the most effective thing to do that day to get closer to the sprint goal, figure out who needs help, and understand who’s doing what Toward the end of the sprint when development work is winding down, it is important that developers are helping the test activities happen “The development team is not just the people that are writing the code; it’s all of the people on the Scrum team that are needed to deliver that increment, aside from the Product Owner and the Scrum Master.” It is important to find the balance between being a “busybody” and being a “T-shaped person” A healthy team spirit is vital Reduncies in skill sets of team members are incredibly valuable Being open to learning new things beyond your expertise and having the intellectual curiosity to step outside of your role makes for a healthy, well-rounded team Mentioned in this Episode: The lawsuit between Scrum Alliance and Scrum Inc. Scrum Alliance Scrum Inc. Ken Schwaber Mastering Professional Scrum: A Practitioner’s Guide to Overcoming Challenges and Maximizing the Benefits of Agility, by Stephanie Ockerman and Simon Reindl The Scrum Guide Arcade Perfect: How Pac-Man, Mortal Kombat, and Other Coin-Op Classics Invaded the Living Room, by David L. Craddock and Milan Jaram Eric Landes 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!
We have a special repeat guest on this week’s episode! It’s Barry Matheney. He is a Senior DevOps Consultant and one of Dan’s colleagues at AgileThought. Get our Download Would you benefit from a DevOps Coach? So often, teams operate on a “get it done” model and try to push their code out the door as quickly as possible, but that is not sustainable and not the markings of a high-class professional team. Barry understands the Scrum Teams’ main mission and purpose is often very wrong; it’s to appease the product owner, not create purposeful and meaningful end-results. In this week’s episode, Barry shares his thoughts on when it’s time to hire a DevOps coach for an organization, some of the troubles organizations run into (problems with easy fixes!) when it comes to their Scrum Teams, and when you know when your team is on the right track in their DevOps journey. Key Takeaways What’s the working definition of DevOps? It’s about delivering better value, sooner, safer, and happier. The difference between Agile and DevOps’s motto is the definition of what “done” truly means. True North for DevOps means there are a continuous delivery and a continuous deployment. If you have some DevOps influence in what you’re doing, you’re on the right track. What are the best ways a Scrum Team can get started? Typically, when a Scrum Team gets started, the sole focus tends to be delivery of stories. AKA, making the product owner happy. Most product owners don’t care about dashboards or reliability. However, they should. The scope of a product owner should include the production world, as well. When do you need a DevOps coach? It’s a tough answer. It depends on the team composition. If you have a junior team, they won’t have the experience to know the consequences of bad code. The journey begins as soon as you begin production. You build resiliency by delivering something that cannot fail, something that was built to last. That takes planning and continuous development. Junior teams might not be thinking in these terms just yet. How do you know when you should be leveraging DevOps? What times do your deployments occur? If you deploy them during off-hours, then something is wrong. Deployments should be normal working events and not interruptions to your life. Do your organization’s security teams always seem to be diving into your business? You can provide compliance and proof to your security teams you’re on the right track and have thought about all the possible security risks. Anything that happens should be logged. You don’t need to manually tinker in production. Software teams want to get things out the door, but that’s not operating at a professional level. The transformation is not about your scrum team. It is an organizational transformation. What’s the distinction between an Agile coach vs. a DevOps coach? Agile coaches plant the ideas. DevOps coaches can help build the prototypes together and experiment with different theories. DevOps coaches give a continuous approach and re-examine practices that were put into place 10 years ago that may not be relevant now. DevOps is an organizational challenge, not necessarily a team challenge. Waste is bad, so you need to either scrap the project or get it into production. Remember, DevOps is a journey. Mentioned in this Episode: Would you benefit from a DevOps Coach? free download AgileThought Event: “Virtual Community: Building an Agile Mindset During COVID-19” Barry Matheney (LinkedIn) Podcast Ep. 17: “Embedding DevOps in Large Organizations, with Barry Matheney” Podcast Ep. 12: “The Importance of Embedding a DevOps Skill Set into Your Team” Greenfield Project Podcast Ep. 4: “Setting Up Working Agreements with Christy Erbeck”Strangler Pattern Podcast Ep. 2: “What is a Full-Cycle Developer?” 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 today’s episode, Dan Neumann is joined by AgileThought’s Managing Director of the Run Practice, Daniel Novelo! In his role, Daniel is in charge of defining the vision and strategic direction of the Cloud & Managed Services Portfolio at AgileThought, by understanding the market trends, designing the Digital Products & Services that our customers require, and by delivering the revenue and profit that AgileThought budgets. He also designs, coordinates, and executes business plans with AgileThought’s Partners, Sales, and Delivery Teams to achieve its yearly objectives. In their conversation today, Daniel speaks about his role as Managing Director of the Run Practice at AgileThought, explains what the Run Practice is, and shares about the different ways that organizations have started down their path to Cloud adoption. He also addresses some of the possible risks associated with migrating to the Cloud, how to mitigate these risks, the benefits and opportunities the Cloud opens up, and how AgileThought works with companies in migrating to the Cloud or optimizing their Cloud usage. Key Takeaways What is the Run Practice? What does it do? It delivers value to customers by providing Cloud & Managed Services and outsourcing the IT operations of its customers (with a modern approach and a mission-critical mindset) They complement the portfolio of AgileThought’s transform, build, and run by operating and maintaining software, applications, and the underlying infrastructure in production environments There are dedicated teams to review the cost and complexity of their customers to operate their systems They accelerate the adoption of the Cloud with a set of services that go from the strategic aspects (like Cloud design, Cloud foundation, & assessments) to building strategies and performing the migrations to the Cloud for their customers Once their customers are in the Cloud, they help modernize their business applications for optimal Cloud performance Why Cloud adoption is becoming increasingly popular and why companies want to migrate to it: It’s important to understand the reasons behind why some companies are adopting Clouds as well as the challenges and implications companies can face dependent on the type of workload they want to bring to the Cloud It’s nearly impossible to find an organization that doesn’t at least partially rely on Cloud services (especially now, during the pandemic, is it becoming more popular than ever) Modern workplace platforms are really encouraging the use their Cloud versions The adoption of Cloud services has been key in accelerating the migration of enterprise workloads to the Cloud Enterprise workloads show that Cloud Storage is the most widely adopted You can easily scale up the Cloud Storage within minutes and then scale it down when needed A Cloud Database setup empowers distributed teams because the team members working remotely can conveniently access data through the internet to perform their tasks Publishing your dev and test environments to the Cloud is also becoming increasingly popular Bringing environments to the Cloud gives the ability to use only what you need when you need it Cloud technology can be a massive enabler for Agile teams (as you are able to spin up an environment, do the deploy, do the validation, and tear it all down once it’s done) Analytics and big data are huge drivers for the Cloud (because when the data resides in the Cloud it’s easier to locate it, consume it, and to embed it into analytic solutions) Daniel on Cloud risks and security: Having partners who can walk organizations through an adoption/sticking their toes into the waters of the Cloud is very helpful in showing how secure it is More than 90% of Cloud breaches are at the user’s fault Possible security risks: loss of data (passwords, banking information, intellectual property, and other sensitive data), exposing confidential information (that leads to regulatory or legal actions against an enterprise), malware and ransom attacks, an employee who has left the company still having access to files and information (however, there are tools to mitigate and control this access) Many risks can be mitigated through tools that can secure confidential documents in real-time Tools and systems that are lagging behind in Cloud adoption: A lot of companies that still rely on legacy systems (but there are strategies to migrate these companies to the Cloud [though additional scaffolding may be necessary]) Implementing APIs (and securing them) can be a way to bring a legacy system to the Cloud How AgileThought works with companies that are new to the Cloud: Customers should first perform a Cloud readiness assessment for their application and infrastructure It is helpful to make an inventory of all of the assets within the company and identify which of them are supported in the Cloud and which need an upgrade The assessment will also help map dependencies to understand the interfaces between all of the customer’s systems, which is key for developing a Cloud strategy Time and effort should be invested into designing a desired state/a landing zone in applying the architecture best practices AgileThought helps their customer establish their Cloud foundation and makes sure to include all of the security and compliance requirements After this, AgileThought helps the customer build their rational decision map (figuring out the path forward, “bucket by bucket”) AgileThought helps the customer identify which applications they want to modernize or refactor so that they really capture the benefits of the Cloud Mentioned in this Episode: AgileThought Event: “Virtual Community: Building an Agile Mindset During COVID-19” Daniel Novelo’s LinkedIn Amazon Web Services (AWS) Microsoft Cloud Dropbox iCloud 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!
Joining Dan Neumann once again is Dr. Jerry Smith who you may remember from a bonus episode of the Agile Coaches’ Corner a few weeks back! Dr. Jerry Smith is AgileThought’s Managing Director of Analytics and Data Science. As a practicing AI & Data Scientist, thought leader, innovator, speaker, author, and philanthropist, Dr.Jerry Smith is dedicated to advancing and transforming businesses through evolutionary computing, enterprise AI and data sciences, machine learning, and causality. In this episode, Dan and Dr. Jerry Smith explore the topic of digital transformations. Jerry takes listeners through what the process of a six-step AI-driven digital transformation process looks like, the challenges of the process, as well as the key benefits. Key Takeaways What is a digital transformation? Changing the behavior of the organization in relation to their customers Changing their journey map so that they can achieve the business outcomes they want Looks at changing the behaviors to create new opportunities It is not ‘transforming digitally’ (i.e. moving to the Cloud, etc.) — the order of words is important to note AgileThought’s AI-driven digital transformation: It is a six-step process that gets a business to actually bend their business curve It is implemented in a set of capabilities; there are over 67 capabilities that transition an enterprise’s data and transform it into insights and actions and is a systematic process This process puts a customer into the position of changing their business The six-step AI-driven digital transformation process: (1) ‘Data is the debris of human activity. We collect it all, but all is not important.’ The first thing that is done is data collection The most important question to ask when you begin is: “What is data?” Data is because of us; not in spite of us (2) ‘We determine what data is causal to the business problem. This allows us to only focus on those areas we can control.’ You need to ask: “Of all this data we collect, what is causal to my business problem? What should I be focusing on?” (3) ‘Using causal data, we build digital twins — surrogates — of the problem. We create an artificial model of the real world.’ They build high-quality, predictive algorithms (from step two’s causal data/input) Changing this data changes the business outcome (4) ‘Within the artificial world, we organically grow perspective solutions designed to optimize the business outcome.’ Now that you have the model it is important to optimize the digital surrogate (5) ‘We implement the prescriptive solutions, wait for change, and collect new data.’ In this step, you are running through optimization, changing those inputs, and looking for a combination that results in that output achieving the business goal (6) ‘The cycle repeats, bending the business curve.’ When you have the behavior of the people that marketing, sales, and product development will have to change, you can then wash, rinse, and repeat When you go through the six-step process in cycles you need to give enough time to see the ripples go through to see the changes and continue to iterate and refine “This is why this six-step process is important for customers; because for the first time we’ve actually connected business and IT together.” — Dr. Jerry Smith Mentioned in this Episode: Agile Coaches’ Corner Bonus Podcast: “How to Make AI Work in Your Enterprise with Dr. Jerry Smith” AgileThought Event: “Virtual Community: Building an Agile Mindset During COVID-19” Six-Step AI-Driven Digital Transformation (Image) 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!
On this week’s ‘solocast’ of the Agile Coaches’ Corner, Dan Neumann wants to talk a little bit about words and phrases! If you had a magic wand and could change any word or phrase in relation to Scrum and agility, what would it be? In this episode, Dan shares the four words and phrases that he would change for all Scrum teams — and, if it were possible, why he would like to see them go away, altogether! Key Takeaways Resources vs. People Don’t confuse the people on your team with resources If you mean ‘people,’ say ‘people’; don’t say ‘resources’ You consume resources (i.e. time is a resource that you can use to achieve goals) Commitment vs. Forecast Commitments are something you keep, come hell or high water When we’re dealing with a lot of uncertainty, a more appropriate term to use would be ‘forecast’ rather than a commitment When you’re dealing with your Scrum teams, make sure that ‘commit’ is a term that is held back; think more in terms of forecasts (and especially forecasts with a probability of when you will be able to deliver, such as: ‘We forecast with 90% confidence’) Grooming vs. Refining Grooming is something you do to a dog; a more appropriate term for what you want to do to your product backlog in the Scrum world would be to ‘refine’ it Think of ‘refining’ as the removal of things that are impure or low value “Your product backlog [is] not a dog; don’t groom it!” Deadlines vs. Goals & Targets Deadlines traditionally refer to drawing a line in the sand (and if you cross said line, you’re dead) — which isn’t a very motivating term nowadays! More appropriate terms would be: goals and targets “We have a target of releasing the new product on January 1st.” With targets, you can introduce the concept of a ‘cost of delay,’ when you miss a target date Having goals and targets with specific dates coupled with a ‘cost of delay’ will allow you to make much more informed decisions about how to prioritize work Mentioned in this Episode: Top 30 Agile Leadership Podcasts To Follow in 2020 Agile Coaches’ Corner Bonus Podcast: “How to Make AI Work in Your Enterprise with Dr. Jerry Smith” 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 bonus episode of the Agile Coaches’ Corner podcast, Christy Erbeck, Chief People Officer at AgileThought, is serving as your guest host for today’s conversation with Steven Granese and Quincy Jordan. Steven Granese is the Managing Director of AgileThought’s Transform Practice and Quincy Jordan serves as the Agile Competency Lead and Principal Transformation Consultant at AgileThought. In their conversation today, they discuss scaling and transformations and how to effectively lead organizations towards business agility. They speak about the role of scaling in transformations, the challenges of scaling, opportunities that arise as an organization begins to scale, how to know when it is appropriate to help a client scale, and how to know when you’re on the right path with a transformation. Key Takeaways Transformation & scaling: Part of a transformation is in transforming how people think There are a number of ways to scale Though it is called “scaling,” oftentimes it is about breaking down the problem into smaller pieces (especially in organizations that are already large) A real transformation is an organizational transformation throughout all departments The long term goal is to achieve business agility Tips for getting clients started on their scaling or transformation journey: Break down the problem into more manageable pieces in order to be able to take action on them and deliver faster (by delivering faster in these smaller increments you are setting expectations with stakeholders, which increases transparency and creates an outcome of more trust) Buy-in is needed from leaders Make sure to employ roadmaps with clients which can help with expectations Clarity and guidance alleviate stress during the scaling process Leaders need to address problems upfront when it comes to adopting agile Asking the question “why” is critical for transformations; it has to be answered first (especially if you’re looking at a true transformation) “Why are you doing this?” “What is it that you’re trying to change?” “Why are you trying to change?” “Are you confronting real organizational challenges and problems that you have?” Knowing what your client wants to focus on fundamentally changes how you work with them Note: A true transformation will take time (sometimes years) and oftentimes, things will get worse before they get better Differences between the two modes of adopting agile: Delivery and Transformation: Ask: If you’re interested in adopting an agile way of working, are you focused on improving your delivery OR do you want a transformation (i.e. change the way your business fundamentally operates)? Knowing which your client wants to do is critical If your client just wants to improve their process and doesn’t believe anything is broken, they just want to improve their delivery There is no right or wrong answer, but it is important to clarify what outcome they’re looking for as it will greatly impact how you help them If a client wants 10–20% better output for their teams they’re looking at improving delivery If a client wants to fundamentally look at the way their business operates, the types of customers they’re going after, the way their teams are structured, their financial incentives, etc. they are looking at a transformation It’s important to determine when a client wants to achieve certain outcomes so you know whether to focus on improving delivery first vs. long-term transformation (that will lead to better delivery down the line) Benefits of an agile transformation/achieving true business agility: Being nimble, adaptable, and being able to react quickly to changes and demands from customers or the business With the right culture and infrastructure in place, an organization is able to move very quickly when an unknown market shift happens (such as with COVID-19) A true agile transformation allows an organization to be in a position that can weather any storm Allows for better reactions to the unknown True business agility helps the business be adaptable Tips for leaders during a transformation: Encourage the ability to learn, relearn, and unlearn — this is critical because companies may get stuck in their past successes, which limits their ability to learn new things and/or do things in a new way Be courageous and vulnerable Be a learner, not a knower Continuously adapt and learn Have a growth mindset in order to be able to help your people Leaders need to ask themselves: “Am I clear as to where I’m going in the future?”, “Do I know why I’m trying to get there?”, and “Can I deliver in small increments and learn from the feedback?” Have humility in understanding that everything can change in a second — so the ability to learn, unlearn, and relearn is critical (if you don’t, your business will become vulnerable to competitors) Mentioned in this Episode: Christy Erbeck’s LinkedIn Quincy Jordan’s LinkedIn Steven Granese’s LinkedIn What Got You Here Won’t Get You There: How Successful People Become Even More Successful, by Marshall Goldsmith Unlearn: Let Go of Past Success to Achieve Extraordinary Results, by Barry O’Reilly Start with Why: How Great Leaders Inspire Everyone to Take Action, by Simon Sinek The Agile of Agile: How Smart Companies Are Transforming the Way Work Gets Done. by Stephen Denning 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, Dan Neumann is joined by AgileThought colleague and frequent guest of the show, Quincy Jordan. Quincy has been with AgileThought for just over two years as a principal transformation consultant and agile competency lead. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. He has also served as a principal consultant and agile coach at SCRUMstudy.com for over six years. In their discussion today, Dan and Quincy explore the topic of culture as related to agile transformations. They define what culture is, why it is important, how it factors into agile transformations, and how to begin addressing it as an organization. Quincy also shares how to become more intentional about addressing culture early on as the company is moving toward a more agile way of working, the outcomes of being unintentional about addressing culture challenges, and additional tips and takeaways that are critical to keeping in mind when addressing culture. Key Takeaways What does ‘culture’ refer to? A combination of the values, habits, and norms within a group or organization The values that are present in everything that your organization does It applies to any organization (whether it’s a religious institution, your family unit, company, etc.) Can be characterized as “The way things happen around here” or “How we do things around here” Quincy’s advice regarding how culture factors into agile transformations: Culture cannot come last; if you want the ‘machine to run well’ and address the culture after, you have created a culture that says, “The machine is more important than the culture” If a specific habit, such as courage, is not encouraged, you are building cultural debt; i.e., it will become more and more difficult for courage to be expressed It is important to be intentional about culture upfront and incorporate it into your transformation as part of your strategy If you don’t want certain habits to be a part of the culture, you have to intentionally set a new structure for everyone to transition to (otherwise it will continue to be pervasive) Outcomes of being unintentional about addressing culture challenges: If you’re not intentional about the culture and you develop a culture by default, it is likely to be riddled with cultural debt If you don’t address having the proper culture that you want up front, you are going to have a mismatch of what you currently have and what it is that you really want If the team/s are checklist-driven then they won’t have the opportunity to help the culture be values-driven How to be more intentional about addressing culture early on as the company is moving toward a more agile way of working: Ask: “Are we involving the teams in the actual planning or are they being given plans and milestones that they’re expected to hit without participating in the creation of those plans?” Ask: “Is our culture checklist-driven rather than values-driven?” The team/s should be involved in understanding what’s drawing value so they can better help accomplish the work that needs to be done for the values to be there Set the culture upfront Figure out the things that you are and are not aligned to as an organization Decide on where the values lie and what they would be (ask individuals and teams: “What are the things that we value?”) Have teams and individuals fill in the blank: “It really agitates me when _________.” It helps make clear what things affect their value system Do a team working agreement where you establish what the values are Once you establish what the values are, ask: “How can we act on these values?” and “What are the things that we can do, day-in and day-out, to express that those are our values?” For example, if the value is: “Everyone has a voice,” then you need to provide opportunities for individuals to have their voice heard Additional culture tips and takeaways: You need to be intentional and know what your values are so that you can drive towards them (and be intentional about not allowing those values to be encroached upon) If you address culture upfront, then you’re putting the organization in a position where you’re helping to impact the decision-making Addressing the culture upfront helps the organization work towards their overall vision It is important to have people within the organization that are carrying the culture forward so that when others are unsure/confused, they can look to those people Mentioned in this Episode: The Reengineering Alternative, by William E. Schneider Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr Science of Running: Analyze your Technique, Prevent Injury, Revolutionize your Training, by Chris Napier 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 bonus episode of the Agile Coaches’ Corner podcast, Christy Erbeck, the Chief People Officer at AgileThought, is serving as your guest host for today’s conversation with Dr. Jerry Smith. Dr. Jerry Smith is AgileThought’s Managing Director of Analytics and Data Science. As a practicing AI & Data Scientist, thought leader, innovator, speaker, author, and philanthropist, Dr.Jerry Smith is dedicated to advancing and transforming businesses through evolutionary computing, enterprise AI and data sciences, machine learning, and causality. In their conversation today, they discuss how to make AI work for your enterprise. Dr. Jerry Smith explains why understanding causality is critical for AI-driven business transformation and how data science and analytics can help enterprise clients transform and become the digital winners that they desire to be. Key Takeaways How AgileThought aids enterprises in understanding AI-driven business transformation: Come up with a working set of definitions for AI, machine learning, and data sciences AgileThought helps companies institutionalize data science, machine learning, and AI at the enterprise level by breaking down the process (as shown below) so that each and every process resides in infrastructure and a set of capabilities There are three kinds of data: your enterprise, your IT, and your opensource — the goal is to get this data into a single machine learning record This single machine learning record is critical in showing all of the variables in columns and observations in rows — from there, you can do basic analytics, and then, data science Data scientists make sense of the data and create models out of the data so the data no longer has to be used In the machine learning phase, data scientists try to predict what these models are trying to do and how they’re going to change under certain variables Note: AI is about prescriptions; making decisions Note: The biggest value is not in generating or reading reports; it is in making an appropriate decision based on these reports How AgileThought helps their enterprise clients solve their problems: The question: ‘What is data?’ should be asked (Dr. Jerry Smith’s answer: ‘Data is the debris of human activity; it’s because of us, not in spite of us’) Note: Data is not just spontaneously created in your data systems; it’s created from an application which captures an interaction between a human being (you, your customers, or your admins/salespeople) and that system Note: The data we see is because of human actions When we look at our capabilities, we should be asking the fundamental question: ‘What data in our enterprise is causal to our business outcomes?’ For example, ask: ‘What data that you have spent time collecting is directly causing your revenue to perform the way it does?’ The very first thing to ask is: ‘What’s causal?’ Once you know the causal data, you can go back to the application and the human and say, ‘How do I change the human behavior so that the application picks up the new behavior and changes the data?’ This result is causal-based data engineering for AI and is the only way to change your organization 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, Professional Scrum Trainer Eric Landes addresses the questions: "How do you measure a Scrum Team's Performance?" What Does the Scrum Guide say About Measuring Performance? In many of our Scrum classes, the issue of measuring performance is asked about how can we measure a Scrum team's performance. It is a good question that the Scrum guide does give some information on the guide states that one of the inputs of Sprint planning is past performance of the development team. It also States that the daily Scrum optimizes team collaboration and performance by inspecting work. In these two statements, we learn that Scrum does want to help optimize team's performance. So how do we measure that though? When we go back to our question, let's talk about why we should measure a Scrum team's performance as the Scrum Guide mentions, we do need that as an input to Sprint planning. Velocity is not the Best Measure For this input, many teams use a velocity chart. A team's velocity chart to understand past performance. And this is a complimentary practice to Scrum. It's not actually asked for in the Scrum Guide or prescribed. But it is one well-established way to measure performance along with Sprint burndown charts and release burndown charts. I find that velocity may not be the best measure. Use Kanban Metrics to Measure and Forecast If this question is more about helping the team understand and communicate delivery performance, there are tools like cumulative flow charts and throughput that could be used. These metrics come from a Kanban perspective and these tools help teams understand their flow and can be used to communicate forecasts. For instance, your team may have a throughput of one PBI done each day. Just as an example, as a for instance, while using the past metrics are never one hundred percent accurate. It can help teams as they go into Sprint planning and Kanban even gives you a forecasting method called Monte Carlo simulations that can help with this. Now this is a complex topic for sure, but the main purpose of this Trainer Talk is to introduce you to concepts beyond team velocity charts, and burndown charts. Many Kanban metrics can be used to help teams understand their delivery capabilities better and achieve a flow that many mature teams are hallmarks of many mature teams. Scrum.org even has a class called Professional Scrum with Kanban that teaches participants to get to that flow and to help measure that flow. Find What Works for Your Team If you are interested in different ways to measure a Scrum team's performance, I urge you to check out some of these other metrics. There is no one size fits all. So, make sure it works for your team and self-organize around the way your team measures performance. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
In today’s ‘solocast’ of the Agile Coaches’ Corner, Dan Neumann is exploring the art of metaphors. Metaphors can be a powerful tool to illustrate important ideas and concepts of agility — if used well. Dan shares the pros and cons of using metaphors in an agile setting, how to use them effectively whatever your role may be, and how metaphors can be a really powerful tool to add to your arsenal, regardless of what level you’re at in the organization and who you’re trying to communicate with. Key Takeaways What is a metaphor? A metaphor is a way of using a concrete image/example to help connect to an abstract thought Taking an abstract idea like agility and then comparing it to something that is very concrete Metaphors help us connect abstract things to familiar ideas Examples: “All the world is a stage.” — Shakespeare, “Life is like a box of chocolates.” — Forrest Gump What to keep in mind when using metaphors: Be aware that we can sometimes bring in biases and/or unintended constraints that are not helpful Using a metaphor may impact the way a person is looking to solve a problem The way in which a metaphor is used is going to affect the way that someone is going to think about different problems Common (and not-so-common) agility metaphors: An 8-hour endurance race (where the goal is to see how many miles you can go in a set amount of time) can be compared to an agile software development project Building a car as compared to product development (the metaphor of construction helps to connect the thought of agility with regard to transportation) Agile gardening vs. Agile farming (illustrates the contextual differences when you’re doing small-scale agility [the gardening] vs. commercial, industrial-scale agility [farming]) Sailboat (a metaphor technique used in retrospectives): i.e. “What are the fair winds that are blowing your boat across the water?” and “What are the anchors?” (i.e. what is keeping your boat moving forward to its destination) Metaphors can also be used to show where agility does not make sense (i.e. you don’t exactly want a McDonald’s lineworker being agile when they’re making your burger; you want the same burger every time you go there) House metaphors: “If you’re building a house you have to build a solid foundation” and “You wouldn’t build a house one room at a time” (these can be good for user stories as well as illustrating the desire for pre-planning) Pros Metaphors are powerful in that they cause the brain to react differently Metaphors can help teams move away from a really concrete way of thinking about a problem to a much more abstract way, unlocking some new potential There are lots of different ways of using metaphors to help connect people to this abstract concept of agility Cons An issue with metaphors is that they can sometimes be militaristic (i.e. using military metaphors, such as those seen in Team of Teams) Some metaphors bring in gender biases (i.e. “don’t get your panties in a twist”) — this baggage is not appropriate and brings in stereotypes Metaphors about games and sports (because agility isn’t a win/lose scenario) Art metaphors — not everyone will be able to relate to the message (it’s important to be aware of your audience) Imagining your team as a machine in a metaphor can bring in some constraints you don’t necessarily want Mentioned in this Episode: “How the brain finds meaning in metaphor,” ScienceDaily “Through Their Own Words: Towards a New Understanding of Leadership Through Metaphors” “Why Metaphors Are Important: Metaphors are not just a literary technique; they are a psychological technique” “The Power of Metaphors in Communication” Team of Teams: New Rules of Engagement for a Complex World, by Stanley McChrystal with Chris Fussell, Tantum Collins, and David Silverman 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, Dan Neumann is joined by not one — but two! — AgileThought Colleagues; Quincy Jordan and Christy Erbeck! In their conversation today, Dan, Quincy, and Christy discuss the key qualities to look for when bringing a new Scrum Master into your organization. They discuss the important characteristics you should be on the lookout for, the key skillsets, important soft skills, and some of the qualifiers (and disqualifiers!). They also share what to pay attention to when hiring, red flags to watch out for, and insightful questions you can ask during the interview process to make sure they’re a good fit. Key Takeaways What to consider when beginning to look for a Scrum Master: Key characteristics Skillsets Soft skills Qualifiers and disqualifiers Good qualities: Humbleness — they focus on the betterment of the team rather than shining the limelight on themselves They are a servant leader A capacity to focus on the strengths of others A good balance of leadership and humility Open to feedback They have a growth mindset They are a learner; not a knower They come from a place of curiosity vs. judgment What to pay attention to when hiring: They understand the five Scrum values Mastery of the Scrum guide They are staying up-to-date on the Scrum framework They purposefully model the behaviors and values of Scrum Listen to how they use their words; i.e. are they phrasing from a competitive standpoint or a collaborative standpoint? Are they phrasing from a comparative standpoint or an inclusion standpoint? They should have stories and anecdotes of how they have applied the Scrum guide in real life They should take on the role of a Maestro rather than a ‘Master’ In the interview process, identify how they apply values, think through problems, and how they recover and ‘rise strong’ from a failure If they don’t have any certifications, inquire why that is and how they have self-taught If they do have certifications, ask when they received them and what they have done with them since Ask how they are participating in the agile community in their area Disqualifiers: Humility to the point where they are not actually leading anything Having too much knowledge and have a hard time pulling their weight from their own experience/knowledge and not allow the team to determine the ‘how’ for themselves They are not open to self-evaluation or evaluation from others They have a fixed mindset They are a knower; not a learner Misconceptions: Do not assume that you can take all of your project managers and turn them into Scrum Masters “We need a very technical person to be a Scrum Master” — untrue; in many cases, a less technical person makes a better Scrum Master 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!
Today on the podcast, Dan Neumann and Christy Erbeck are discussing how to lead in times of crisis and come out of it stronger than ever. As a leader, it is critically important to take care of yourself during crises to be able to lead others through them, as well. In this episode, Christy shares her tips for leading through crisis, key strategies leaders can begin to implement, and how to cultivate a healthy work environment for everyone involved. Key Takeaways Christy’s tips for leaders, leading in a time of crisis: Use it as a time to reflect on where you are now and where you want to be on the other side of it all Take time to process your emotions and lead from a place of truth Lead by example; take care of yourself and work at a sustainable pace while encouraging the rest of the team Transparency is key — be transparent about where you are, as a team, as an organization, and in relation to the difficult decisions you’ve had to make to survive the crisis (transparency offers the opportunity for growth and building trust within the organization) Understand your audience in your approach with being transparent; it is important to care for the person receiving the information Going hand-in-hand with transparency, it is also critical to communicate (and the need for communication exponentially rises, the greater the crisis) Meaningful, intentional communication and on-going dialogue between the employee and the leader (or the team and the team members) is critically important for minimizing the stories they may be telling themselves when there is a gap in communication or lack of communication Connect in a meaningful way with your employees vs. walking away or being silent Authenticity is critically important in leading through a crisis — it’s not about what you know; it’s about what you’re willing to learn Do not defer taking action until the last possible moment How to come out of a crisis stronger than ever with your team: Delegate decision-making and allow other people to make decisions within a framework Take pragmatic action Ensure you are still meeting and talking about your longer-term strategy beyond COVID-19 Examine how to position your organization so that when you come out on the other side of COVID-19 you are attractive to the marketplace and your customers Leverage OKRs Apply an experimental mindset and conduct experiments (one way you could do this is to utilize Kanban boards) Implement empirical process control Cultivate a culture steeped in trust and forgiveness Continual planning Reach out to others as a leader so that you’re not making decisions in a vacuum and are leveraging other people’s expertise Imagine what the leader that you most respect would do; how would they handle this situation? And how can you tap into this person’s expertise? Make the time to reflect and gain perspective Be courageous as a leader by being vulnerable Mentioned in this Episode: The Dave Ramsey Show Brené Brown “A Guide to OKRs,” KOAN Agile Coaches’ Corner Ep. 5: “Exploring an Experimental Mindset with Adam Ulery” “What is a Kanban Board?” Small Business Administration (SBA) SCORE — Service Corps of Retired Executives Gartner The Conference Board Harvard Business Review “Microsoft Analyzed Data on its Newly Remote Workforce,” Harvard Business Review “Managing When the Future is Unclear,” Harvard Business Review “Leadership in Times of Crisis,” American Psychological Association “How to Survive a Recession and Thrive Afterward,” Harvard Business Review “The Downside of Flex Time,” Harvard Business Review “The Reopening Challenge: 5 Tips for Getting Back to Business,” Inc. “COVID-19 is Reshaping Business: 6 Tips for Coming Back Even Stronger,” Forbes 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, Professional Scrum Trainer Eric Landes addresses the questions: "Will the Professional Scrum Master Certification help me get a job as a Scrum Master?" The Professional Scrum Master certification Bolsters your Credentials Of course there is no guarantee of a job with a certification, but I believe it helps you have the intelligent conversations around scrum when you have the background from passing a certification in the Scrum framework. If you are already working in IT, one way to do bolster your chances for a job would be to take the class and go for the certification. Then in your current job, use Scrum with your team, at any opportunity you have. Get Experience in the Scrum Master Role If you can volunteer for other teams within your organization. This will help you get experience with the concepts. Then you are positioned to be a Scrum Master in your current organization should the opportunity present itself. Having the certification helps, and get as much experience as you can as you attempt to become a full time scrum master. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
This week, Dan Neumann is joined by his AgileThought Colleague, Quincy Jordan! In their conversation today, Dan and Quincy are diving into the world of online videogames — specifically Fortnite; the popular battle royale, sandbox game — and drawing comparisons between it and agility. Having watched his son play Fortnite over the summer, Quincy saw how he remotely communicated with his friends online to come together as a team, seek out an objective, collaborate, and go after that goal. In this episode, Quincy not only highlights many of the similarities between online gaming and having an agile mindset, but he also shares some of what we (and our kids) can learn from playing these sorts of games and further improve our agility. Key Takeaways The overlap between an agile mindset and Fortnite/other online games: In the game, you play in teams and the players coordinate and collaborate remotely through headsets In both agile teams and Fortnite, you need to come together as a team, seek out an objective, collaborate, and go after that goal In the game, you gather raw materials and architect right on the spot to create structures such as barriers or ramps (similar to the agile concept of solving problems with the resources you have at your disposal) They do team working agreements (i.e. before they start, they set out their goals and agree on what they’re trying to achieve) When their objective is at risk of reaching its goal (similar to a sprint goal), they reevaluate quickly, make adjustments, stay adaptable, and continue without losing sight of the goal What Fortnite/other online games can teach us about having an agile mindset: The team collaboration in Fortnite emphasizes teamwork and shows how having ‘hero complex’ does not get you to your goal (you have to work together, one person cannot do everything) In Fortnite, your character can lose energy and need time to recuperate. In this scenario, a teammate will ask another for help to spot them as they recover, which is very similar to how high-performing agile teams should behave (i.e. being transparent with one another if you need help) There’s a collective recognition that you win and lose as a team The teams in Fortnite are self-organized and not afraid to take risks and fail fast — this is key to growth They always stay focused on the overall objective, which is a crucial mindset piece for agile teams to have Mentioned in this Episode: Fortnite Halo Discord The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart Quincy Jordan’s Book Pick: Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr 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, Professional Scrum Trainer Sam Falco answers the question: "Why do you say that Sprint Zero is an anti-pattern?" Why do you say that Sprint Zero is an anti-pattern? “Sprint Zero” is a label applied to the indeterminate period of time used to gather product requirements and analyze them before a Scrum Team can start developing the product. Although “Sprint Zero” appropriates a Scrum term, it isn’t part of Scrum, nor is it a Complementary Practice that enhances Scrum. Sprint Zero undermines Scrum and agility. Sprint Zero isn’t a Sprint The Scrum Guide tells us that “The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.” That’s enough on its own to dispel the idea that Sprint Zero is a good Scrum practice. Sprint Zero rarely has a timebox— I have seen organizations where Sprint Zero lasted for months—and no potentially releasable product is produced by it. Sprint Zero inverts agile values The purpose of Sprint Zero is to generate comprehensive documentation. The practice rests on the false belief that we can and should understand and predict all of a product’s requirements before we start building. We often use the phrase “gather requirements,” as if they are some harvestable commodity. For complex efforts like software development, nothing could be farther from the truth. Requirements emerge as we build and are often obvious only in hindsight. Spending time trying to predict them is wasteful. Not only does Sprint Zero value comprehensive documentation over working software, it values contract negotiation over customer collaboration. The implicit promise of Sprint Zero is that once we have defined and analyzed our requirements, we can arrive at an agreement about scope and no further interaction with customers will be necessary until the product is completed. By attempting to define scope up front, we miss out on the value of working with the customer over the course of the development effort to ensure that the customers true needs are met. Sprint Zero undermines agile principles It delays the beginning of product development—so forget about satisfying the customer through early delivery of valuable software. It violates the principle of welcoming changing requirements. It prevents emergence of requirements, designs, and architectures. Articulate a vision and start building Sprint Zero is nothing more than the earliest stages of waterfall disguised by an agile-sounding term. But it’s not necessary—or possible—to know everything up front. All those features and requirements that seem so important during a requirements-gathering phase often turn out to not be needed at all. The best way to handle the uncertainty of product development is not extensive up-front analysis, but to articulate a clear product vision and start building toward it. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
In today’s episode, Dan Neumann is joined by return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought. Andrea has 25 years of experience in software development and management. She is an innovator who has led multiple organization-wide scaled agile implementations, and she has also architected innovative solution strategies and roadmaps across many frameworks (including Scrum, Kanban, and the Scaled Agile Framework). Dan and Andrea will be discussing the premise of agility and the common misunderstanding that it is only an IT ‘thing’ and is software-centric. Andrea explains how agility addresses needs across the enterprise and that it is about collaboration with many different areas of the business beyond IT. She shares how a shift from software agility to business agility drives the enterprise; and talks collaboration, feedback loops, design-thinking techniques, the importance of being customer-centric, applying agility across the organization, and key considerations around bringing the technology side and business side together. Key Takeaways Considerations when shifting to a more business agility: Be careful not to create “us vs. them” scenarios (‘us’ as in the technology side and the ‘them’ being the business side) As leaders, it is important to open up about the way you think about Agility and the principles It is important to create a united effort of working together to achieve the desired outcomes (moving from ‘doing’ to ‘understanding’) Be aware of cognitive biases, for instance, the ingroup and outgroup bias (where people tend to ascribe positive behaviors/attributes to people they consider to be in their group vs. ascribing/amplifying negative behaviors/attributes to people they consider to be outside of their group) It is important to expand your ingroup bubble to at least your whole company (which would lead to more interpretation of positive intent and better collaboration) It’s not about the individual developer getting to done; it’s about the team getting to done Being more inclusive and valuing what every individual is bringing to the table has an incredibly profound impact Key pieces in shifting from a software (or IT-centric) view of agility to business agility: Start to reimagine roles and how you operate together The business side needs to welcome the technologists to their side/domain and vice versa Everyone needs to understand that there is huge value in understanding their customers/users and understanding the ‘why’ behind delivering Allow people to be free and feel safe enough to create and innovate Invite everyone into the full conversation Truly value being engaged Work towards building empathy between the people building the software and the people who will be using it Apply the Agile principles, practices, and mindset pieces across the organization Understand the ‘why’ behind why you’re doing agile practices as well as the intention behind them Key places to have dynamic conversations with technology and the business: Through backlog refinement — the inclusiveness comes from the product owner being able to articulate Come up with a more creative ‘how’ or an ‘incremental how’ The product owner can communicate “no” or “not yet” to their stakeholders The software on its own is not the product; there are other key pieces that create the ‘shrink-wrapped’ product “When we think about business agility, what we want to do is understand what it takes to really get that product into the hands of our customers” How you coordinate across the teams so you get that “shrinkwrapped product increment” is important Think beyond just getting the software to ‘done’ Key points around accelerating the value chain: Look to make ‘idea to value’ as short of a line as possible Reference The Age of Agile’s three laws of business agility: the law of the customer, the law of a small team, and the law of the network Empower your team and allow for autonomy Feedback loops with your users/customers are key Design thinking techniques are a great way to learn more about your customers/users Empathy is huge — it is the basis for innovation and creativity Mentioned in this Episode: The Agile Manifesto Modern Agile — Joshua Kerievsky The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart Andrea Floyd’s Book Picks: Shelter in Place, by Nora Roberts 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, Professional Scrum Trainer Sam Falco answers the question: "Is it OK to plan several Sprints in advance?" I’ve seen this practice in many organizations. Product Owners plan four, five, even six Sprints of work for their teams. The result is something like a Gantt chart with Sprints instead of weeks as the unit of measure. It’s a bad practice with many drawbacks and no real benefit. It diminishes transparency The Scrum Guide’s description of the Product Backlog gives us our first clues that planning Sprints in advance is a bad practice. “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.” Assigning Product Backlog items to future Sprints means that you’re splitting your Product Backlog into multiple lists. The order is more difficult to see, and instead of a single source of requirements, you now have several. The Scrum Guide also says that the Product Backlog is dynamic and constantly changing. Having Product Backlog Items scattered over a number of Sprints makes managing this dynamic change more difficult than if you have a single artifact. In one organization I was in, Product Owners would plan an entire Program Increment and then spent a significant amount of time trying to manage multiple forecasted Sprint Backlogs as well as the remaining Product Backlog. It diminishes self-organization When multiple Sprints are planned in advance, the Development Team loses its role in collaborating with the Product Owner to craft a Sprint Goal and select Product Backlog Items into the Sprint Backlog that they believe will help achieve that Sprint Goal. Often, no Sprint Goal is identified—instead, the goal is for the Development Team to “do all the things.” The Development Team’s autonomy is hobbled, and it is robbed of the opportunity to self-organize around a coherent, meaningful goal. It diminishes inspection and adaptation The Scrum Guide closes its definition of the Product Backlog by pointing out that while forecasting progress may prove useful, forecasting techniques “do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.” Planning multiple Sprints in advance means that we are making decisions about the future based on what we expect will happen. Sprint six is planned based on what we expect to do in sprints one through five, for example. We’re making assumptions about the future before we have a chance to validate what we’re doing right now. It tends to result in attempting to produce to a forecast rather than basing our work on current business conditions. But how do I forecast? Proponents of planning multiple Sprints in advance say that they need to do it in order to forecast release dates. But as Scrum Master Yoda said, “Always in motion is the future.” Planning several Sprints at a time, only to have to re-plan them as things change is wasteful and doesn’t create certainty. Instead, we should embrace uncertainty and incorporate it into our forecasts, providing a target range that widens the farther out we look. Forecasting with Scrum is best done by understanding our team’s velocity (as it actually is, not as we want it to be). We can use what we know about the team’s historical ability to deliver to make a “good enough” estimate of the least and most they are likely to produce. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
This week on the Agile Coaches’ Corner, Dan Neumann is joined by a new guest, Michael Guiler! Mike is an Agile Consultant at AgileThought. He has been an Agile coach for over 13 years now and has tons of experience helping geographically dispersed organizations (both business and technology) transform to better achieve their goals. His focus is on helping organizations learn and apply the values and principles of the Agile mindset to continuously improve. In this episode, Dan and Mike will be focusing on the topic of intent-based leadership and the key leadership characteristics that allow for intent-based leadership. Mike shares how an organization can begin to take the first steps towards intent-based leadership, how to avoid common pitfalls, and shares his best practical tips and advice on embracing intent-based leadership throughout the organization. Key Takeaways What is intent-based leadership? What problems does it solve? Helps to get the entire team to chip in and no longer wait for approvals and sign-offs Takes the pressure off of one single leader and unlocks the potential of every employee The opposite of directive leadership Changing the pattern from leader-follower to leader-leader Those in the leadership level are not telling people what to do/how to do it; they are setting goals and directions The ‘followers’ are engaging their creativity, mind, and intelligence and leveraging those skills and sharing their solutions with the leadership (this gives the organization a great opportunity to learn and exposes leaders to things they hadn’t thought about before) Getting started with intent-based leadership/Characteristics of leadership to allow for intent-based leadership: Before the leader-leader pattern can take place a lot of growth has to take place Keep in mind that this process won’t happen overnight Immediately begin to address competence — leadership at all levels can’t thrive if your team doesn’t have the skills or knowledge to prioritize and take action Establish safety — mistakes will happen; it’s how we react to those mistakes that will enable leadership at all levels to thrive or to fail miserably Use mistakes as a learning opportunity rather than punishing an individual Be curious and ask good questions from a place of true curiosity Challenge your preconceived notions of how things have always been done Embrace new ideas and thoughts — there’s a real chance you’ll learn something! Allow time for the team to talk out loud Respect others opinions and encourage others to have their own point of view It’s hard and will take a lot of time and investment (but it’s money well-spent — the productivity will explode) It’s important to set guide rails in the technology world Focus on the goal/outcome instead of the ‘how’; set clear intentions and let the team figure out how Adopt the “I intend to” language pattern Mike’s intent-based leadership tips: Once the competency is established and you’ve gotten your organization thinking about it, it is important to establish safety (without safety people won’t bring their creative-selves or do anything new) It is key crucial for the team to know what the goals are Have an “ish” mindset; decisions and actions being taken won’t match yours and that’s OK! Overcome urges to command and control Be tolerant of differences and encourage different points of view Mike’s recommendation to further learn about intent-based leadership: Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet Mentioned in this Episode: Michael Guiler Agile Coaches’ Corner Ep. 84: “Getting to ‘Finish’ as a Scrum Team with Andrea Floyd” Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet Forbes article regarding psychopathology in CEOs Michael Guiler’s Book Picks: The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning Leaders Eat Last: Why Some Teams Pull Together and Others Don't, by Simon Sinek 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, Professional Scrum Trainer Sam Falco addresses the question: “How do you escape the tyranny of the burndown chart?” The Problem with Burndown Charts This was the question a student asked last week. I knew exactly what he meant. I experienced it myself with my first Scrum Team, and I’ve seen it many time since. Teams try to predict every task they’ll have to do during a Sprint, estimate the hours for each, and make sure that the team’s capacity is fully allocated. As the Sprint progresses, they discover new work. Work that was predicted takes longer than usual. The burndown rises instead of falling, or it plateaus. The burndown chart becomes a burden that destroys morale and effectiveness. After a few Sprints of this experience, teams either abandon the burndown chart or they start playing games to make the burndown “look right.” In both cases, the team loses out on a valuable tool for helping them achieve the Sprint Goal. Does the Scrum Guide Require Burndown Charts? To be clear, the Scrum Guide does not mandate the use of a burndown chart. Here’s what it says about tracking Sprint progress: “At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.” Tracking total work remaining provides transparency about the team’s progress toward the Sprint Goal. That transparency allow the team to make informed decisions about how to adjust the scope of its work throughout the Sprint. If the team doesn’t know how much forecasted work remains, the Sprint Goal may be placed in jeopardy. A sprint burndown chart is one way to fulfill the need to sum up the remaining work and make that data visible. So why does the burndown chart so easily become a burden to the team, rather than a tool? Often, it’s because of a holdover from the mistaken belief that software development can be managed through predictive processes. Even in organizations that recognize the folly of predictive planning on a macro level, teams fall into the trap of thinking they can and should plan every minute of a team’s capacity. How do we use a Burndown Chart Effectively? Software development falls into the realm of complexity. Even within a Sprint, we have to allow for emergent understanding of the work. Requirements, understood well enough for the work to begin, become clearer. New work emerges as a result. Teams that have strived for efficiency in allotting their time find that there’s no room to adjust as new information and understanding becomes available. The secret to avoiding the tyranny of the burndown chart has nothing to do with the burndown chart itself. The secret is to let go of the belief that we can know everything up front and that efficient time usage is a worthwhile goal. Instead, strive for value delivery, select work that the team understands well enough to start on, and don’t strive for 100% utilization. The only thing certain about software development is that it is filled with uncertainty. In Sprint Planning, you need only look a few days into the future, and allow remaining details to arise as work gets underway. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
In this week’s episode, Dan Neumann is joined by frequent guest of the show, Quincy Jordan — principal transformation consultant and agile competency lead at AgileThought! Together, they are exploring COVID-19 as an agile accelerator. In the agile space, there has been a long-time myth that face-to-face is synonymous with colocation and that you cannot have effective agile teams if they are not colocated. However, in the past year or so, many companies have been beginning to consider going to a hybrid remote model. But, when COVID-19 hit, their 12-month transition plans quickly became one-week transition plans. And though this has been very difficult for many, this acceleration due to COVID-19 has actually been a good thing in many cases — which is what Dan and Quincy will be talking about today! They discuss which types of things got accelerated, beliefs about agility that got challenged due to COVID-19, what the ‘new normal’ post-COVID-19 may look like, and how these changes will be made to be sustainable going forward. Key Takeaways Beliefs about agility that got challenged due to COVID-19: Those people in the agile space that were especially adamant that you cannot have effective agile teams that are remote were shown that it was possible Some people believed that doing training in a distributed way would bring the quality down — however, the quality of training that is being delivered has not gone down since going remote What COVID-19 has accelerated: When pressed, many people are able to do very impressive things and accomplish more than they thought possible It accelerated ingenuity and creativity It accelerated the decisions to collaborate with one another as teammates and to quickly come together on a situation to figure out the most effective solution It helped accelerate clarity on what was truly important to accomplish It has driven companies to really start embracing business agility a lot more Agility went from a concept that companies only thought about to a concrete concept that they embraced Organizations have been focusing on value more due to embracing the agile mindset (and COVID-19 has been pushing this to further bounds) It has helped push organizations to further their alignment on business agility and focus on the problems that need to be solved COVID-19 has also accelerated businesses beyond those in software (it permeated into all facets) Challenges regarding COVID-19 and the acceleration it has brought: How do we maintain alignment between business and IT in this remote world? (How often do we need to meet? What do we need to be aligned on?) Video conference fatigue How do we ensure that the right problems are being solved, that the vision is clear, that the business objectives at hand are clear, and that the teams know how to tie their work to meaningful outcomes for the business? People don’t adapt as fast as technology What might the new ‘new normal’ look like post-COVID-19? There most likely will be more remote work and more emphasis on collaborating remotely There may be a bigger demand for remote tools (such as digital whiteboards) and they will become even more efficient going forward People will most likely be more intentional about how they are showing up to video conferences with clearer goals in mind Mentioned in this Episode: From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver, by Johanna Rothman and Mark Kilby The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart 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, Professional Scrum Trainer Sam Falco addresses the question: "How do we avoid Scrum adoption pitfalls?" Last week, a student asked me what are some common pitfalls that we see when organizations shift to Scrum from a “big design upfront” process like waterfall. A big one is that they think it’s a silver bullet Adopting Scrum doesn’t solve problems overnight. It doesn’t solve problems at all! Scrum will surface the problems in your ability to deliver so that you can fix them. Too many organizations falter when Scrum runs up against an organizational impediment and “the way we’ve always done it” wins out. One example of this phenomenon is when there’s an onerous change management system that prevents code from getting into production. Scrum teams complete an increment and it sits there waiting until someone approves it to be moved to production. Sometimes, the wait is so long that multiple increments pile up. Some organizations will cling to that change management system even though it’s getting in the way. Success comes when they adapt to the new way of working. At one organization I worked with, the solution was to set up an experiment with one team working on a less risky area of code. Once they proved that they could safely put code into production without breaking things, it paved the way for broader changes to their process. Another pitfall is that the organization doesn’t really adopt Scrum In many cases, organizations claim to adopt Scrum, but what they really do is apply Scrum terminology to existing roles and processes. I frequently see the term “Product Owner” used—or maybe I should say abused—as a new name for a Project Manager. But those Project Managers carry on pretty much the way they did before. They lack any of the accountabilities or authority of a Scrum Product Owner. They shift from using Gant charts measured in weeks to plotting out a project in Sprints over several months. And that’s another way this behavior manifests. They’ll use the name of Scrum events without understanding their underlying purpose. A Sprint lacks the focus of creating a usable increment. “Daily Scrum” is a daily status report. “Sprint Review” is a carefully orchestrated smoke-and-mirrors show with limited, if any feedback or collaboration with stakeholders. Without using all of its roles, events, and artifacts—and the rules that bind them together—you’re not using Scrum. You’re probably perpetuating your existing system. You know, the one that wasn’t working for you before. This is the realm of “Scrum, but.” And “Scrum, but” is not Scrum at all. They don’t make other necessary changes Even when an organization adopts Scrum’s mechanics, they sometimes find that Scrum doesn’t provide the benefits they hoped for. Delivery improves a little, but it soon plateaus and it’s a struggle to keep improving. That’s because other changes are necessary to really reap the gains of Scrum. A common organizational structure is to have teams organized around technical layers or components. For example, a User Interface team, a Data Access Team, a Service gateway team, and so on. Scrum requires that we produce a working increment each Sprint, which means one that’s in usable condition. Teams organized by layers or components face numerous handoffs and challenges integrating their work. There’s a loss of transparency, and they struggle to compete that working increment. The solution is to form teams that can deliver complete features that cut across all layers. Scrum doesn’t tell you to do that, but it works best if you do. Scrum also doesn’t tell you to adopt good DevOps practices, or incorporate Kanban techniques, or to refactor your code. They’re all still good ideas. Scrum is incomplete for a reason and that’s so that you can identify what works best for your organization. You have to go beyond Scrum. I talked about the pitfall of “Scrum, but,” earlier. But “Just Scrum” isn’t enough. You need “Scrum, and.” Adopting Scrum requires a shift in organizational mindset. Without that, people revert to familiar behavior, even if that behavior wasn’t effective. And adopting Scrum can’t be an endpoint. It’s the beginning of a journey of experimentation and continuous improvement. In the Trainer Talk episode “Why Does Scrum Have So Many Meetings?” a few weeks ago, I mentioned that implementing Scrum requires intentional, thoughtful organizational redesign. That’s true of implementing the basics of the framework, but it’s equally true about the wider ecosystem that Scrum teams work in. And just like I said in that earlier episode, that’s why you need a good experienced Scrum Master—and sometimes more than one—to guide your organization’s Scrum adoption. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
Joining the podcast once again one of Dan’s favorite return guests, Christy Erbeck! Christy is a principal transformation consultant at AgileThought and a Certified Dare to Lead™ Facilitator (CDTLF). She has over 25 years of experience in domestic and international consulting, training and coaching, and working in both software development and non-product-focused environments, including manufacturing (discrete and process), distribution, and sales and marketing. In this episode, they are exploring the topic of uncertainties. There’s a lot of uncertainty going on in the world right now with COVID-19. We’re in this awkward gray zone that Christy refers to as “the muddy middle.” And, as much as we’re getting used to this ‘new normal,’ there are still adjustments and daily changes that can be very disruptive to our psyche. So, in today’s conversation, Christy and Dan are taking a deep dive into exploring these uncertainties and Christy provides the tools and tips you need to better adapt during this confusing time and make the most of it! Key Takeaways What is this ‘new normal?’ The ‘new normal’ can refer to “the new better” in reference to organizational transformation or change (because with these new changes come new ways of working and new ways of thinking that create a better outcome than what was previously in place) In reference to what we’re currently experiencing, ‘our new reality’ may be a better phrase ‘New normal’ is a concept of accepting the current disruption as our new reality to have an easier time adapting to the new way our day-to-day lives look The sooner we recognize that this is our reality the better able we will be able to adapt, grieve our old reality, and find a way to make this current reality the best we can Christy’s tips and tools for adapting to the ‘new normal:’ First, recognize where you are personally and take some time to reflect and go inward and ask yourself: “Where am I? How am I feeling?” Christy uses a journal to track her mood every day so she’s better able to reflect on where she’s at Recognize that we cannot, at this moment, move into comparative suffering (i.e. saying that your suffering is worth more than someone else’s and vice-versa) Own how you feel Dig deep into your ability to empathize and seek to understand how others are experiencing the ‘new normal’ Be overly generous with yourself (which will give you the space and capacity to be overly generous with those in your circle and community) Adopt the concept “assume good intent” because, as you take care of yourself, you’ll have more space to assume good in others around you (which gives extra grace with your interactions with people) Come together and allow everyone to share their voice and stories Reach out for help if, in your process, you are still struggling (because you don’t have to do this alone) Anti-patterns/How we should not respond: Comparative suffering Competitive storytelling Listening to respond Mentioned in this Episode: APA’s Help Center SILK + SONDER (Self-care monthly planner and journal subscription service) “10 Eye-Opening Statistics on the Mental Health Impact of the Coronavirus Pandemic,” Forbes The Road Less Traveled, Timeless Edition: A New Psychology of Love, Traditional Values and Spiritual Growth, by M. Scott Peck The Four Agreements: A Practical Guide to Personal Freedom, by Don Miguel Ruiz Turn the Ship Around!: A True Story of Turning Followers into Leaders, by L. David Marquet Brené Brown 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 week’s episode, Dan Neumann is joined by special guest and AgileThought colleague, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought. Andrea has 25 years of experience in software development and management. She is an innovator who has led multiple organization-wide scaled agile implementations, and she has also architected innovative solution strategies and roadmaps across many frameworks (including Scrum, Kanban, and the Scaled Agile Framework). Last week on the podcast, Dan and Quincy Jordan were exploring the topic of getting to ‘start’ as a Scrum team and overcoming the inertia of being stuck. Continuing on this theme, Dan and Andrea figured it would be fitting to discuss what comes after getting to start. I.e., start finishing! So, in this episode, they discuss everything that happens between starting to finishing, getting to ‘done’ incrementally, challenges Scrum teams run into with starting ‘finishing,’ and Andrea’s tips for getting to ‘done’! Key Takeaways Challenges Scrum teams run into with starting ‘finishing’: They get stuck with reimagining the new way of working and understanding how to get to ‘done’ incrementally They face analysis paralysis by overthinking (which prevents them from adapting to this new way of working) They may defer risk due to their fear of failure They have a reluctance to let go of yesterday and falling back on the previous practices they were comfortable with because it’s easier/what they know They take on more work without considering what’s going on with the rest of the team What does “finish” or “done” mean? All organizations have their own, unique definition of ‘done’ Some organizations even have multiple definitions of done for different levels (i.e., ‘done’ at the story level, done at the sprint level, done at the release level, etc. [it depends on their build and release cadence]) Andrea’s tips for teams for getting to ‘done’: It is important for the team to discuss what “finish” or “done” means and to come to a consensus Make the definition of “done” visible in the team room (the more visible it is, the easier it is to refer to and to guide conversations) Get creative in the visibility of your team’s definition of ‘done’ — Andrea suggests making team t-shirts with the slogan, “Our definition of done: ______” Look for opportunities to care and work with your team members to support them in this journey (retrospectives and daily scrums can be great opportunities for positive reinforcement, calling out work well done, and celebrating successes) Work together as a team and help one another Consider adopting a catchphrase for your team such as, “No man/woman left behind” Stay focused on the sprint goal as a team The practices established in Scrum will help you understand the ‘why’ behind what you’re doing and how you’re working Use the Five Whys to understand the root cause of why some team members may be stuck in their ways and not wanting to adapt Get the team to a point where they feel safe and courageous enough to share the challenges they may be facing that are preventing them from achieving their goals Create an environment that feels safe and supports learning, courage, and experimentation Make safety a prerequisite You can achieve great wins as a leader by empowering your team, helping them become autonomous, and teaching them the ability to self-organize Mentioned in this Episode: Agile Coaches’ Corner Ep. 83: “Getting to ‘Start’ as a Scrum Team with Quincy Jordan” The Failure Bow The Five Whys Waco (TV Mini-Series) Tiger King (Netflix Series) Andrea Floyd’s Book Pick: The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning 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!
Joining Dan Neumann this week is frequent guest, Quincy Jordan! Quincy has been with AgileThought for just over two years as a principal transformation consultant and agile competency lead. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. He has also served as a principal consultant and agile coach at SCRUMstudy.com for over six years. In this episode, Dan and Quincy are talking about what it takes to get from zero to ‘start’ as a Scrum team. They speak about the different types of starting, the strong values needed for getting started, the foundational pieces you need a strong understanding of, some of the bad practices and anti-patterns teams fall into when getting started, and additional key pieces to keep in mind after a Scrum team is established. If you want to know how to go from zero to start — stay tuned in! Key Takeaways Scrum values that are key to getting started: Courage is needed to get to the point of deciding to start A willingness to try something that you haven’t tried before Adaptation is crucial Be comfortable moving forward in the face of ambiguity Being okay with starting before everything is “perfect” or “right” (because you can’t ever get it “right” if you don’t start at all) Key points and understandings to getting to ‘start:’ Clarify the roles in Scrum Refer to the Scrum Guide to understand the foundations of the framework Determine who is going to fill the role of Scrum Master and the Scrum Product Owner It is critical to understand that the Scrum framework is already so scaled down that you really can’t take anything out If you do not have enough team members to separate the roles out it is possible to start, but not recommended Having the product backlog in place helps keep the team focused — especially early on (because it helps the team know what they’re headed toward is truly producing value) Start with the questions: Do we have a team? Do we have a group of people who are committed to doing the work? Are they cross-functional enough to do the actual increment at the end of every sprint? Do they have a product backlog that helps identify what to do? Take note of what isn’t in the Scrum guide You don’t need to forecast four or five sprints out (too much will change before you get to that point); if you have enough for one or two sprints you can start Camaraderie is an essential part of doing Scrum Leadership support/buy-in is not 100% necessary to get started You should have a commitment to allocate a cross-functional group of people to the effort and allow them to focus The team needs to collaborate and work together; you can’t have islands within the team Key pieces to understand after getting to ‘start’: A way to gain leadership support/buy-in is to get some early, quick wins and show the value of what your Scrum team is doing When the leadership support is there, the onus is on the team to make sure that they’re communicating well with leadership Communicate well with leadership by not only letting them know what’s great but letting them know the challenges as well Frequent communication within the team outside of the daily Scrum is crucial Mentioned in this Episode: The Scrum Guide 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, Professional Scrum Trainer Eric Landes addresses the questions: "hy would the Scrum guide not use ceremonies and events interchangeably?" Introduction In some classes, students will refer to the scrum events as ceremonies. Yet the guide refers to these as events. So why would the Scrum guide not use ceremonies and events interchangeably? My answer typically is something along these lines: What is a Ceremony? While we might be able to use these words interchangeably, I think there is a reason for the distinction. There is not a clear explanation in the scrum guide why this is. But if we look at the definition of “Ceremony,” we might find some hints. According to dictionary.com, one of the definitions of ceremony is "the formal activities conducted on some solemn or important public or state occasion". I think the key is in formal and solemn. In fact, most of the rest of the explanations include the word or a variant of the word formal. What is an Event? In contrast, dicitonary.com defines event. "something that happens or is regarded as happening; an occurrence, especially one of some importance." The scrum guide says this about events - "Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.” The talk of creating regularity is better defined by event than ceremony to me. And this speaks to scrum as a whole. It is more about a framework that helps solve complex problems, it's not a solemn process that teams must follow. Scrum Should Minimize Other Meetings I also emphasize to students that the events are supposed to minimize the need for meetings not defined in Scrum. If team members are saying that Scrum makes most of their time about meetings, I will respond that this is not from the scrum framework. This may be an issue where prior meetings for non-scrum frameworks are still on the books and may not be necessary! As a team take some time and evaluate the need for these meetings. Collaboration is Key Sometimes I will tell classes that Scrum and other agile frameworks were invented to make sure that developers meet in a regular cadence. Collaboration was not a necessary component of software development when I first started. Agile frameworks just showed us knowledge workers how much we needed collaboration and gave us events that made sure we were collaborating! Conclusion So whatever we call these events, make sure to follow the framework, and use them to encourage and foster team collaboration! Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
This week, Dan Neumann is joined by a special return guest — Christy Erbeck! Christy is a Principal Transformation Consultant at AgileThought and a Certified Dare to Lead™ Facilitator. She has over 25 years of experience in domestic and international consulting, training and coaching, and working in both software development and non-product-focused environments, including manufacturing (discrete and process), distribution, and sales and marketing. Today, they’re going to be exploring the topic of how to ask powerful questions. Powerful questions can lead to powerful change if they are asked in the right way. In this episode, Christy explains what makes a question powerful vs. a not-so-powerful one, how to ask powerful questions, when and when not to ask a powerful question, and important qualities and skills for a facilitator or coach to have that is asking these powerful questions. Christy also shares some fantastic resources for further reading on the subject and provides some examples of what powerful questions look like! Key Takeaways What makes a ‘powerful question?’ A powerful question is one that gets the person being asked to think about the situation in a way that they may not have if the question had not been asked Powerful questions elicit a thoughtful response They provide a way to help the individual being asked to become ‘unstuck’ The Co-Active Training Institute defines a powerful question as: “A provocative query that puts a halt to evasion and confusion” The person asking the question is inviting the client to clarity, action, and discovery at an entirely new level They help people think differently How to ask powerful questions: Kickstart coaching sessions by asking, “What’s on your mind?” to simply begin the conversation in a way that allows the coachee to bring forward a topic in a way that is non-judgemental and invites additional inquiry Ask a question in a neutral way versus a ‘loaded’ way Stay neutral and ask the question in a curious way rather than in a judgemental way Use the Five Whys technique Take into consideration the layering and sequencing of the questions you’re asking Make sure that the person you’re engaging with is interested and engaged Ask yourself if you have earned the right to ask the question in the first place (i.e. a level of mutual respect has been reached and the person being asked believes you to be credible) Important qualities and skills for a facilitator or coach asking these powerful questions to have: Understand what type of questions or decision-making needs to happen in the moment Understand the different types of questions and the different intents and outcomes that those questions will provide Have a natural curiosity and perspective of care when working with clients Create space and allow for silence for people to answer the questions When shouldn’t you ask a powerful question? When you don’t have time to debrief and explore Potentially, in a group setting (it is important to consider the dynamic of the room) Ask yourself, “Is now the time to ask this question?” because the trust and safety may not be strong enough yet to be asking certain questions Questions that are uninvited, at an inappropriate time, or out of line Examples of powerful questions: “What do we need to do to wrap this up and have clarity around our next steps?” “What’s preventing us from moving forward?” “What’s keeping [decision] from actually being enacted?” “Tell me more” questions Clarification questions Open-ended questions such as who, what, when, where, why, and how Powerful resources to learn more about powerful questions: The Co-Active Training Institute The Coaching Habit, by Michael Bungay Stanier The Complete Book of Questions, by Garry D. Poole Vertellis — a card game Mentioned in this Episode: Co-Active Training Institute The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever, by Michael Bungay Stanier Five Whys Technique The Complete Book of Questions: 1001 Conversation Starters for Any Occasion, by Garry D. Poole Vertellis card game Christy Erbeck’s Book Picks: Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr Employee Experience: Develop a Happy, Productive and Supported Workforce for Exceptional Individual and Business Performance, by Ben Whitter 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, Professional Scrum Trainer Sam Falco addresses the question: "If we have stories that aren't finished by the end of the Sprint, how do we get credit for the work we've done so far?" Introduction I get that question a lot, both in training classes and when I'm coaching teams. It stems from a fundamental misunderstanding of what a Scrum Sprint is for and how Scrum Teams should measure their effectiveness. How does seeking credit relate to the Agile Manifesto? Two of the principles behind the for Agile Manifesto are relevant: "Working software is the primary measure of progress." It doesn't talk about credit. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Seeking credit for unfinished work violates both principles. There's no value in unfinished work! OK, mister smart guy, I hear people saying, but it happens. Sometimes things don't get finished. What should we do about it? Achieving the Sprint Goal without finishing all Sprint Backlog items In the most positive scenario: the team achieved the Sprint Goal, but there were some extra items in the Sprint Backlog that weren't directly related to it. We have a working, thoroughly tested Increment that meets our definition of "Done," but we also have these one or two things we were doing, and we've run out of time. If that's the case, congratulations on creating a potentially releasable increment! As to those extra bits that you thought you could finish, have a conversation with your Product Owner. Is this work worth continuing? Make sure it is reflected in the Product Backlog, so the Product Owner can order it appropriately. Maybe it should go into the next Sprint, maybe not. It's the Product Owner's call. In your Retrospective, talk about the fact that the Development Team brought work into the Sprint that it couldn't complete, and talk about why it happened. Did the team overestimate how much work it could do? Adjust for that in future Sprint Planning. Did your team add the extra work as a kind of "stretch goal," or add new work to the Sprint Backlog late in the Sprint because it was running out of work to do, and wanted to "fill up the time?" Talk about whether those are practices that add value. That half-completed work is a form of waste. The Sprint Goal was not achieved Another scenario, less positive, is when the incomplete work means that the team failed to achieve the Sprint Goal. There's no new working increment. If that's the case, the team needs to figure out why that happened. This becomes another topic for a Retrospective. Was the Sprint Goal too ambitious? Worse, was the Sprint Goal simply, "Do all the things?" Learn to create better Sprint Goals. If the Sprint Goal was reasonable, figure out what kept the team from achieving it. Do better the next Sprint. Examine your practices and figure out how you can achieve the Sprint Goal next time. Just don't kid yourself that you "get credit" for incomplete work. Don't engage in accounting tricks, where you split the Product Backlog Item and include the incomplete work in this Sprint's velocity and hope to finish the rest in a future Sprint. Carrying over work from Sprint to Sprint subverts the Product Owner's accountability for maximizing the value of the product and of the Development Team's work. How do we measure effectiveness of a Scrum Team? Scrum Teams should measure their effectiveness by the value they deliver, not by how busy they are from Sprint to Sprint. If the organization values productivity measures rather than value delivery, the Scrum Master should work with the organization to re-orient its outlook. The Scrum Master will also probably need to work to establish safety for the team, so that they don't feel obligated to try to fill up every minute of their time. Conclusion The purpose of a Scrum Sprint is to produce a thoroughly tested product Increment that is in useable condition. There is no "credit" given for work that isn't complete in Scrum. You either produce an Increment by the end of the Sprint that meets your definition of "Done," or you don't. You either fulfill your Sprint Goal, or you don't. There's no middle ground. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
This week, Dan Neumann is joined by repeat guest and AgileThought colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a principal consultant and agile coach at SCRUMstudy.com for over six years. In their discussion today, Dan and Quincy are talking all about disruptions in these unprecedented times. Right now, disruptions, especially in the transformation space, are incredibly challenging. Though, there is a silver lining given the circumstances; Disruption can also lead transformation where there wouldn’t have been without the push. So in this episode, Quincy and Dan highlight some of these transformations that they’re seeing currently happening within companies and the silver lining of what it could mean for these companies in the long term. Key Takeaways Transformations currently happening within organizations: Airlines have had to revisit their business model and reward programs (such as extending reward points) Companies are making very quick adjustments and shortening their feedback loop Companies also have to respond very quickly which is causing them to figure out what they need to respond to and prioritize Companies have a new focus that has emerged: they need to figure out the true important problem that they are solving Companies are needing to figure out creative ways to continue operating during this time They are adding services (like curbside pickup) and figuring out what services to subtract (such as offerings that are not applicable or appropriate during this time) Obtaining professional certifications have gone remote as well (such as on Scrum.org) Companies and individuals are understanding what is important to focus on now and moving more quickly to get it in place They are figuring out how to limit their risk by figuring out what to respond to and what not to They are limiting risk by shortening their feedback loop (sometimes to even a matter of days) They are leveraging their infrastructure and their ability to use Cloud technologies to scale up and roll out new changes They are making sure that the company’s values stay central to the decisions Final thoughts and questions around transformation: COVID-19 has really challenged the agile space as many of its principles are grounded in being in person/communicating in person It has proven that remote facilitation and coaching is possible When someone’s back is pushed against the wall all of a sudden new solutions arise because you have to It’s not just about being Lean or Agile; it’s about figuring out the right problems to solve as quickly as possible ‘What are the things that are being disrupted that will lead to true transformation and then what things are being disrupted that are being put on pause and will be revisited later?’ ‘What disruptors that are happening now as a result of all of this will create a new norm that becomes what we have transformed into?’ Are we changing for now and then going back or is it a permanent change in how we do things? There is more need and delivery on remote agile coaching and remote transformation consulting due to not being able to go on-site (will this be more of a permanent offering going forward or is it just transient until everything settles down?) Mentioned in this Episode: Mike Rowe “Amazon temporarily suspending Amazon Shipping service” Scrum.org Scrum Alliance MURAL 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, Professional Scrum Trainer Eric Landes addresses the questions: "How technical stories should be used in Scrum?" Overview I have been asked how technical stories should be used in Scrum. Great questions, and of course Scrum has a framework, while not specifically talking to this issue. When discussing technical stories, I typically am thinking about things like product performance, system availability, and security. I refer to these as non-functional requirements, and the Scrum guide does not specifically speak to NFRs. However, the scrum guide has this to say about the product backlog: "The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. " So, looking at the scrum guide definition it would seem that we can put NFRs in the product backlog. Of course, the last sentence of this part of the scrum guide: "The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." means that the team needs to work with the Product Owner on NRFs that belong in the product backlog. Example of a Non-Functional Requirement Here is an example of an NFR that might be used in the backlog. The team has a screen on an application that shows personal information, including credit scores to a sales administration user of your application. Your security team has deemed that Personal Information like this cannot be displayed due to certain laws within different countries. Your product owner could add a PBI that describes hiding data on the Sales administration screen, which is not adding functionality. Refine the Definition of Done I also tell students that NFRs that apply to multiple PBIs might be a candidate for definition of done. For instance, if we have a security requirement that all code must be run through a static code analysis and then dealt with, we might put running a static code analyzer against source code as part of our definition of done. Update the Acceptance Criteria Another way to deal with an NFR is to place it in the Acceptance Criteria of a PBI. Let's say we have a feature that includes posting data to an external data store. The requirement was that after a sales transaction the sales data needs to be pushed in that data store within 10 minutes of the transaction. We could easily put that into your Acceptance Criteria. Conclusion The bottom line is that while Technical Stories, or Non-Functional Requirements are not mentioned explicitly in the Scrum Guide, the framework gives teams ways to handle them. And in typical self-organizing fashion, it is up to the team to determine the best way to handle this for their application. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
In today’s episode, Dan Neumann is once again joined by his colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a principal consultant and agile coach at SCRUMstudy.com for over six years. Today, they’re talking agile psychology and the rise of the agile Jedi. They go beyond the general skills and practices of agile to the key mindset pieces and various ways of thinking. Similar to a Jedi, agilists need to also go on a journey of mastery to improve all aspects of their skills. So tune in to find out more about agile psychology and begin on your path to becoming an agile Jedi! Key Takeaways What is agile psychology? Being more in tune with how things are impacting the teams From a human standpoint, you’ll have an easier time getting teams to perform better Understanding people better and then understanding how to use that information effectively Evaluating things like reading the room and reading microexpressions — and not only picking up on them but knowing what to do with that information What does it mean to be an agile Jedi? It is a play on Star Wars — Jedi is a master of certain skills, so in reference to agility, it is referring to going beyond agile coaching to a true mastery of agile psychology and understanding how you influence vs. manipulate, etc. It’s about mastering the soft skills, reading microexpressions, seeing microaggressions, etc. Quincy’s tips for coaches and project managers: It’s important to ask yourself if the project was truly successful (i.e. it’s not always just about getting the result — ask yourself, ‘Are you contributing to a sustainable model?’ or ‘Is this a sustainable business model that goes toward business agility?’) As a coach, it is important to teach behaviors and skills rather than a shift in mind-shift Bad practice: project managers that are more concerned about if the process was followed rather than if the outcome was achieved It’s important to understand that the individuals on your team understand the psyche of the role they’re assigned in an agile framework (i.e. you can’t just spray paint a lime orange and call it an orange!) When you’re moving someone from one role to another during an agile transformation it is important to take psychology into consideration It’s important to consider the ‘why’ behind the Agile Manifesto Agile coaching vs. Agile psychology: A key difference: getting into the experience that those that you’re influencing are having i.e. influence vs. manipulation The difference between influence vs. manipulation is the intent If you’re operating in agile psychology, you want to influence, not manipulate Helpful tools, tips, and skills around building agile psychology: Active listening training can be helpful in helping you to empathize with the person you’re listening to and forcing you to put your own thoughts aside and genuinely listen — critical thinking is also crucial Micro-expressions and negotiation training is beneficial in learning how to read others (the agile psychology part comes in when you learn what to do with this information) If you can empathize with someone it puts you in a better position to help them in shifting their thinking that is more beneficial for the whole Mentioned in this Episode: The Dave Ramsey Show (Podcast) National Public Radio (NPR) Active Echolocation 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, Professional Scrum Trainer Sam Falco addresses the complaint: "I don't like Scrum because there are too many meetings." At first glance, that seems like an odd thing to say, because there are only four meetings. The Meetings in Scrum Sprint Planning is timeboxed at up to eight hours for a one-month Sprint. It's usually shorter for shorter Sprints. The Daily Scrum, as the name implies, happens every day, but it's timeboxed to no more than 15 minutes. Sprint Review takes no more than four hours for a one-month Sprint, and it's usually shorter for shorter Sprints. Sprint Retrospective maxes out at up to three hours for a one-month Sprint. Like the other two big events, it's usually shorter for shorter Sprints. In a one-month Sprint then, you're spending no more than 15 hours in the big events, and for the Daily Scrum, five or so hours spread out in fifteen-minute increments. And that's out of roughly 160 hours per month. That means that we're talking about twelve to thirteen percent of your time in meetings that are designed to make the remaining 87 percent more effective. It's not actually that much time. So, what drives the complaint that Scrum has too many meetings? Scrum Might be Adding Needed Structure One driver comes when Scrum is being introduced into an environment where there aren't many existing meetings. Usually, this is an organization that is emerging from a startup culture, where there is a more wild-west style, with an informal network of ad-hoc communication. As startups grow, that informal network starts to break down. A framework like Scrum ensures that the necessary coordination and collaboration occurs. Otherwise, meetings metastasize across the calendar. Get Rid of Some Old Meetings More commonly, I hear the complaint in the context of an organization that already has a ton of existing meetings. Scrum events are overlaid like a veneer on existing process and meetings, which are retained without examining them to determine if they're providing value. The Solution The solution is not to add Scrum to existing process and meetings. Scrum is a radical replacement for an ineffective, bureaucratic culture--including all those meetings that aren't providing value. Odds are, the Scrum events supply all the value you need for effective collaboration and delivery. If you find that you really do need more structure than Scrum provides, you can always add it back in. Regardless of which direction the concern about too many meetings comes from, implementing Scrum requires intentional, thoughtful organizational redesign. That calls for an experienced, effective Scrum Master who is adept at navigating all levels of the organization and helping achieve business agility. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
In this week’s episode, Dan Neumann is excited to be joined by someone outside of AgileThought, Yvonne Marcus! Yvonne specializes in teaching home management (which is the process of effectively running a household) with an agile twist. Her mission is to help parents develop flexible home management solutions using agile principles to leave them with more time for themselves, quality family time, less money spent, and a more productive week. Yvonne Marcus shares how you can begin to implement agile into your home with her invaluable tips and tricks in this episode! She shares exactly how you can start bringing the agile process into your home, how to introduce your family to it, and actionable tips to take in getting started. Yvonne truly illustrates how applying agile principles can take your family from surviving to thriving! Key Takeaways What is home management? Everything you have to do in your house to make it run (doing the dishes, cooking dinner, taking care of your kids, etc.) The process of effectively running a household Ways to apply agile to home management: You can use Scrum boards at home for your kids so they know what they need to do for the day (and lessen their dependency on parents to guide them through every step) The kids can contribute to the backlog during their family sprint meetings (ask your kids: “What needs to be done in the next two weeks?” or “What do you want to do in the next two weeks?”) Families can also discuss behavioral problems at the sprint meetings and discuss what an appropriate consequence could be for said behaviors by involving them in the process (similar to a team working agreement) Yvonne’s tips for bringing Agility into your home: Yvonne uses DAKboard for their sprint goal board where she keeps track of their daily schedule, count downs to important events, sprint goals, etc. She recommends whiteboarding and putting everything either in a Google Sheet or using an application that creates to-do lists (such as Microsoft To-Do) Do not ask anyone in your family to start using a new piece of software that they do not already use (because if they’re not used to it they will not use it and you’ll fail with your first implementation of trying to run agile at your house!) You can use Scrum, Agile, Kanban, etc. — whatever works best for your home! Do your daily Scrum first thing in the morning An important question to ask yourself is: “How much time do I need to take care of myself today?” (Because if you don’t set aside self-care time at the very beginning of the day you will always find something in your home that is more important that needs to be done and you’ll forget about it) Create a sustainable pace with the principles behind the Agile Manifesto (it’s not just about the work)Stick with it even if it’s not perfect the first few times Create a continuous feedback loop by asking your family what went well that week, what didn’t work, modifying, and implementing changes Ask yourself: “What is the simplest thing you can do to create a solution for the start?” Don’t go over the top; just start with what you have Take the four tendencies quiz (it can be helpful to understand who is on the “team” and how to communicate in a way that will be most receptive for them) Where Yvonne recommends getting started with implementing the Agile process in your home: Start with the daily standup (because being able to reconfigure time so that everyone’s time is valued will be one of the most eye-opening spots) If you start with the daily standup you’ll see the most immediate success Everyone should provide input so that everyone knows they have a weight in what is going on inside the home Mentioned in this Episode: Yvonne Marcus “Agile programming — for your family” Bruce Feiler’s TEDTalk The Secrets of Happy Families: Improve Your Mornings, Tell Your Family History, Fight Smarter, Go Out and Play, and Much More, by Bruce Feiler DAKboard Microsoft To Do Whiteboarding Yvonne Marcus’ Podcast: Your Agile Home Airtable ClickUpTrello iCalendarGretchen Rubin — The Four Tendencies Quiz Ethical Hacking Courses on Udemy 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, Professional Scrum Trainer Eric Landes addresses the questions: "Can Scrum and Kanban work together?" Introduction In my classes I often get asked about the differences between Scrum and Kanban. Can Scrum and Kanban work together, how can that work? Typically people will talk about one team doing and Kanban, typically an Operations type team along with other Scrum teams, typically feature teams. Scrum and Kanban can Coexist The short answer is Kanban and Scrum can coexist. Scrum.org has a class called Prfessional Scrum with Kanban. This was created by Kanban expert Daniel Vcante and Yuval Yevet a Professional Scrum Trainer. Both of Daniel and Yuval have extensive kanban experience and have been working in the Kanban community Yes, Kanban and scrum can coexist. How does that actually work, you are asking? Let's think about this. Kanban is about flow and Kanban principles and practices do not conflict with the Scrum framework. The principles for Kanban are: start with what you know and agree to pursue incremental evolutionary change and respect the current process, rules responsibilities and titles. Within Scrum, we have a built in way to achieve evolutionary change, because we inspect and adapt. The retrospective and daily scrum are ways that this can be achieved. Limit Work In Progress There is some limit work in process in Scrum, in Kaban it is more explicit. Making processes explicit is another Kanban practice that makes sense, Kanban implements feedback loops and we improve collaboratively and evolve experimentally. Again all of these seem very compatible with the scrum framework So we're not staying with Kanban and scrum together, you are getting rid of anything within the framework. We are saying kanban practices and some of those tools can help you achieve flow within a scrum framework. And you get the benefits of the focus of scrum what scrum team practices that they're used to. Getting Started How will scrum team begin with what they do? What is one thing they can do is begin with Kanban in scrum. For instance, if the teams forecasts five stories done in the current sprint, but the team consistently misses one or two stories in a sprint, these Kanban metrics can help with the cause. Metrics for Scrum with Kanban For instance the Aging working process metrics used in a daily scrum so that can help the scrum team focus on that question with data, are we going to meet our forecast or not? If not the team can decide to focus and swarm on one item, get that item to done and continue to finish PBIs in the sprint. Hopefully this helps the team focus on getting to done, and issues that prevent the team from achieving their forecast. I would recommend the aging working process metric as a great way to start work with your scrum team using Kanban in your daily scrum. Other practices like visualizing your workflow and limiting WIP will help that focus as well. Conclusion If you are want to increase your teams focus, I recommend reading up on Scrum and Kanban. Even taking the Scrum with Kanban course, which goes in depth on methods to help Scrum team utilize metrics to increase their focus. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
In this episode, Dan Neumann is excited to be joined by special guest, Felipe Castro! Felipe is an expert on OKRs or Objectives and Key Results. He is an OKR trainer, speaker, and author who helps organizations transform how they use goals by adopting OKR! He has even created his own OKR tool called the OKR Cycle which is a simple method to avoid OKR’s most common pitfalls. As a master of all things OKR, Felipe Castro is here to speak about — you’ve got it — all things OKR! He goes over what OKRs are; important aspects you should consider; tips and advice regarding them; common mistakes, misunderstandings, and pitfalls; and how to overcome them. Key Takeaways What are OKRs? Stands for Objectives and Key Results An Agile approach to setting goals and creating alignment OKRs are about the outcome you want to achieve A framework for defining and tracking objectives and their outcomes Focuses on outcome-based planning as opposed to tracking tasks and activities Instead of giving the teams a feature to build, you are giving them a problem to solve or an opportunity to tackle Important aspects of an OKR: The objective should be memorable, compelling, motivating, and inspiring The ‘why’ comes from leadership and the team figures out the ‘what’ together Asking ‘so what?’ can help your team create better key results Give your engineers autonomy to solve problems Psychological safety is crucial for fostering an environment for high-performance teams Felipe’s OKR tips and advice: Start with targets that are regular goals (hard, but achievable) Don’t copy another company’s method around OKR — adopting OKR is a journey that will be different for every company Adapt the principles of OKRs for your specific context You need to unlearn, adapt, and evolve — especially if you come from an Agile background Common OKR mistakes, misunderstandings, and pitfalls: Treating it as a glorified to-do list Using OKRs as a copy of Jira (which doesn’t add any value) Seeing the role of engineers as assisting only with the coding rather than problem-solving That the sweet spot for achieving a target is 70% (which has zero science behind it) Mentioned in this Episode: Felipe Castro The Beginner’s Guide to OKR, by Felipe Castro SVPG (Silicon Valley Product Group) INSPIRED: How to Create Tech Products Customers Love, by Marty Cagan McKinsey’s Three Horizons Model Doc Norton “How Can You Test Business Ideas? Interview with David J. Bland,” by Felipe Castro Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr Felipe Castro’s Book Picks: Testing Business Ideas: A Field Guide for Rapid Experimentation, by David J. Bland and Alexander Osterwalder Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing, by Ron Kohavi, Diane Tang, and Ya Xu 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, Professional Scrum Trainer Sam Falco addresses the questions: "What does an effective Daily Scrum look like?" Introduction Recently, I saw a great question on Twitter from Ebenezer Ikonne. I love following him because he often asks thought-provoking questions about agility in theory and agility in practice. His question that day was about practice of daily standups. He asked, "Is there anyone in my network who has experienced a standup done well? And possibly consistently? now I'm curious... is there anyone in my network who has experienced/participated/facilitated/observed...a standup done well? possibly consistently? if yes, would you mind describing what it looked like? — Eb (@eikonne) April 26, 2020 I thought that was a great question because the Daily Scrum in Scrum is so often a ritual devoid of meaning other than people standing around giving a status report to someone else, often the Scrum Master. I responded with a short thread describing an experience with one of my teams, years ago that was very positive and a very effective use of the Daily Scrum. I think that it's worth repeating here and elaborating on. The team in question had been practicing Scrum for quite some time pretty successfully. We were delivering on a regular basis. We were delivering fairly high-quality stuff. But our Daily Scrum fell into the typical rhythm: The Development Team members took turns answering the classic three questions and then it would be on to the next person, without really collaborating. Because what we were doing most of the time was merely mentioning task IDs from our electronic tool: "Yesterday I finished 1037. Today, I'm going to pick up 1052 and if I finish that I'll get started on 1053. No impediments." We were following the Scrum Guide, but only in a rote fashion. The Product Owner was attending our Daily Scrum one day because we’d asked him to be there to answer some questions about the scope of one of the PBIs. He said he was really confused at what he had just seen and asked if it was really helpful to us. We realized that it wasn’t, and that we needed to change. The next day, we started at the top of the Sprint Backlog and talked about the first unfinished Product Backlog Item. We talked about what was remaining. What did we still need to do to get this PBI completed? Could we do it today? Failing that, what could we do to advance its progress? When we finished talking about that item, we'd move on to the next, and the next one after that, and so on, until our fifteen-minute time box expired. As we continued this practice, the effect was dramatic. We came out of the Daily Scrum every day energized instead of bored and disaffected. We were collaborating, and it led to further collaboration throughout the day. Instead of people working on their individual tasks in silos, we were working together to deliver that integrated increment. We started finishing PBIs faster as a result. We also very quickly realized that it was pointless to have more than a few PBIs in progress at any given time. We only had time to discuss three or four of them each day in the Daily Scrum. Previously, we had enacted a work-in-progress limit based on the number of tasks per person. Instead, we started limiting the number of PBIs in progress. That increased our focus on collaboration. It increased our focus on completing PBIs together, not getting tasks done. The change of focus helped our throughput increase, and it increased our quality. We changed from a mechanical practice of the Daily Scrum "by-the-book" to one that honored the spirit of Scrum, which is true team collaboration. Although we weren't individually answering the "three questions," we were still answering them--as a team. Conclusion If your Daily Scrum is stale or you feel as though it isn't providing value, try changing it up. Ask yourself how you can structure the discussion around what the whole team needs to do today in order to get a little closer to the Sprint Goal. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
In this episode, Dan Neumann is back with his co-host and colleague, Sam Falco! Today, they’re discussing whether or not a Scrum Master should be technical. Sam often finds himself being asked about this and has noticed many other people have a strong opinion for arguing either side of the coin. But, there’s more to it than just those two extremes! So, in their discussion today, Sam and Dan will be walking listeners through the various possibilities beside technical or not technical, and providing their advice on how to find the perfect balance between the two! Key Takeaways A technical Scrum Master: benefits, challenges, and advice: It can be beneficial to know the product and the knowledge domain your team is working in so that you can help the team when they have an impediment or are struggling with something Knowing the domain also makes it easier to help the Product Owner understand good backlog management, communicate to the development team, and encourage refinement to happen With technical knowledge, you can call out your team if they are sandbagging Challenges and pitfalls that can come with having a Scrum Master having a technical background is that there is a possibility that they might want to get in and do it themselves (which is not their role as a full-time Scrum Master) which can damage a team’s ability to self-organize and ability to innovate As a Scrum Master, if someone on the team approaches you and asks how to solve it, your response shouldn’t be to directly solve it, but to instead ask: “What are you going to try?” A Scrum Master who has no technical knowledge: benefits, challenges, and advice: They can be helpful in removing impediments because they have some knowledge about how things work (which may help them with knowing who to go to when there’s a problem in a particular area) The danger in not having any technical knowledge (but having domain knowledge) is that they may step on the Product Owners toes A non-technical Scrum Master could be challenging the team where they shouldn’t be Another concern is if the Scrum Master only knows Scrum and they’re only concerned with the team getting value out of Scrum Sam’s Scrum Master tips: A valuable skill for a Scrum Master is knowing when the team is confused or misunderstanding things and pausing to check and make sure that everyone is in the same place You have to be good at what you do and you have to be doing it to serve the team; not making sure everyone does everything by the book (without understanding why) As a Scrum Master, you should be asking yourself: “What are we doing here?”, “Why are we doing this?”, “How can I help my team?”, and “How can I serve best?” Take some time to reflect on: “Is the Scrum framework is being applied well?”, “Is the team delivering value incrementally?”, and, “Are the Scrum values present?” In Conclusion, should a Scrum Master be technical or not? The question itself is a bad premise because it implies either ‘yes’ or ‘no’ The answer is ‘yes’ and ‘no;’ it depends If you’re a Scrum Master that feels that your lack of technical knowledge is inhibiting your ability to serve your team, then it is okay to take some basic classes to understand the challenges your development team is facing If you’re a Scrum Master who is very technical, take some time to reflect on where your service is best applied and ask if yourself if you’re relying too hard on your technical knowledge Mentioned in this Episode: “The Expert (Short Comedy Sketch)” (Seven Redlines Video) Agile Coaches’ Corner Trainer Talk Episode: “The Risks of Having Scrum Masters as Schedulers” The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, by Don McGreal and Ralph Jocham Sam Falco’s Book Pick: The Janes: An Alice Vega Novel, by Louisa Luna 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, Professional Scrum Trainer Eric Landes addresses the questions: "Why doesn't Scrum care about good software development?" Introduction In my Professional Scrum Foundation classes, sometimes I'm asked, "Why doesn't Scrum care about good software development?" Kind of a funny question, right? Scrum was founded for software development teams and we don't really see that in the Scrum guide. So, for instance, if I look at the Scrum guide and search for terms like tester and development or continuous integration, we don't really see that in the Scrum guide. Scrum Does Care About Good Software My answer to this question to the students typically is Scrum does care about software development and one of the first classes from Scrum.org was for the Professional Scrum Developer course and Ken Schwaber created that, he's a software developer at heart and in his background. So very passionate about good practices there. And this course teaches Scrum along with good software engineering practices. Things like test driven development, continuous integration, those kinds of things where the foundation of the course and as with all courses you create an increment of software over the course of multiple Sprints. You create multiple increments of course. So, I'm a Professional Scrum Developer Trainer, love the course. And one of the things I do love about it is we keep incorporating fresh trends, trends like DevOps for instance, infrastructure is code, telemetry and monitoring. Those are all things that are incorporated now into that course. So Scrum.org is always modifying, inspecting and adapting as good Scrum should do on their courses. Build the Right Team The idea that Scrum doesn't care about good engineering practices though is not actually correct, but the Scrum Framework encourages development teams to have all the skills necessary to create that increment, that complete increment. So, for instance, if your team doesn't have the ability to do infrastructure as code, they don't have the right person so that you can get all the way to production, you need to get somebody on your team to do. Also, self-organization means we as a team have to decide which practices we're going to utilize. Scrum may not say specifically you need to use these technical practices and it's not prescribing them. But Scrum gives you some good basis from your Professional Scrum Developer course on what practices are good and go well with Scrum. Self Organize Scrum assumes that you as a self-organizing team are going to come up with those good engineering practices to create that finished increment that delivers what the customer wants and you're going to continue to keep up on good trends and what the software needs for your customer. So, in the end, Scrum does care about good software engineering practices, it's just not prescriptive about it. And if you're interested at all in the Professional Scrum Developer course, keep in mind it's been made for all different kinds of languages. Java, C sharp, JavaScript, React, those kinds of things can be modified and used with that course. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
Today on the podcast, Dan Neumann is joined by one of his favorite repeat guests, Christy Erbeck! Christy is a Principal Transformation Consultant at AgileThought and a Certified Dare to Lead™ Facilitator. She has over 25 years of experience in domestic and international consulting, training and coaching, and working in both software development and non-product-focused environments, including manufacturing (discrete and process), distribution, and sales and marketing. In this episode, Dan and Christy are taking a look at vulnerability — specifically, the six myths of vulnerability. As a Dare to Lead™ Facilitator, Christy has learned a lot about Brené Brown’s research which is grounded in understanding vulnerability. Vulnerability is important to understand as it shows up not only in our personal lives, but our professional ones as well. Christy will be walking listeners through what vulnerability is, the six myths of vulnerability, the truths behind the myths, and the work you can do to overcome the challenges associated with them. Key Takeaways What is vulnerability? Brené Brown’s definition is: the emotion that we experience during times of uncertainty, risk, and emotional exposure Oftentimes, we have a physical, visceral response to the feeling of uncertainty It is often connected to shame The six myths of vulnerability: Myth #1: “Vulnerability is weakness” When we see vulnerability in other people, it shows up as courage Courage is courage and vulnerability is courage Myth #2: “I don’t do vulnerability” When someone says this, it is armor (i.e. a facade); not reality Pretending you have no problems is a way of holding people at arm’s length People appreciate vulnerability and authenticity; it’s important to let people in This leads to distance, challenges, tough conversations, and a lack of emotional connection with others that we all need as humans Myth #3: “I can go it alone” Those who feel this way often feel a lot of shame with who they are Asking for help can be a very vulnerable thing to do As Brené Brown would say: this is B.S! We are hardwired for connection and need support from others Myth #4: “You can engineer discomfort out of vulnerability” There’s no way to intellectualize vulnerability as it is all about the emotion and the heart You cannot engineer uncertainty and discomfort out of vulnerability; You just have to embrace ‘the suck’ and go through it Myth #5: “Trust comes before vulnerability” Vulnerability drives trust; it enables trust to happen between two people in the first place We have to be vulnerable in order to build trust Myth #6: “Vulnerability is disclosure” Disclosing is not vulnerability; they are not one and the same I.e. it’s not just about telling others your deep dark secrets or oversharing on social media — that’s just inappropriate disclosure Where to learn more about vulnerability: Read the Dare to Lead book by Brené Brown Listen to the previous podcast on Dare to Lead™ Read the accompanying read-along workbook Join a class or go through the training program Listen in to an upcoming webinar Mentioned in this Episode: Christy Erbeck Brené Brown Brené Brown — Dare to Lead™ Agile Coaches’ Corner Ep. 32: “Christy Erbeck on Courageous Leadership” Dare to Lead Read-Along Workbook Dare to Lead™ Curriculum Unlocking Us Podcast with Brené Brown 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, Professional Scrum Trainer Sam Falco answers the questions: When should we hold our Daily Scrum? Introduction A student asked me, "When should we hold our Daily Scrum? Does it have to be in the morning?" The Scrum Guide tells us that "The Daily Scrum is held at the same time and place each day to reduce complexity," but it doesn't give any guidance on when. That means it is up to the Development Team to decide the best time for them. Here are some thoughts about the pros and cons of various times: Early Morning Daily Scrum First thing in the morning often works well, because we're starting fresh. Planning for the day together helps us get our heads back into the work. A challenge some teams have is that if it's too close to the start of the workday, commuter disruptions (traffic delays, kids need to be dropped off, and so on) can make it difficult for everyone to arrive on time. Also, sometimes it's hard to remember what happened yesterday. Mid-Morning Daily Scrum Mid-morning gives everyone time to get into the office, but if you wait too long, some people have already started working, and Daily Scrum can feel like a disruption. Lunchtime Daily Scrum One team I worked with held Daily Scrum right before lunch time. Everyone was in the office, and everyone was taking a natural break, so they didn't feel disrupted. However, they sometimes felt rushed when they had team lunches scheduled--everyone wanted to get moving before restaurants became crowded. End of Day Daily Scrum Near the end of the day means that what everyone did today is still fresh in mind, which can make planning tomorrow's work easier. But sometimes it means that there's too much focus on what we've done, and not enough on what we should do tomorrow. Scaled Agile Daily Scrum In a scaled environment, with multiple teams, it's probably a good idea to have all the teams' individual Daily Scrums around the same time, so that cross-team issues that emerge can be resolved more quickly. Want to Learn More or Get in Touch? Register for our upcoming AgileThought Virtual Community events: Resolving Agile Anti-Patterns in Remote Work See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at 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 return guest, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the Transformation Lead for Pivotal’s Atlanta Office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a Principal Consultant and Agile Coach at SCRUMstudy.com for over six years. In this episode, they’re going to be discussing portfolio management. A lot of times, Agility is thought of as team practices or activities that go around the team. And yet, there’s a lot of disruption and a lack of clarity that can happen when the higher-level contacts around those teams aren’t set. And a lot of times, that vision and strategy are being set at the portfolio level. So in Dan’s and Quincy’s discussion today, they shed some light on Lean and Agile portfolios in particular, as well as how portfolios fit into Agile ways of working and how it could help. They also provide actionable advice around how to keep the communication clear and transparent, key takeaways around the sustainability of the portfolio, and how to add Agile or Lean components to portfolio management. Key Takeaways How to add Agile or Lean components to portfolio management: Make sure that alignment is there (when you don’t have alignment from the portfolio level you run into a lot of challenges around teams not being clear about why they’re doing the work that they’re doing and the overall vision) Capture the vision through a framework (like OKRs) to add clarity Make sure that alignment is created and that there is a concise and clear vision that everyone can execute on Ensure that the team knows where the organization is going (so that they know what that the goals are beyond just delivering on a project) Good alignment from the top-down is critical You don’t want to spend time on products that are not going to bring value, so the portfolio of products needs to be constantly reprioritized and reevaluated Make sure that the team is not putting emphasis or focus on products that are not bringing value to the portfolio of products Ways to keep communication clear and transparent: Once alignment is established and everyone understands what the vision is, you then have to make sure that everything/everyone is very transparent about them Establish good, clear, and frequent communication Potential downfalls with portfolio management and agile transformations: forgetting to communicate on a frequent basis with those on the ground who are helping to bring this vision to pass (when people aren’t clear on the ‘why’ they don’t have as much of an invested interest in the outcome) Make sure communication is flowing both ways Value mapping can be a valuable method for making the value creation visible, which improves communication and understanding Within a portfolio of products, you can utilize Kanban boards which will show all of the products within that portfolio that are in flight and all of the teams that are supporting those products (they’re also highly visible to all the teams and it’s a nice transparent way for people to see how their team fits into the bigger picture) Key takeaways around the sustainability of the portfolio: Within the portfolio, you want to make sure that you’re looking at the cross-team dependencies and using an appropriate model that will allow the management of the portfolio to be sustainable To make things sustainable, you need to look at what the post-transformation sustainability and the overall sustainability model looks like Conduct change in a series of ‘push and let go’ Have a portfolio combined of different horizons (reference the ‘Three Horizons Method’) You don’t want to spend so much time keeping the lights on that you end up being a ‘blockbuster video’ (i.e. remember to look ahead at Horizons 1 and 2 as referenced in the ‘Three Horizons Method’) Mentioned in this Episode: Quincy Jordan OKRs “How to Avoid OKR Fake News — Felipe Castro at the OKR Forum Amsterdam 2019” Video Value Mapping McKinsey’s Three Horizons Model Quincy Jordan’s Book Pick: Unlearn: Let Go of Past Success to Achieve Extraordinary Results, by Barry O’Reilly 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, Professional Scrum Trainer Sam Falco answers the questions: Are there any types of work which aren’t suitable for Scrum? Scrum is for Complex Work Scrum lives in the area of complexity, where more is unknown than is known--about requirements, about how to fulfill them--and we have to apply an empirical approach in order to discover what we need to know and how to solve the problem. Scrum is Unnecessary for Simple Work Scrum would be unsuited to very simple work domains, where cause and effect are obvious to everyone, and all needed information can be known. This is the realm of "best practices," meaning there is one way to solve the problem; it is known to everyone involved, and following the known process will provide the expected result. As a concrete example, think of an oil change. In simple work, Scrum is unnecessary. Scrum is Overkill for Complicated Work For more complicated work that is not complex, more is known than unknown about the problem to be solved. This is the realm of "good practices." The problem is not as precise or easily defined as in simple work, and there are likely a few different ways to solve it. The example I always use is when I had to have a new roof put on my house. Everyone agreed on the requirements: Make my roof water-tight! But there are multiple types of roofing technologies, and my house's roof has a peculiar design. Those complications required analysis before we could decide on the appropriate approach. But my roofers could still use a predictive, plan-driven approach. For complicated problems, an empirical approach like Scrum could work, but it is likely to be overkill. Scrum is not Suitable when we Know Nothing Finally, Scrum is not likely to be suitable for a chaotic environment, when almost nothing is known about the problem to be solved or how to solve it. The classic example is a natural disaster, but I've also worked in an environment where no one could agree on what was wanted, and any plan we made could be invalidated at a moments' notice. Provide Feedback Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com. Want to Learn More or Get in Touch? Register for our upcoming AgileThought Virtual Community events: Kanban for Work and Home" See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
This week, Dan Neumann is joined by David Horowitz, the co-founder and CEO of Retrium! Retrium is an incredible tool that’s all about helping teams have engaging retrospectives that fuel continuous improvement. It enables Agile teams to have more effective conversations, discover new insights, and generate action plans by providing a toolbox of activities, a guided facilitation process, and a space to organize your retrospective documentation in one place. And speaking of retrospectives, today’s episode is going to be a retrospective deep-dive! Dan and David will be addressing some of the common misunderstandings and misconceptions around retrospectives, why you should hold retrospectives in the first place, some of the common anti-patterns with retrospectives (and how to combat them), and most importantly, how to have much more effective, engaging retrospectives! Key Takeaways What is the goal of a retrospective? To achieve actionable team learning It’s not just about improving productivity; it’s about getting the team to learn something and try something new (that, in turn, may lead to improvement) They’re not limited to Scrum or Agile (or really any team working together on anything using any process) Anti-patterns of retrospectives: Retrospective disillusionment (where someone has the sense that retrospectives are a waste of time and don’t want to show up to them) Lack of follow-through (if every retrospective led to actionable team learning that eventually led to productivity gains, people would show up and be engaged) Not being cautious of who you invite to the retrospective because if you can’t get the right people in the room, how are you going to retrospect effectively? (It is crucial to think through who you invite based on the circumstances that you’re facing) How to improve your retrospectives: Make sure who you invite is an opt-in that the whole team, through consensus, agrees on bringing in (if you don’t, you’re throwing psychological safety out the window) You can have multiple retrospectives and it doesn’t have to be at the end of the sprint — do what’s best for your team in any given situation Some people may speak too much at the exclusion of others — you can use various ways to level the playing field (one way is to ask everyone to write down their ideas on sticky notes or through ‘dot voting’) Some people feel more comfortable talking 1:1 so you could use something akin to ‘1-2-4-All’ before talking in a group Generally varying the way the conversation takes place is a good way of ensuring everyone has a chance to speak up Having a solid background in meeting facilitation is incredibly beneficial to the success of your retrospective Using open-ended questions (such as, “Does anyone have anything else to say about this?” and counting to ten) can be very helpful for giving everyone a chance to speak The Scrum Master does not have to facilitate the sprint retrospective If you’re facing low-engagement in your retrospectives you can increase empathy by opening up the meeting to others who might want to experience how difficult facilitation really is (it also gives you the chance to experience participating) It can be good practice to reach outside of the scrum team for someone who is a neutral party Ten surface-level conversations are not as effective as having a single deep-level conversation on a single impediment Narrow the scope down to the most minimal amount of impediments possible until you’ve proven that you can do more There are some great facilitation techniques to find the root cause analysis such as the ‘5 Whys’ and ‘Fishbone’ Create space for diverging before converging on a potential solution Rank your action items to get a list of prioritization of which one your team should try/focus on first (you can use the ICE Framework for this) Follow the energy of the team to understand what the team wants to focus on (if no one wants to work on it, it won’t happen) Uplevel the impediments your team is experiencing that it can’t solve Have information radiators in place Ask your team: ‘What, out of everything we just discussed, should we talk about intentionally, frequently, with everybody in the organization, as often as we possibly can?’ Mentioned in this Episode: David HorowitzDavid’s Twitter: @DS_Horowitz David’s Email: David@Retrium.com Retrium Agile Retrospectives: Making Good Teams Great, by Diana Larsen and Esther Derby The Retrospectives Academy by Retrium Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth Dot Voting 1-2-4-All Liberating StructuresRoot Cause Analysis The 5 Whys Fishbone ICE Prioritization Framework Badass: Making Users Awesome, by Kathy Sierra 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 of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: Do Sprint Reviews and Sprint Retrospectives Overlap? Why do we talk about what went well in a Sprint Review? In a Professional Scrum Foundations class I taught recently, one of my students asked if there was an overlap between the Sprint Review and the Sprint Retrospective. She was reacting specifically to the statement from the Scrum Guide that in Sprint Planning, “The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.” Doesn’t that discussion properly belong to the Sprint Retrospective? It’s easy to see how someone could be confused by that statement in the Scrum Guide. After all, a common format for Retrospectives is “What went well, what could have gone better, and what could we do differently?” The Intent of a Retrospective The difference is in the intent. In the Sprint Retrospective, the Development Team is focused on how it can improve its work. Whether that has to do with the way we work together, the tools we use, improving our Definition of Done, or some process we’re using, the goal of the Retrospective is to produce improvements it can introduce into the next Sprint. The Intent of a Sprint Review By contrast, the focus of Sprint Review is to collaborate on the most valuable thing we can do next with regard to the product. When the Development Team talks about what went well and what problems it ran into in this context, it is valuable feedback to the Product Owner and stakeholders about the nature of their work—facts that ought to be taken into account when creating and ordering Product Backlog items. Provide Feedback Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com. Want to Learn More or Get in Touch? Register for our upcoming AgileThought Virtual Community events: "Working Agreements Workshop" and Kanban for Work and Home" See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
This week, Dan Neumann is joined by George Dinwiddie, an Independent Software Consultant and Coach who works with organizations both large and small to develop software more effectively. He strives to help organizations, managers, and teams solve the problems they face by providing consulting, coaching, mentoring, and training at all levels. Dan and George will be taking a deep dive into George’s newest book, Software Estimation Without Guessing: Effective Planning in an Imperfect World, which addresses both the technical and sociological aspects of estimation. In this episode, George takes listeners through several chapters of the book, key points and best practices, as well as myths and misconceptions, all to help your organization achieve its desired goals with less drama and more benefit! Key Takeaways What is software estimation? A tool to estimate for the particular need you and your organization has Estimation in comparison to past experience and by modeling the work mathematically (or a hybrid of both) One of the big purposes of making estimates is for the business to build a look ahead and make decisions What are not estimations? Commitments Negotiations Plans “Estimations are wrong; if they were right, they would be called measurements.” How to estimate/estimation best practices: It’s important to track progress with your estimates to create a feedback loop (burn up charts are an easy way to do this) It’s okay to be wrong in the estimates With sprints, you want to be more 50/50 with the estimates Communication is critical Having contingency plans in place is a good idea Estimations are not the same as plans — estimate, and if it is critical, then put in some contingency buffers Allow for some space for the unexpected When you find out that your estimate is wrong then that means some assumption that you’ve based your estimation on is wrong (so there’s a lot of value in analyzing what assumption is untrue and to learn from it) For simple estimations (like how much work to take on for the next two weeks) you don’t need a lot of precision or accuracy Set near-term estimates Be clear about how far along you are (“...otherwise, you’ll be fooling yourself”) Have a good measure of what is done or not (you can use test automation for this) A model can be very helpful but if it doesn’t really track reality then it’s going to lead you astray The book’s purpose: It strives to help people work with estimates (given a desire to have things come out well) Provides a guide for comparison-based estimates It’s not very recipe-driven; it more so provides things to think about and options to consider A how-to on estimating for unknowns Rather than walking people through a series of steps, George’s book aims to help people think about what they’re trying to accomplish and how what they’re doing is accomplishing that Approaches to estimation: Enlisting Expert Estimators Using a model such as the COCOMO model (which is encoding how you compare it to other experiences) Utilizing function points Notes about the social side of estimation: Having in-person communication skills are just as important as your programming skills The better you can balance a concern for the needs of self, the needs of the other, and the needs of the context, the better things will be (even if the other person is not doing a good job of balancing them) Mentioned in this Episode: George Dinwiddie Software Estimation Without Guessing: Effective Planning in an Imperfect World, by George Dinwiddie Agile Estimating and Planning, by Mike Cohn Planning PokerFibonacci Sequence Agile2020 Conference James Grenning Software Estimation: Demystifying the Black Art (Developer Best Practices), by Steve McConnell COCOMO Model Burn Up Chart Gerald Weinberg Donald Rumsfeld — Unknown Unknowns Virginia Satir’s Concept of Congruence The Fifth Discipline: The Art & Practice of The Learning Organization, by Peter M. 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!
In this episode of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: Is there anything wrong with the Scrum Master scheduling and running all the Scrum events? Today’s question came up in a discussion about the perception that a Scrum Master’s responsibility includes scheduling all the Scrum events and running them all. Is there anything wrong with that being the Scrum Master’s responsibility? After all, the Scrum Guide says that one of the Scrum Masters’ services to the Product Owner and to the Development team includes “Facilitating Scrum Events as requested or needed.” Danger 1: Scrum Master as Admin Assistant While that’s true, I think there are hidden dangers in assuming that “as requested or needed” means “always.” The first danger is that it risks turning the Scrum Master into an administrative assistant to the team. Remember that a Scrum Master is also supposed to provide other services to the Scrum Team and to the organization at large. When a Scrum Master’s primary responsibility is to schedule meetings and run them, it necessarily means that the Scrum Master has to limit other activities that may provide higher value. Danger 2: Teams Will Not Self-Organize The second danger, and the more significant one, is that it may impair the team’s ability to self-organize. This is especially true in the case of the Daily Scrum. The Daily Scrum is a tool for the Development Team to self-organize around solving problems, and the Development Team is explicitly given responsibility for conducting the Daily Scrum. When this responsibility is shifted onto the Scrum Master’s shoulders, the Daily Scrum often transforms from a collaboration session into a round-robin status report of Development Team members to the Scrum Master. For the other events, it is valuable for everyone on the Scrum Team to develop the skills necessary to facilitate the Sprint Planning, Sprint Review, and Sprint Retrospective events. Conclusion There’s nothing wrong with a Scrum Master facilitating events “as requested or needed,” but if the Scrum Master is always needed and is always requested, it’s a sign that the Scrum Team needs to work on its self-organization. Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com. Want to Learn More or Get in Touch? Register for our upcoming web meeting "Staying Focused in a Remote Work World." See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
© 2020-2025 Ivy Podcast Discovery LLC
