Created with Sketch.
Agile Coaches' Corner
33 minutes | 7 days ago
Evidence-Based Management 101 with Sam Falco
In this episode, Dan and Sam are exploring the topic of evidence-based management, which was first mentioned in Episode 101, “Are Scrum Masters Expendable?” In that conversation, they discussed some of the things that Scrum Masters could be doing beyond the team and one of them is in helping manage the product suite. Dan and Sam unpack the concept of evidence-based management and share how this model can be used alongside Scrum to help people and organizations improve the way they deliver products and improve the value of their products. This episode is rather timely too, with the newest edition of the Evidence-Based Management Guide just being released on Scrum.org! If you’re new to EBM (or didn’t fully understand it before) there is no better time than the present to learn about it. Key Takeaways What is evidence-based management? It’s an empirical approach to help organizations EBM provides a framework to get a better feel for what is valuable so you can base the decisions you make on actual data (rather than gut-feeling) and run experiments that improve metrics Through intentional experimentation and evidence, EBM enables organizations to systematically improve their performance over time and refine their goals based on better information The EBM model: It has five key elements: A Strategic Goal — something important that the organization would like to achieve; this goal is big and far away with many uncertainties (similar to a product goal) — because of this, the organization needs a series of practical targets, like: Intermediate Goals — achievements which indicate that the organization is on the path to its Strategic Goal (the path to the Intermediate Goal is often somewhat uncertain but not completely unknown) (kind of like a release goal) Immediate Tactical Goals — critical near-term objective toward which a team or group of teams will work help toward Intermediate Goals (similar to a sprint goal) A Starting State — where the organization is relative to the Strategic Goal when it starts its journey A Current State — Where the organization is relative to the Strategic Goal at the present time EBM focuses on four Key Value Areas (KVAs): These areas examine the goals of the organization As an organization, you want to measure and evaluate these Current Value (CV) – the current value that the product is delivering today The purpose of looking at CV is to understand the value that the organization is delivering to customers and stakeholders at the present time Organizations need to be continually re-evaluating and looking at customer/user happiness, employee happiness, and investor and stakeholder happiness CV helps the organization understand the value that their customers or users are experiencing today Unrealized Value (UV) — additional/potential value the product could realize if it was pursued UV could be features that the organization hasn’t considered developed yet (but could) or markets that the product could serve (but doesn’t currently) The organization should be thinking about: “Can we get any additional value out of this product?” and whether or not it’s worth it Comparing UV and CV can help an organization decide whether or not they should continue investing in a product Time to Market (T2M) — how long it takes the organization to deliver new value The reason for looking at T2M is to minimize the amount of time it takes for the organization to deliver value (without it, the ability to sustainably deliver value in the future is unknown) Ask: “Are we spending too much time estimating?” Questions the organization needs to continually re-evaluate for T2M are: “How fast can the organization learn from new experiments and information?”, “How fast can you adapt, based on the information?”, and “How fast can you test new ideas with customers?” Ability to Innovate (A2I) — the effectiveness of the organization at delivering value The goal of A2I is to maximize the organization’s ability to deliver new features and capabilities that customers will find valuable When evaluating A2I, an organization should be asking: “What is preventing us from delivering new value?” and “What prevents customers from benefiting from the innovation?” Having a hypothesis and executing an experiment: A hypothesis is a proposed explanation for some observation that has not yet been proven or disproven After forming a hypothesis, run the experiments, and then inspect the results Was the hypothesis proven or disproved? Once you have this data you can evaluate it and make adjustments as needed “Explicitly forming hypotheses, measuring results, and inspecting and adapting goals based on those results are implicit parts of an agile approach. Making this work explicit and transparent is what EBM adds to the organizational improvement process.” — EBM Guide Mentioned in this Episode: Evidence-Based Management Guide | Scrum.org Agile Coaches’ Corner Ep. 101: “Are Scrum Masters Expendable?” Agile Coaches’ Corner Ep. 78: “Exploring OKRs with Felipe Castro” Three Horizons Framework The Anarchy: The East India Company, Corporate Violence, and the Pillage of an Empire, by William Dalrymple The Creative Habit: Learn It and Use It for Life, by Twyla Tharp Hillbilly Elegy: A Memoir of a Family and Culture in Crisis, by J.D. Vance 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!
34 minutes | 14 days ago
What's new with Scrum?
Today marks an exciting day; the new Scrum Guide was released just this last Wednesday and marks some big, notable changes! The release of the new guide also marks Scrum turning 25 years old! Join Dan Neumann and Sam Falco in this episode as they discuss all of the changes from the previous 2017 to the new 2020 guide; share their thoughts and key takeaways; and provide further insight on what some of these changes could mean for Scrum, Scrum teams, and Scrum Masters going forward. Key Takeaways Notable changes to the new 2020 Scrum Guide: From 17 pages to 13 pages Clarification on the daily Scrum; why you have it and what its purpose is The statement about the immutability of Scrum went from being an endnote to being placed front and center They’ve taken out all IT-specific language; the 2020 Scrum Guide is explicitly reaching out to an audience beyond IT and software development “Developer” no longer means “coder”; it applies to anyone developing a solution (if you are developing a product, you are a developer) The new language used in the guide will make it easier to teach and apply to a broader audience (such as marketing campaigns, artistic endeavors, etc.) Doing away with two levels of teams (no more Scrum team which has a development team); it’s just a Scrum team now All roles are within the Scrum team (i.e. the Scrum team is responsible for all product-related activities) In the 2017 version, it spoke about potentially releasable increments but in the 2020 version, it says the increment must be useable A greater emphasis on the fact that the Scrum Master is accountable for the Scrum team’s effectiveness by enabling the Scrum team to improve its practices within the Scrum framework Clarification around one of the ways that the Scrum Master serves the team: “by causing the removal of impediments” (vs. “removing impediments” in the 2017 vers.) From “self-organizing team” to “self-managing team” Commitment has taken on a greater significance: each of the three artifacts now comes with an associated commitment Before, the commitment on the Scrum team was to the sprint goal; now, the product backlog has its own commitment (the product goal), the sprint backlog retains the sprint goal as a commitment, and the increments commitment is the definition of done This change emphasizes the importance of a long-term vision and eliminates the previous criticism that Scrum is just about going sprint-to-sprint Closing thoughts: Scrum itself inspects and adapts Jeff and Ken are hearing and listening to what people are saying about the Scrum Guide and are striving to help people understand it better It continues to evolve at a good rate Be sure to go read it through start-to-finish! Mentioned in this Episode: The 2020 Scrum Guide Launch Event Ken Schwaber’s 2020 Scrum Guide Teaser Blog Post 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!
27 minutes | 21 days ago
Losing Control to Gain Value with Quincy Jordan
Dan Neumann is joined once again by Quincy Jordan; Principal Transformation Consultant at AgileThought! Today, they’re exploring the concept of losing control to gain value. Though the concept of “losing control” may sound a bit frightening, it is actually the most invaluable thing you can do as a leader of a team! Oftentimes, there are habits of control that can greatly impact a team’s ability to self-organize, mature, and deliver value. With less control, the team is able to produce better value. In this episode, Quincy outlines the many interesting facets of losing control to gain value. He shares what this loss of control is, why losing control is key to gaining value, what you can do as a leader to let go of control and support your team in creating value, and much more! Key Takeaways Why is it important to lose control to gain value? If you’re wanting to gain/produce value, you can run into roadblocks if you have a desire or habit of control Oftentimes, leaders and senior leaders (especially managers, tech leads, etc.), primarily in the context of Scrum, struggle with a habit of control which can block them from achieving their desired result of more value There are many habits of control that can impact the team’s ability to self-organize and deliver value The leader can become accustomed to controlling the team’s narrative, leading the team to build mechanical habits (which doesn’t encourage self-organization, free-thinking, or experimentation) Leaders are often inundated with fear that if they allow the team to self-organize they’ll make the wrong decisions or won’t produce as much (but this needs to happen in order for the team to mature properly) When people want to direct and control what the team does (i.e. how they figure things out) they are hindering them from producing better results or better value (your team is full of smart people that can figure things out!) If the team only knows the objective and they don’t understand the “why,” there is the potential that they’ll begin to do stuff mechanically (because it cripples them from making decisions in line with what the expectations are) If you are directing your team’s day-to-day activities, you’re actually limiting/capping what they’re capable of Exerting control of their activities makes you become the bottleneck Why can a loss of control lead to more value? Shifting the focus from trying to control what people are doing to instead trying to understand what they’re intending to do allows the team to mature By removing yourself as the bottleneck of your team you’re allowing them to have room to grow and mature Tips for leadership in letting go of control to support the team in creating value: As a leader, it is important to not only understand the approach that’s being taken and where the parameters are/where the boundaries lie, but also that the team has the ability to self-organize and to figure out the best way to accomplish what is going to produce the most value Your team just needs to know what the objective is that they’re trying to achieve (any more control is a hindrance) It is critically important for teams to understand the “why” behind what the objective is (if they do, 9/10 times they’ll produce the best results and the best value that they’re capable of!) Instead of controlling or directing the workflow, leaders should be focusing on improving the environment in which people work, closing skill gaps, and removing organizational impediments As a supervisor or tech lead, you should serve as a mentor or be there as a resource for the team (i.e. a go-to point for team members if they get stuck or need some direction on finding resources that will help them do their work) It’s important to be there as a support but not a person to direct day-to-day activities as a leader Leaders at a program, VP, or portfolio level need to make sure that they’re supportive of an agile ecosystem In David Marquet’s Turn the Ship Around!, he talks about intent-based leadership (where the team comes to leaders, not with a request for direction, but instead with a: “I intend to do x, y or x,” which gives the leader a chance to inquire if appropriate. Eventually, this leads to less checking as the team demonstrates competency and consistency of delivery) Pivoting to intent-based leadership is only possible if the leader makes it clear what the outcome is that they’re expecting How to balance giving your team room to grow with safety measures: In taking a Scrum approach, there are many benefits (because the framework gives solid boundaries that allow for a good balance of self-organization and accountability) Accountability to one another (and themselves) is created by having daily Scrums The sprint review adds balance because nobody is going months at a time without feedback There is a regimen within the flexibility that the Scrum framework provides Mentioned in this Episode: Quincy Jordan Agile Coaches’ Corner Ep. 101: “Are Scrum Masters Expendable?” Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David Marquet 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!
28 minutes | a month ago
Celebrating Two Years of the Agile Coaches’ Corner
In celebration of the two-year anniversary of the podcast, Dan Neumann is joined by Sam Falco, co-founder of the Agile Coaches’ Corner podcast. In the theme of continuous improvement, Dan and Sam take a look back on the last two years of the podcast and reflect on all that they’ve learned about podcasting and agility. They also invite on some of their favorite past guests and AgileThought colleagues to share their own biggest takeaways and lessons learned from the past two years on the theme of agility. Andrea Floyd, Agile Transformation Consultant; Adam Ulery, Senior Agile Coach; Quincy Jordan, Principal Transformation Consultant; Steven Granese, Managing Director of the Transform Practice; and Michael Guiler, Agile Consultant. Key Takeaways Andrea Floyd Key lesson: the importance of the Agile mindset and an Agile culture coupled with any Agile journey “What does it mean for us to be successful?” “What will that take from a mindset and culture perspective?” — Andrea Floyd Tools and techniques: exercises around value stream mapping, understanding what value means to your customers and users, design-thinking techniques around customer journey mapping, good leadership, and commitment from the whole organization Adam Ulery Key lesson: the importance of having committed top-level leaders in an Agile transformation The buy-in of leadership in a transformation is key (it makes the difference in creating real change or giving up) Drawbacks that occur without leadership buy-in: change will only occur in small pockets at best, more than likely it will flounder and never transform the people and the way they work Tools and techniques: in order for leaders to transform themselves they must be committed and willing, step out of their comfort zone, push through fears, and commit to change In summary: it is important to have top-level leaders that are committed to the transformation and are committed to change Quincy Jordan Key lesson: Agile is Agile (it has transformed, evolved, and adapted over the years) It used to be considered strictly for software development but has now been taken outside of IT; into HR, marketing, etc. The overall thinking has made a big splash in non-IT environments A challenge with agility being adopted into non-IT environments: sometimes business and leadership have a misconception that agility is only IT so they believe it is not relevant to them When agility ripples outside of IT, it can be really powerful Michael Guiler Key lesson: that the business side has really begun to take hold of agility What has caused the shift from technology-driven agility to business-driven agility: the entire world has fundamentally begun to understand that agility is key (i.e. “We can’t just have really detail-oriented plans with a command and control structure and be able to compete in today’s world” — Michael Guiler) Now, business wants to build an environment where they can really pivot on a dime and compete — and agility is the way to do that Steven Granese Key lesson: it is very difficult to define what agility is — especially with large organizations There are a lot of different ideas and definitions about what agility is It can be hard to define what problem the client is trying to solve and why agility would help them How Steven has seen the problems that clients are trying to solve change over the years: 1) From a focus on speed (the speed with which they need to continuously adapt) to a focus on market changes (it’s the organizations that focus on market demands that are the ones having the most success) 2) There used to be more of a concern about leaning too much on tooling and automation but now it has become so good and there is so much more that is possible now due to the tools that are available Sam Falco Key lesson: Agility spreads beyond IT — even to a personal level “Even on a personal level, I have taken a lot of the principles and ideas — and even the practices of Scrum — into my own personal life. I use Scrum on a weekly basis; I do one-week sprints for myself.” — Sam Falco Sam has lowered his personal work-in-progress limit from three to two and his throughput shot way up He’s learned how to apply agility in all sorts of situations Dan Neumann Key lesson: the power of collaboration (specifically, the value of collaborating with people) You can riff off each other if a client isn’t quite hearing what one of you is trying to say Diversity of perspective is tremendously valuable (just like on any well-functioning team) Mentioned in this Episode: Steven Granese Andrea Floyd Adam Ulery Quincy Jordan Michael Guiler The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning 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!
27 minutes | a month ago
When Things Are Going So Well That You Just Don’t Notice
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!
30 minutes | a month ago
Halloween Special: The Scrum Treehouse of Horrors!
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!
34 minutes | 2 months ago
Are Scrum Masters Expendable?
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!
35 minutes | 2 months ago
What Does Shifting to a Teal Model Mean? with Simon Holzapfel
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!
32 minutes | 2 months ago
What is Professional Scrum?
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!
34 minutes | 3 months ago
When Do You Need a DevOps Coach?
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!
30 minutes | 3 months ago
Cloud Adoption and Migration with Daniel Novelo
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!
24 minutes | 3 months ago
Exploring Causality and AI-Driven Digital Transformation with Dr. Jerry Smith
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!
11 minutes | 3 months ago
The Power of Words with Dan Neumann
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!
26 minutes | 3 months ago
Scaling and Transformation: Leading Your Org to Business Agility with Steven Granese and Quincy Jordan
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!
27 minutes | 3 months ago
Factoring Culture into Your Agile Transformation with Quincy Jordan
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!
19 minutes | 3 months ago
How to Make AI Work in Your Enterprise with Dr. Jerry Smith
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. 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 science 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 is 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 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 About 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. 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!
5 minutes | 4 months ago
How do you measure a Scrum Team's Performance?
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!
19 minutes | 4 months ago
How to Effectively Use Agility Metaphors with Dan Neumann
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!
22 minutes | 4 months ago
What Makes a Great Scrum Master? with Quincy Jordan and Christy Erbeck
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!
39 minutes | 4 months ago
How to Lead in Times of Crisis with Christy Erbeck
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!
Terms of Service
© Stitcher 2020