
How do you deliver business value in every sprint?
03/24/20 • 4 min
In this episode of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: How do you that in the first Sprint? Don’t you have to build out all your infrastructure first?”
Prove Your Infrastructure Works One common question I hear from students in my Professional Scrum Master classes is, “How do you deliver business functionality every Sprint, including the first one? Don’t you have to build out all your infrastructure first?”It’s true that on a new software development initiative, there’s a lot of architectural and infrastructure work to be done at the beginning. But infrastructure alone doesn’t give stakeholders the information they need to decide whether to continue funding the project. You need to deliver some kind of business functionality to prove that the infrastructure you’ve built actually works. Stakeholders need to know that work they care about is happening.
Deliver Business FunctionalityWhat might that look like? There’s a great example in Ken Schwaber’s book Software in 30 Days. He describes a project to build a mobile banking app. In the first sprint, the development team did a lot of work on architecture and infrastructure, but they also provided a way to connect to a web portal, designed a basic front end, and created a landing page where customers would ultimately be able to log in. They didn’t even build the capability to log in—all you could do was hit the front page.
Obviously, you wouldn’t want to release that as a product, but it still provides some small slice of business value. It provides something for stakeholders to evaluate and collaborate on with the Scrum Team. What’s the response time? Does the design look good? What might customers want to see once they log in? Was it worth continuing this project? They decided that it was. And if they hadn’t, the team wouldn’t have wasted time building out a platform that was never going to be used.
Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at [email protected].
Want to Learn More or Get in Touch?Register for our upcoming web meeting "Virtual Lean Coffee | How To Thrive In A New Virtual World"
See available training courses at agilethought.com/training.
Visit the website and catch up with all the episodes at AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
In this episode of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: How do you that in the first Sprint? Don’t you have to build out all your infrastructure first?”
Prove Your Infrastructure Works One common question I hear from students in my Professional Scrum Master classes is, “How do you deliver business functionality every Sprint, including the first one? Don’t you have to build out all your infrastructure first?”It’s true that on a new software development initiative, there’s a lot of architectural and infrastructure work to be done at the beginning. But infrastructure alone doesn’t give stakeholders the information they need to decide whether to continue funding the project. You need to deliver some kind of business functionality to prove that the infrastructure you’ve built actually works. Stakeholders need to know that work they care about is happening.
Deliver Business FunctionalityWhat might that look like? There’s a great example in Ken Schwaber’s book Software in 30 Days. He describes a project to build a mobile banking app. In the first sprint, the development team did a lot of work on architecture and infrastructure, but they also provided a way to connect to a web portal, designed a basic front end, and created a landing page where customers would ultimately be able to log in. They didn’t even build the capability to log in—all you could do was hit the front page.
Obviously, you wouldn’t want to release that as a product, but it still provides some small slice of business value. It provides something for stakeholders to evaluate and collaborate on with the Scrum Team. What’s the response time? Does the design look good? What might customers want to see once they log in? Was it worth continuing this project? They decided that it was. And if they hadn’t, the team wouldn’t have wasted time building out a platform that was never going to be used.
Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at [email protected].
Want to Learn More or Get in Touch?Register for our upcoming web meeting "Virtual Lean Coffee | How To Thrive In A New Virtual World"
See available training courses at agilethought.com/training.
Visit the website and catch up with all the episodes at AgileThought.com!
Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!
Previous Episode

