Scrum Master Q & A with Sam Falco

10/18/19 • 33 min

This week on the podcast, Dan Neumann is joined by his collaborator, Sam Falco! Together they’re going to be tackling three Scrum-related questions that they dug up on Quora.

Sam finds himself running into these particular questions fairly frequently. In fact, every new client seems to have a set of similar questions! So if you’ve ever pondered, “What is better: one-week or two-week sprints,” “What is the scrum master’s role,” “What are the tasks that a scrum master has to perform,” or “What are the first things a scrum master should do when starting at a new organization?”... tune in!

And if you have any questions you’d like to hear answered in a future episode, you can email them to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Key Takeaways

“Do you prefer one-week or two-week sprints? And why?”

The Scrum guide says up to a month

Sam doesn’t have a preference between one-week or two-week sprints as it depends on what the situation (and organization) calls for

The key is to balance how much time it will take for the development team to do the work with the risk the organization is willing to absorb by not releasing (i.e. if an organization can wait three weeks without messing with the scrum team’s sprint goal — then three weeks is a good length)

Sam recommends that teams brainstorm their definition of ‘done’

Either way, it’s important for the organization and team to maintain focus for the sprint duration, no matter the length

A short sprint means there’s less to plan, less to review, less retrospective, and it scales more linearly

All-in-all: it really depends!

“What is a scrum master role? And what are the tasks that a scrum master has to perform?”

Scrum masters are responsible for coaching the product owner, the development, and the organization

Through transparency, inspection, and adaptation they should be working to improve the system over time

They should be always be asking: ‘What value are we getting out of this activity?’

They have to remove impediments for the scrum team (once it is clear that the team cannot clear them)

They must coach and protect the team

They should help those outside of the team to understand how to interact with the team

They need to coach the team and the organization how to work in Scrum

They need to work with the organization on how to spread Scrum (as well as agile values and principles)

The scrum master has to do whatever is necessary to help the team be successful

“What are the first things a scrum master should do when starting at a new organization?”

When you’re coming into a new organization as a scrum master, you should give the team that you’re going to work with a reason to trust you (Sam recommends creating a “mind map” of yourself and modeling some vulnerability)

Have a group AMA as well as one-on-ones with each member of the team to build trust

Ask the team what their challenges are, listen to them, and address those first

Build a report with the dev team and the product owner

You should be networking within the organization and learn who’s who

If it’s a completely new organization, you want to establish good Scrum practice from the get-go, explain the ‘why’ behind the Scrum Guide, and make sure that the team is engaging in good Scrum practice

Mentioned in this Episode:

Quora

Mind map

Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!”

Deep Work: Rules for Focused Success in a Distracted World, by Cal Newport

Agile 2019 Conference

Quiet: The Power of Introverts in a World That Can't Stop Talking, by Susan Cain

Quora Questions:

“Do you prefer one-week or two-week sprints and why?” Asked by Sara Morsi

“What is a scrum master role? What are the tasks that a scrum master has to perform?” Asked by Rashmi Pathak

...

This week on the podcast, Dan Neumann is joined by his collaborator, Sam Falco! Together they’re going to be tackling three Scrum-related questions that they dug up on Quora.

And if you have any questions you’d like to hear answered in a future episode, you can email them to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Key Takeaways

“Do you prefer one-week or two-week sprints? And why?”

The Scrum guide says up to a month

Sam doesn’t have a preference between one-week or two-week sprints as it depends on what the situation (and organization) calls for

Sam recommends that teams brainstorm their definition of ‘done’

Either way, it’s important for the organization and team to maintain focus for the sprint duration, no matter the length

A short sprint means there’s less to plan, less to review, less retrospective, and it scales more linearly

All-in-all: it really depends!

“What is a scrum master role? And what are the tasks that a scrum master has to perform?”

Scrum masters are responsible for coaching the product owner, the development, and the organization

Through transparency, inspection, and adaptation they should be working to improve the system over time

They should be always be asking: ‘What value are we getting out of this activity?’

They have to remove impediments for the scrum team (once it is clear that the team cannot clear them)

They must coach and protect the team

They should help those outside of the team to understand how to interact with the team

