Agile Coaches' Corner

This week, Dan Neumann is joined by a long-time acquaintance and friend, Tricia Broderick, a leadership advisor and co-author of Lead Without Blame with Diana Larsen.

In this episode, Tricia talks about the book she wrote with Diana, their mission, and the most important messages that are carried in it, such as the true meaning of a Team, the relevancy of collaboration and connection, autonomy, metrics, and much more!

Key Takeaways

• What makes a Team resilient?
• • Collaboration and connection are the foundations of an authentic Agile Team.
  • Online work does not make connecting to others any easier.
• Do the leader’s team connections need to be cared for differently than the lateral connections between team members?
• • Power dynamics don’t have to be formal, it could be someone who the leader greatly respects or who has an influential power.
  • A psychologically safe environment welcomes everyone to express their true selves, even though it is impossible to assure emotional safety for everyone at all times since each Team member is unique.
  • Are you showing up with compassion?
• Bounded autonomy:
• • You cannot empower someone to do something if they don’t have the knowledge or the skills.
  • Trust is required in both directions.
• Information radiators and appropriate use of metrics are the right way of seeing trends.
• • Sometimes metrics are misused; they need to be used carefully.
  • Metrics need to help the team collaborate towards problem-solving and not as weapons.
• A Team doesn’t become one only because it is named that way.
• • A group is not a Team, cooperation isn’t the same as collaboration.
• You are a better leader because you are not perfect, own your mistakes and growth, since they have brought you to the point where you are today.
• • The only way it is impossible is if you stop trying.

Mentioned in this Episode:

Lead without Blame: Building Resilient Learning Teams, by Diana Larsen and Tricia Broderick

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 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

...

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...

This week, Dan Neumann is joined by AgileThought colleague, Eric Landes, to discuss real vs. fake teams! Landes, who comes from a DevOps background, originally started out as a developer. Currently, he serves as a Senior DevOps Consultant, ALM Director, and Solutions Architect. In his roles, he helps clients deliver value to customers in their software delivery pipeline, and has extensive experience in leading organizations in adopting agile and lean frameworks, like Scrum and Kanban.

In today’s discussion about real vs. fake teams, Dan and Eric talk about what distinguishes between the two, the benefits to having a real team vs. a fake one, and how you can help enable teams to move from ‘fake’ to real. Tune in to hear it all!

Key Takeaways

What distinguishes a real team vs. a fake team?

Real teams collaborate while fake teams cooperate

Fake teams are groups of individuals that are not behaving together and do not have a shared goal or outcome

Real teams have a collective focus, they are catching defects before they happen, and there are code reviews happening in real-time

Fake teams observe rather than code in real-time (so they end up with really delayed feedback)

Fake teams generally have lots of individuals, working on lots of different problems at the same time (therefore, they’re not really building on each other’s ideas)

Real teams have an interest in continuously improving together, whereas fake teams may have a rockstar or two who go after self-improvement where the rest don’t

Benefits of having a real team:

Faster delivery pattern with higher quality

A real team collaborates and keeps the whole team’s focus in check

It’s a lot more energizing than working in isolation

Benefits of quality and speed and delivery

The focus from the accountability you get from being on a team helps eliminate brain distraction

Happier employees

How to enable teams to move from “fake” to real:

Making coding katas or dojos a regular thing for the team

If you’re management and the team wants to hone their craft, help enable that

Defining the goals for real collaboration beforehand with your team can help enable more effective collaboration

Does the team have a goal that makes sense for them? If they don’t, then start there in establishing one

When you do have a goal for the team, look at the product backlog and make sure it is structured in a way that enables collaboration

In the retrospective, help the team see some things that might be opportunities for improvement that would encourage a collaborative focus

Mentioned in this Episode:

Eric Landes (LinkedIn)

Agile 2019 Conference

Woody Zuill

Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts, by Annie Duke

Eric Landes’ Book Picks:

Training from the Back of the Room!, by Sharon L. Bowman

How to Lead When You're Not in Charge: Leveraging Influence When You Lack Authority, by Clay Scroggins

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!

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 Functionality

What 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!