Oct 11, 2019
Joining Dan Naumann today is AgileThought colleague and return guest, Sam Falco! Sam is an Agile Coach and Certified Scrum Professional with an extensive background leading Agile development teams.
Today they’re discussing under-promising and over-delivering: the what-not-to-dos for Scrum teams, their leaders, and the business they work for. Every now and then when Sam is teaching Scrum or coaching people on sprint planning he’ll say, “Select what you think you can do.” However, a lot of beginning Scrum teams will bite off more than they can chew because they’re way too optimistic. He often cautions to dial it back and then will hear the phrase in return, “Oh, we get it! Under-promise and over-deliver.” But that is as much of a lie as, “Sure, we can get that done,” and then not delivering. Businesses pick up on this dishonesty and it creates a tumultuous relationship between the development team, the leadership, and the business.
Tune in to get Sam’s key insights on how to build trust between the team and the business, the to-dos and not-to-dos for scrum teams and leadership, his cautions for new scrum teams and leaders, and his advice and actionable steps for building a healthy relationship between the team, the leader, and the business!
Key Takeaways
“Under-promising and over-delivering” and other unhealthy Scrum team mentalities perpetrated through the team or through the leadership:
- When the business fears that the team is under-committing or sandbagging the estimates they’ll create stretch goals for the team (which are often unhelpful)
- Theory X: The belief that people will not perform unless you force them to do so; that workers are lazy so you have to put systems in place to keep them working
- If the leader is making crazy demands, the team is going to end up overcommitting or sandbagging
What healthy Scrum teams and leadership looks like:
- Theory Y: Assembling together the people who want to help you accomplish your goals, give them the barometers, and then letting them do it
- They have an established sprint goal
- There is collaboration between the development team and the product owner
- The product owner and development team are collaborating to come up with product backlog items that are aligned with the sprint goal
- The leader or business does not drive the team as hard as they can to get as much as they can (which can lead to sandbagging)
Sam’s cautions to new Scrum teams and leaders:
- New Scrum teams need time to learn what they can do
- New Scrum teams tend to overcommit and add way more than they actually can do
- Dial it back a notch as a team — you can always add something later if you find you go through something too fast
Sam’s principles for successful teams:
- Technical excellence enhances agility (if you are always providing a done increment, you are always in a position to release and always in a position to pivot or change direction)
- A professional Scrum team that really observes Agile principles and values will be the most successful at knowing exactly what they can accomplish and being able to deliver on it
Actionable steps for building a healthy relationship between the team, the leader, and the business:
- Realistically forecast what you know you can deliver
- If you are on a development team and you’re using Scrum, give honest estimates and have the courage to say, ‘No, we will not commit to doing more than we can do.”
- Follow the three pillars of Scrum: transparency, inspection, and adaptation
- Establish a sprint goal that is meaningful between the business and the technology team
- Do enough planning during the sprint planning to build a credible forecast
- The business should be asking for the ‘what’ that they want, and as the technology team, give them some alternatives as to ‘how,’ then collaborate together to figure out the best option
- Have a well-established definition of ‘done’ that everybody understands, agrees to, and adheres to
- Never sacrifice your quality goals
- Use the ‘fist to five’ to vote on how confident the team feels on accomplishing a set goal
- As you go through the sprint, be honest with where you’re at
- In sprint review, discuss how problems were solved as well as the difficulties that were encountered (because stakeholders need to know that this is not magic)
- If you did not deliver, that should be the subject of your sprint retrospective
Mentioned in this Episode:
Sam Falco’s Book Pick:
Bad Blood: Secrets and Lies in a Silicon Valley Startup, by John Carreyrou
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!