They need to coach the team and the organization how to work in Scrum

They need to work with the organization on how to spread Scrum (as well as agile values and principles)

The scrum master has to do whatever is necessary to help the team be successful

“What are the first things a scrum master should do when starting at a new organization?”

Have a group AMA as well as one-on-ones with each member of the team to build trust

Ask the team what their challenges are, listen to them, and address those first

Build a report with the dev team and the product owner

You should be networking within the organization and learn who’s who

Mentioned in this Episode:

Quora

Mind map

Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!”

Deep Work: Rules for Focused Success in a Distracted World, by Cal Newport

Agile 2019 Conference

Quiet: The Power of Introverts in a World That Can't Stop Talking, by Susan Cain

Quora Questions:

“Do you prefer one-week or two-week sprints and why?” Asked by Sara Morsi

“What is a scrum master role? What are the tasks that a scrum master has to perform?” Asked by Rashmi Pathak

...

Previous Episode

Under-Promising & Over-Delivering: What New Scrum Teams & Leaders Should Avoid

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:

The Agile Manifesto

Three Pillars of Scrum

Fist to Five...

Next Episode

Concepts Around Agile: Common Misunderstandings and How to Correctly Apply the Agile Manifesto Principles

Today on the podcast, your host, Dan Neumann, is going to be exploring concepts around Agile. This is a very important topic as a lot of times we go into an organization and find that there’s a lack of clarity or a lack of common understanding about what agility really is. Often, it’s the agile itself that is confused with a popular framework on the market, or, it is seen to be implementing a different methodology than what they already have.

In this episode, Dan will be exploring a couple of these misunderstandings around implementing agility, what exactly defines agile, and some of the principles behind the Agile Manifesto and how to correctly engage with them

Download the Manifesto for agile software development and principles

Key Takeaways

What defines Agile:

As the Agile Manifesto states: “We’re uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:

“Individuals and interactions over processes and tools
“Working software over comprehensive documentation
“Customer collaboration over contract negotiation
“Responding to change over following a plan
“...While there is value in the items on the right, we value items on the left more”
- I.e. while there is value in processes, tools, documentation, contracts, and plans, the Agile Manifesto simply places more value on individuals and interactions, working software, customers collaboration, and responding to change
These agile values have allowed the agile approach to be more successful and a better way of delivering software than many alternatives
Agility is not binary; it’s not that you are agile or you are not agile — think of it more like a spectrum

Common protests and misunderstandings about Agile:

Sometimes the phrase, ‘it’s not agile,” is thrown around like a weapon — but in the manifesto itself there is nothing about how the plan is to be displayed; it’s up to the people doing the work to determine how much documentation is appropriate
Some argue that agile is simply hip and trendy for websites or that it only makes sense for delivery of a certain type of system, yet, amongst the names of the signatories on the Agile Manifesto there are people that do a variety of work (from extreme programming to Scrum to embedded software to financial systems)
A common protest is: “We can’t be agile because we do _______,” but regardless of the type of work you do, you can still place value in the items on the left over the right
You don’t have to be doing Scrum or paired programming to be agile

Three of the twelve principles behind the Agile Manifesto and how to correctly engage with them:

The second principle: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
- How to engage with it: In some organizations, change occurs simply because their opinions change — but it’s key to really ‘welcome change’ when there is a substantial positive benefit from making it
The sixth principle: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
- How to engage with it: though you can email and use messaging out of convenience, it is really important to engage in face-to-face conversation whenever you can (especially when communication seems to be going off the rails)
The tenth principle: “Simplicity — the art of maximizing the amount of work not done — is essential.”
- What this principle means: Software development tends to be laser-focused on getting the requirements from the customer and doing all of the things that the customer needs... but the team tends to take an architecture mindset forward and overbuild (all these extra complexities create a lot more code to maintain and defers risk); AKA ‘gold-plating’
- How to engage with it: If you want to pursue more agility, one way to do that is to start looking with a critical eye at what’s being asked for and take a look at how you’re implementing it and really try to figure out where there are opportunities to not do something or not do something yet
Remember: Delivering working software for your customer is the highest priority rather than serving the architecture