So You Want to Be an Agile Coach?
So you want to be an Agile Coach, huh? This week on the podcast, return guest, Christy Erbeck, is going to tell you everything you need to know if you’re looking to be a coach!
In case you haven’t caught Christy on a previous episode, she is a Principal Transformation Consultant at AgileThought and a Certified Dare to LeadTM 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.
Christy and Dan discuss what a coach is, what it takes to be a coach, how to become a coach, how to know when you are a coach, the differences between a coach and a trainer, as well as some coaching anti-patterns!
Key Takeaways
What is a coach?
It is a passion and mindset
As a coach, it is your duty to bring out the best in your team — you’re there to see what others cannot see
Someone who delivers value to your clients by creating and improving Agile processes within a team
What does it take to be a coach?
The ability to hold space for others to discuss tough subjects
A strong combination of hard and soft skills are required
Hard skills would be your ability to think strategically and tactically; clearly communicate up, down, and across the organization; your ability to tell the truth (even when it’s the last thing people want to hear); and to have real-world experience where you were not the coach
Soft skills would be a healthy sense of self, strong personal boundaries, the ability to empathize with others, a playful spirit, and natural curiosity
You should have had the proper training (for example: through CoachU or Lyssa Atkin’s SolutionsIQ)
Another important soft skill for a coach is to be the ‘wind behind their wings’ by releasing your ego and allowing the person you are coaching to be front stage
How to become a coach:
A new Scrum Master can experiment with coaching their team and should be there long enough to build a depth of experience — both good and bad to build a library of experience from
A coach should see multiple success and failure patterns
It’s important to have a strong foundation of your strengths and weaknesses, know how you’re going to respond to different situations, know what might trigger you in a setting, and to do ‘your work’ before coaching others to do ‘their work’
It’s important to not assume everyone else has the same success and failure patterns and experiences as you
When you’re walking into a new team as a coach you should always have a beginner’s mind (i.e. the perspective of being fully present in the moment and not projecting on historical experiences)
Anti-patterns of coaching:
Sending in a coach only when a team needs the help
When a manager is considered a coach of an employee (which sets both parties up for failure and is a conflict of interest)
Coaches that do not see their coachees as equals
Difference between a coach and a trainer:
A training stance would be that you are the expert in the given topic and those you are teaching are novices
Trainers impart knowledge to the trainees in a way that they can apply and grow from it
A trainer’s primary skill is to teach
In a coaching stance, you are there to help coachees uncover what they need to learn in order to become their best selves
A coach’s stance is not to be an expert in the person they teach; the person they teach should be the expert of themselves (a coach is just helping a person create space to allow them to follow and blossom)
How do you know when you are a coach? What should you continue to do?
As a coach, you should seek continuous improvement and adopt a lifelong learning mindset
You should continue to improve upon your hard and soft skills
If you want to be a coach, get a coach!
Understand that this is a journey
Ultimately, you will know when you’re ready to become a coach
Mentioned in this Episode:
Agile Coaches’ Corner Ep. 68: “Fixing Your Scrum with Ryan Ripley”
Fixing Your Scrum: Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller
Next Episode

Reasons Why Agile Transformations Don’t Stick with Andrea Floyd
Joining Dan Neumann today is Andrea Floyd, an Enterprise Agile Transformation Consultant within AgileThought! Andrea has 25 years of experience in software development and project management. She’s been an innovator that has a ton of experience leading multiple organization-wide Scaled Agile implementations as well as architecting innovative solutions, strategies, and roadmaps across many frameworks (including Scrum, Kanban, and Scaled Agile Framework).
Today, Dan and Andrea will be taking a look at some of the reasons why Agile transformations don’t stick! Sometimes transformations get announced with fanfare... but then die off with whimpers. Tune in so that you can reduce the chance of failure and give your teams the best chance of success!
Key Takeaways
Top reasons why Agile transformations don’t stick:
If the organization doesn’t understand why they’re doing a transformation and how it is going to impact them on an individual level there will be resistance (which will erode the intention behind the transformation)
There is a lack of identifying a team of champions throughout the organization
The train goes off the track; i.e. the ‘rubber-band theory:’ if you don’t continually reinforce positive behaviors and have a deep understanding of the ‘why’ behind the changes being made, it often becomes a series of checking off the boxes, which leads to a breakdown
If someone is not looking for anti-patterns and helping to coach others about the transformation, individuals will go back to their old ways
If you don’t put the right investment in your transformation or the change that you’re trying to create, you’re not going to see the results that you’re looking for
How to ensure that your Agile transformations stick:
You need to have an awareness of why you’re doing a transformation and it needs to be shared enterprise-wide
The transformation should be done holistically and in small pockets where you can actually start to demonstrate the value of the transformation
You need a perfect marriage between having enterprise-wide support and individuals who are fully on board
The message of how the transformation is going to impact individuals in a positive way needs to be reinforced often
You want to make sure there is transparency
Make what the transformation is trying to achieve and the progress that is being made towards that visible and known
Foster a community of believers who turn into supporters
Identifying a team of champions throughout the organization, which helps set up the transformation for sustainability (five is usually a good number)
Having someone to monitor or provide ongoing awareness around the transformation (i.e. a trusted advisor who can provide support to individuals who are wary about the changes)
It’s important for the organization to also take responsibility for moving things forward
Show the value and improvement of the transformation sooner rather than later
Get people excited about the changes by showing other teams’ success
Create a sustainable environment with sustainable practices and people that can actually continue after you leave
Mentioned in this Episode:
Real-World Kanban: Do Less, Accomplish More with Lean Thinking, by Mattias Skarin
Training from the Back of the Room!, by Sharon L. Bowman
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!
If you like this episode you’ll love
Episode Comments
Generate a badge
Get a badge for your website that links back to this episode
<a href="https://goodpods.com/podcasts/agile-coaches-corner-111882/how-do-you-deliver-business-value-in-every-sprint-5749137"> <img src="https://storage.googleapis.com/goodpods-images-bucket/badges/generic-badge-1.svg" alt="listen to how do you deliver business value in every sprint? on goodpods" style="width: 225px" /> </a>
Copy