
Sign up to save your podcasts
Or


This week on the podcast, Dan Neumann is joined by AgileThought colleague and return guest, Eric Landes! Eric Landes comes from a DevOps background and originally started as a developer. Currently, he serves as a Senior DevOps Consultant, ALM Director, and Solutions Architect at AgileThought.
In today’s episode, Dan and Eric are discussing organization transformation. If you haven’t already heard Agile Coaches’ Corner ep. 59, “The Four C’s of Organizational Culture,” you should tune into that first, as this episode makes reference to it. Today’s episode, however, is asking the question of whether an organization should start by implementing a practices-based change or a culture change when they’re looking to transform.
Is starting with changing the culture a more practical approach, or, is keeping the culture as it is and incorporating more Agile practices overtime more beneficial? Tune in to hear Dan and Eric’s take!
Key Takeaways
A culture change approach vs. a practices-based approach:
A practices-based approach generally refers to making small changes to behavior
A culture change is much more of a big bang whereas a practices-based approach is more of an Agile journey
A culture change is more of a plan-driven, A-B transformation and a practice approach is more an incremental, step-by-step process
The argument for taking a practices-based approach to transforming an organization rather than changing the culture first:
The ability to change practices and shift the overall mindset without changing the culture is a more achievable place to start — it’s also more of an Agile mindset/method (because you’re starting with a practice, seeing how it helps, measuring it, and then moving forward)
Practices get modified over time so it can be beneficial to be more Agile as your organization is going through a transformation (rather than going for that “big bang” that a culture change would call for)
Putting practices into play (such as test-driven development, breaking down product backlog items, or implementing more Kanban metrics) can help the organization discover what fits and what doesn’t fit into the current culture and also what delivers the most value to the customers
Using metrics and practices will lead to changes in thinking around how the organization is delivering
Mentioned in this Episode:
Eric Landes (LinkedIn)
Agile Coaches’ Corner Ep. 59: “The Four C’s of Organizational Culture”
The Reengineering Alternative: A Plan for Making Your Current Culture Work, by William Schneider
Professional Scrum with Kanban Certification
Eric Landes’ Book Picks:
Training from the Back of the Room! by Sharon L. Bowman
The Color of Compromise: The Truth about the American Church’s Complicity in Racism, by Jemar Tisby
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
On today’s podcast, Dan Neumann is joined once again by 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.
On top of all of Christy’s licenses and titles, she is also a Certified SAFe® Program Consultant — which is also the topic of today’s show! There are a lot of horror stories around SAFe implementations because, in many cases, the original intent has been corrupted. So in this episode, Christy is breaking the SAFe framework down for listeners. She’s busting the myths that have given SAFe a bad rap and then providing her tips for a successful and effective implementation of SAFe!
Key Takeaways
What is SAFe?
SAFe is a framework for predictability at scale
Empowers complex organizations to achieve the benefits of Lean-Agile software and systems development at scale
Christy busts some myths regarding the SAFe:
“Waterfall disguised as Agility” — not true; it is a framework with elasticity in how it can be implemented
“It’s very prescriptive” — though there is an overarching framework and path that is laid out, the fundamental mindset underneath it is Agility
“SAFe stops at training the leaders about velocity” — untrue! Just train the leaders and just get started
“You can just put aside vulnerability” — you cannot, so instead get in front of it and break down the walls by discussing the discomfort and change that comes with implementation
“SAFe always goes wrong and completely goes against an Agile mindset” — SAFe as a framework does not do this; it’s perpetrated by the consultants and the organizations that don’t fully commit to implementing it
How to ensure your SAFe implementation is effective and successful:
Start small and ‘nail it before you scale it’
Start with training your leaders and give them a compelling ‘why’
Create a Lean-Agile center of excellence where you can bring everyone together to help identify the system-level items and issues that are going to need to be addressed as you all move through the implementation roadmap
As a manager, reject bad plans (this is very beneficial towards getting more predictable deliveries)
Implement the events within SAFe well (and safely) so that your organization can be set up for success
Understand Lean thinking
Establish safety within the team and the organization to build trust
Stay nimble
Listen to what the client needs, not what you think they need
Mentioned in this Episode:
Christy Erbeck’s LinkedIn
Scaled Agile Framework
Certified SAFe® Program Consultant
Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!”
Agile Coaches’ Corner Ep. 22: “The Role of Managers in Agile Organizations with Esther Derby”
Brené Brown
Brené Brown — Dare to Lead
Start With Why: How Great Leaders Inspire Everyone to Take Action, by Simon Sinek
Relentless Forward Progress: A Guide to Running Ultramarathons, by Bryon Powell
How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas W. Hubbard
Christy Erbeck’s Book Pick:
Master of One: Find and Focus on the Work You Were Created to Do, by Jordan Raynor
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
This week on Agile Coaches’ Corner, Sam Falco is taking over the podcast! He’s gathered up some interesting questions on the topic of Scrum through Quora and will be going through them one by one to give his insights and key points regarding each!
Tune in to hear Sam’s take on what the purpose and benefits are of a daily Scrum meeting, the best way to resolve the issue of a team member taking up too much time at the daily Scrums, and whether or not he thinks the role of the Scrum Master should be temporary in a Scrum team until the team is self-organizing!
Key Takeaways
What is the purpose, as well as the benefits, of a daily Scrum meeting?
The Scrum guide states that the purpose is for the development team to plan its work for the next 24 hours
To inspect the work the team has done since the last time they’ve met and adapt the plan accordingly to achieve the sprint goal
It’s all about helping the development team to meet the sprint goal
You should be getting a new plan out of the daily Scrum meeting that takes into consideration the new data you’ve gathered since the last time you met
A team member is taking too much time at daily Scrums — what’s the best way to resolve this issue as the Scrum Master?
Firstly, remember the purpose of the daily Scrum: to inspect the work and adapt the plan to achieve the sprint goal, and ask: is that still happening in the allotted timeframe? If it is, it’s really not a problem for the Scrum Master to solve
It could be a real problem when it’s leading to the daily Scrum taking way too long, people begin ‘checking out’ in the middle of it, or it’s preventing the team from self-organizing
Don’t jump in right away as the Scrum Master; your role is to simply make sure the development team has the event and teach them to keep it in the timebox
Consider pointing out that the meeting has been taking too long to the team and allow them to solve it themselves
Consider coming up with a signal when someone is taking an unnecessary deep dive into a topic (but make sure the team isn’t relying on this method to the point where they’ll struggle to self-organize)
Bring up the problem at a retrospective, let the team decide whether it’s a problem or not and how they want to handle it, and then give them guidance based on that feedback
Should the role of Scrum Master be temporary in a Scrum team until the team is self-organizing?
The Scrum Guide argues that no, it wouldn’t be Scrum, because if you do away with any of the rules and roles in Scrum (though possible) the result becomes something that is not Scrum
The presence of the Scrum Master on the team will vary depending on the team, but early on it is especially important that they need to be involved quite a bit
As the team matures and learns to self-organize, the Scrum Master could shift their role from working on the rules of Scrum and how to apply them to help the team determine better engineering practices
It’s not practical to think that the team will never need their Scrum Master again (as the Scrum Master does more than facilitate meetings and teach the Scrum framework)
Ultimately, it’s important that the team is able to call upon their Scrum Master
Mentioned in this Episode:
Quora
The Scrum Guide
Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust, by Ken Schwaber
The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, by Gene Kim, Patrick Debois, John Willis, and Jez Humble
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
Welcome to the first episode of 2020! In this first episode back into the new year, Dan Neumann will be taking a look at organizational culture.
It’s often said in the Agile community that the culture has to change within an organization for Agile to take place. When it is thought of like that, changing culture can be a pretty tall order. But in William Schneider’s book, The Reengineering Alternative: A Plan for Making Your Current Culture Work, he outlines a framework to make your current organization’s culture work. In this episode, Dan will be taking a look at the key concepts of Schneider’s framework and exploring the four cultures he categorizes every organization into — also known as the four Cs.
There’s no one-size-fits-all for the perfect culture to support Agility in an organization. Your results will be much more effective if you work with your organization’s current culture — so be sure to tune in to learn how to fully leverage your current organization’s culture!
Key Takeaways
The four Cs of organizational culture:
Collaboration:
Similar to a family in their social nature
Derives their strength through affiliation
Strengths: very team-focused, participative, values diversity, and are a generally fairly trusting organization with lots of open and honest communication
Weaknesses or downsides (when the pendulum swings too far into a collaboration-based culture): the harmony of the group may be valued over the frankness that’s needed to talk about tough issues, and there may be too much compromising and too much movement towards consensus building and collaboration versus being clear about how decisions get made and collaborating within the defined framework (i.e. trouble making and sticking to decisions)
Important to consider: collaboration culture can be great, but just make sure the pendulum hasn’t swung too far to the point where the organization is ignoring misbehaviors or shortcomings; instead, tackle them head-on within the culture
Control:
Similarly modeled to the social institution of the military
Power-oriented
Leaders are awarded for power reasons
Strengths: emphasizes strength; very effective at planning; and there are clear systems, policies, and procedures in place
Weaknesses or downsides (when the pendulum swings too far into a control-based culture): people will begin to rigidly adhere to the policies and practices without ever stopping to improve them, innovation may stop within the organization, and it becomes difficult to have generalists (which can be very important on Agile teams)
Important to consider: control culture is not anti-Agile, but if you are looking to embrace the values and principles of Agile, you have to keep the culture in perspective
Competence:
Similar to the social institution of a sports team or university
Rewards staff that are achievement-focused
Can be very creative and visionary and values craftsmanship
Strengths: organizations are task-driven, tend to be very efficient and objective, and have high-performance standards
Weaknesses or downsides (when the pendulum swings too far into a competency-based culture): individuals may go on ‘technical tangents’ and are spending too much time in ‘analysis paralysis’ (i.e. trying to find the ‘perfect’ solution instead of moving forward with building), overplanning, and may become too emotionally controlled with no willingness to deal with interpersonal conflict
Important to consider: make sure that the organization’s culture is not striving to win at all costs but instead focusing on completing tasks and achieving objectives
Cultivation:
Similarly to a religious institution in their social nature
Values growth and self-actualizing
Generally non-profit organizations
Strengths: these organizations tend to be personal, nurturing, inspiring, fairly subjective, help people self-actualize to be their best, and provide lots of opportunities for growth and development (which can be very helpful for an Agile team)
Weaknesses or downsides (when the pendulum swings too far into a cultivation-based culture): way too much self-expression, too much time focused on feelings and worrying about the slightest offense that may have been taken, favorites may be played in the organization, and emotions may begin to trump the place of data
Important to consider: make sure the pendulum doesn’t swing too far into cultivation as the notions of measuring and managing would have a hard time really taking root
Mentioned in this Episode:
Agile Coaches’ Corner Ep. 58: “How to Get Past the Two-Week Shelf Life of Your New Year’s Resolution”
The Agile Manifesto
The Reengineering Alternative: A Plan for Making Your Current Culture Work, by William Schneider
Susan DiFabio’s LinkedIn
Team of Teams: New Rules of Engagement for a Complex World, by General Stanley McChrystal, Tantum Collins, David Silverman, and Chris Fussell
How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas W. Hubbard
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
With just days before the new year, your host, Dan Neumann, figured it’d be the perfect time to discuss New Year’s resolutions! Many people set New Year’s resolutions, but the problem is: they don’t keep them. Some research even says that only 8% of people actually achieve the goal they’ve set out for. Many of these goals don’t even reach a two-week shelf life before many people give up.
But why is this? In today’s podcast, Dan Neumann sets out to find the answer! He takes a look at what’s inherently flawed about this concept of New Year’s resolutions, gives his insights on how you can make your New Year’s resolution more likely to stick, and even shares some of the goals and resolutions related to the podcast itself!
Key Takeaways
What is inherently flawed about the concept of New Year’s resolutions?
It’s too long of a goal; you’re setting a goal for the next 365 days!
January 1st is actually a pretty arbitrary start date
A lot of people don’t plan for what to do in a situation that challenges their New Year’s resolution (a lack of planning can majorly impact your ability to follow-through)
How to get your New Year’s resolution to stick:
Set a shorter duration; it doesn’t have to be for the next year
If two-week sprints work well for you, you could work similarly on this cadence
Differentiate between a resolution vs. setting a goal
Use the S.M.A.R.T goal framework (S= Specific, M= Measurable, A= Achievable, R= Relevant, T= Time-bound)
Set your new goals on a better starting date that makes more sense for you (such as on a Monday or the start of a new month)
Brainstorm some ways to set milestones for yourself
Plan for what you’re going to do when you run into a challenging situation
Find an accountability partner
Each week, each ‘sprint,’ or each month, reflect on how to become more effective and adjust accordingly (similarly to the last principle in the Agile Manifesto)
Mentioned in this Episode:
“This is the Day You’re Most Likely to Let Your New Year Fitness Goals Slip,” by Runner’s World
S.M.A.R.T Goals
The Agile Manifesto
Want to Learn More or Get in Touch?
Visit the website and catch up with all the episodes on AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
From the publisher's feed