Agile Coaches' Corner

In this episode, Dan Neumann is back with his co-host and colleague, Sam Falco! Today, they’re discussing whether or not a Scrum Master should be technical. Sam often finds himself being asked about this and has noticed many other people have a strong opinion for arguing either side of the coin. But, there’s more to it than just those two extremes!

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "Why doesn't Scrum care about good software development?"

Introduction

In my Professional Scrum Foundation classes, sometimes I'm asked, "Why doesn't Scrum care about good software development?" Kind of a funny question, right? Scrum was founded for software development teams and we don't really see that in the Scrum guide. So, for instance, if I look at the Scrum guide and search for terms like tester and development or continuous integration, we don't really see that in the Scrum guide.

Scrum Does Care About Good Software

My answer to this question to the students typically is Scrum does care about software development and one of the first classes from Scrum.org was for the Professional Scrum Developer course and Ken Schwaber created that, he's a software developer at heart and in his background. So very passionate about good practices there. And this course teaches Scrum along with good software engineering practices. Things like test driven development, continuous integration, those kinds of things where the foundation of the course and as with all courses you create an increment of software over the course of multiple Sprints. You create multiple increments of course. So, I'm a Professional Scrum Developer Trainer, love the course. And one of the things I do love about it is we keep incorporating fresh trends, trends like DevOps for instance, infrastructure is code, telemetry and monitoring. Those are all things that are incorporated now into that course. So Scrum.org is always modifying, inspecting and adapting as good Scrum should do on their courses.

Build the Right Team

The idea that Scrum doesn't care about good engineering practices though is not actually correct, but the Scrum Framework encourages development teams to have all the skills necessary to create that increment, that complete increment. So, for instance, if your team doesn't have the ability to do infrastructure as code, they don't have the right person so that you can get all the way to production, you need to get somebody on your team to do. Also, self-organization means we as a team have to decide which practices we're going to utilize. Scrum may not say specifically you need to use these technical practices and it's not prescribing them. But Scrum gives you some good basis from your Professional Scrum Developer course on what practices are good and go well with Scrum.

Self Organize

Scrum assumes that you as a self-organizing team are going to come up with those good engineering practices to create that finished increment that delivers what the customer wants and you're going to continue to keep up on good trends and what the software needs for your customer. So, in the end, Scrum does care about good software engineering practices, it's just not prescriptive about it. And if you're interested at all in the Professional Scrum Developer course, keep in mind it's been made for all different kinds of languages. Java, C sharp, JavaScript, React, those kinds of things can be modified and used with that course.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

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, Professional Scrum Trainer Eric Landes addresses the questions: "Why doesn't Scrum care about good software development?"

In this episode, Professional Scrum Trainer Sam Falco answers the questions: When should we hold our Daily Scrum?

Introduction

A student asked me, "When should we hold our Daily Scrum? Does it have to be in the morning?"

The Scrum Guide tells us that "The Daily Scrum is held at the same time and place each day to reduce complexity," but it doesn't give any guidance on when. That means it is up to the Development Team to decide the best time for them.

Here are some thoughts about the pros and cons of various times:

Early Morning Daily Scrum

First thing in the morning often works well, because we're starting fresh. Planning for the day together helps us get our heads back into the work. A challenge some teams have is that if it's too close to the start of the workday, commuter disruptions (traffic delays, kids need to be dropped off, and so on) can make it difficult for everyone to arrive on time. Also, sometimes it's hard to remember what happened yesterday.

Mid-Morning Daily Scrum

Mid-morning gives everyone time to get into the office, but if you wait too long, some people have already started working, and Daily Scrum can feel like a disruption.

Lunchtime Daily Scrum

One team I worked with held Daily Scrum right before lunch time. Everyone was in the office, and everyone was taking a natural break, so they didn't feel disrupted. However, they sometimes felt rushed when they had team lunches scheduled--everyone wanted to get moving before restaurants became crowded.

End of Day Daily Scrum

Near the end of the day means that what everyone did today is still fresh in mind, which can make planning tomorrow's work easier. But sometimes it means that there's too much focus on what we've done, and not enough on what we should do tomorrow.

Scaled Agile Daily Scrum 

In a scaled environment, with multiple teams, it's probably a good idea to have all the teams' individual Daily Scrums around the same time, so that cross-team issues that emerge can be resolved more quickly.

Want to Learn More or Get in Touch?

Register for our upcoming AgileThought Virtual Community events: Resolving Agile Anti-Patterns in Remote Work

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, Professional Scrum Trainer Sam Falco answers the questions: When should we hold our Daily Scrum?

This week, Dan Neumann is joined by his colleague and return guest, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the Transformation Lead for Pivotal’s Atlanta Office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a Principal Consultant and Agile Coach at SCRUMstudy.com for over six years.

 

In this episode, they’re going to be discussing portfolio management. A lot of times, Agility is thought of as team practices or activities that go around the team. And yet, there’s a lot of disruption and a lack of clarity that can happen when the higher-level contacts around those teams aren’t set. And a lot of times, that vision and strategy are being set at the portfolio level. So in Dan’s and Quincy’s discussion today, they shed some light on Lean and Agile portfolios in particular, as well as how portfolios fit into Agile ways of working and how it could help. They also provide actionable advice around how to keep the communication clear and transparent, key takeaways around the sustainability of the portfolio, and how to add Agile or Lean components to portfolio management.

 

Key Takeaways

How to add Agile or Lean components to portfolio management:

Make sure that alignment is there (when you don’t have alignment from the portfolio level you run into a lot of challenges around teams not being clear about why they’re doing the work that they’re doing and the overall vision)

Capture the vision through a framework (like OKRs) to add clarity

Make sure that alignment is created and that there is a concise and clear vision that everyone can execute on

Ensure that the team knows where the organization is going (so that they know what that the goals are beyond just delivering on a project)

Good alignment from the top-down is critical

You don’t want to spend time on products that are not going to bring value, so the portfolio of products needs to be constantly reprioritized and reevaluated

Make sure that the team is not putting emphasis or focus on products that are not bringing value to the portfolio of products

Ways to keep communication clear and transparent:

Once alignment is established and everyone understands what the vision is, you then have to make sure that everything/everyone is very transparent about them

Establish good, clear, and frequent communication

Potential downfalls with portfolio management and agile transformations: forgetting to communicate on a frequent basis with those on the ground who are helping to bring this vision to pass (when people aren’t clear on the ‘why’ they don’t have as much of an invested interest in the outcome)

Make sure communication is flowing both ways

Value mapping can be a valuable method for making the value creation visible, which improves communication and understanding

Within a portfolio of products, you can utilize Kanban boards which will show all of the products within that portfolio that are in flight and all of the teams that are supporting those products (they’re also highly visible to all the teams and it’s a nice transparent way for people to see how their team fits into the bigger picture)

Key takeaways around the sustainability of the portfolio:

Within the portfolio, you want to make sure that you’re looking at the cross-team dependencies and using an appropriate model that will allow the management of the portfolio to be sustainable

To make things sustainable, you need to look at what the post-transformation sustainability and the overall sustainability model looks like

Conduct change in a series of ‘push and let go’

Have a portfolio combined of different horizons (reference the ‘Three Horizons Method’)

You don’t want to spend so much time keeping the lights on that you end up being a ‘blockbuster video’ (i.e. remember to look ahead at Horizons 1 and 2 as referenced in the ‘Three Horizons Method’)

 

Mentioned in this Episode:

Quincy Jordan

OKRs

“How to Avoid OKR Fake News — Felipe Castro at the OKR Forum Amsterdam 2019” Video

Value Mapping

McKinsey’s Three Horizons Model

 

Quincy Jordan’s Book Pick:

Unlearn: Let Go of Past Success to Achieve Extraordinary Results, by Barry O’Reilly

 

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, Dan Neumann is joined by his colleague and return guest, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the Transformation Lead for Pivotal’s Atlanta Office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a Principal Consultant and Agile Coach at SCRUMstudy.com for over six years

In this episode, Professional Scrum Trainer Sam Falco answers the questions: Are there any types of work which aren’t suitable for Scrum?

Scrum is for Complex Work

Scrum lives in the area of complexity, where more is unknown than is known--about requirements, about how to fulfill them--and we have to apply an empirical approach in order to discover what we need to know and how to solve the problem.

Scrum is Unnecessary for Simple Work

Scrum would be unsuited to very simple work domains, where cause and effect are obvious to everyone, and all needed information can be known. This is the realm of "best practices," meaning there is one way to solve the problem; it is known to everyone involved, and following the known process will provide the expected result. As a concrete example, think of an oil change. In simple work, Scrum is unnecessary.

Scrum is Overkill for Complicated Work

For more complicated work that is not complex, more is known than unknown about the problem to be solved. This is the realm of "good practices." The problem is not as precise or easily defined as in simple work, and there are likely a few different ways to solve it. The example I always use is when I had to have a new roof put on my house. Everyone agreed on the requirements: Make my roof water-tight! But there are multiple types of roofing technologies, and my house's roof has a peculiar design. Those complications required analysis before we could decide on the appropriate approach. But my roofers could still use a predictive, plan-driven approach. For complicated problems, an empirical approach like Scrum could work, but it is likely to be overkill.

Scrum is not Suitable when we Know Nothing

Finally, Scrum is not likely to be suitable for a chaotic environment, when almost nothing is known about the problem to be solved or how to solve it. The classic example is a natural disaster, but I've also worked in an environment where no one could agree on what was wanted, and any plan we made could be invalidated at a moments' notice.

Provide Feedback

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 AgileThought Virtual Community events:  Kanban for Work and Home"

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, Professional Scrum Trainer Sam Falco answers the questions: Are there any types of work which aren’t suitable for Scrum?

Scrum is for Complex Work

Scrum lives in the area of complexity, where more is unknown than is known--about requirements, about how to fulfill them--and we have to apply an empirical approach in order to discover what we need to know and how to solve the problem.

This week, Dan Neumann is joined by David Horowitz, the co-founder and CEO of Retrium! Retrium is an incredible tool that’s all about helping teams have engaging retrospectives that fuel continuous improvement. It enables Agile teams to have more effective conversations, discover new insights, and generate action plans by providing a toolbox of activities, a guided facilitation process, and a space to organize your retrospective documentation in one place.

 

And speaking of retrospectives, today’s episode is going to be a retrospective deep-dive! Dan and David will be addressing some of the common misunderstandings and misconceptions around retrospectives, why you should hold retrospectives in the first place, some of the common anti-patterns with retrospectives (and how to combat them), and most importantly, how to have much more effective, engaging retrospectives!

 

Key Takeaways

What is the goal of a retrospective?

To achieve actionable team learning

It’s not just about improving productivity; it’s about getting the team to learn something and try something new (that, in turn, may lead to improvement)

They’re not limited to Scrum or Agile (or really any team working together on anything using any process)

Anti-patterns of retrospectives:

Retrospective disillusionment (where someone has the sense that retrospectives are a waste of time and don’t want to show up to them)

Lack of follow-through (if every retrospective led to actionable team learning that eventually led to productivity gains, people would show up and be engaged)

Not being cautious of who you invite to the retrospective because if you can’t get the right people in the room, how are you going to retrospect effectively? (It is crucial to think through who you invite based on the circumstances that you’re facing)

How to improve your retrospectives:

Make sure who you invite is an opt-in that the whole team, through consensus, agrees on bringing in (if you don’t, you’re throwing psychological safety out the window)

You can have multiple retrospectives and it doesn’t have to be at the end of the sprint — do what’s best for your team in any given situation

Some people may speak too much at the exclusion of others — you can use various ways to level the playing field (one way is to ask everyone to write down their ideas on sticky notes or through ‘dot voting’)

Some people feel more comfortable talking 1:1 so you could use something akin to ‘1-2-4-All’ before talking in a group

Generally varying the way the conversation takes place is a good way of ensuring everyone has a chance to speak up

Having a solid background in meeting facilitation is incredibly beneficial to the success of your retrospective

Using open-ended questions (such as, “Does anyone have anything else to say about this?” and counting to ten) can be very helpful for giving everyone a chance to speak

The Scrum Master does not have to facilitate the sprint retrospective

If you’re facing low-engagement in your retrospectives you can increase empathy by opening up the meeting to others who might want to experience how difficult facilitation really is (it also gives you the chance to experience participating)

It can be good practice to reach outside of the scrum team for someone who is a neutral party

Ten surface-level conversations are not as effective as having a single deep-level conversation on a single impediment

Narrow the scope down to the most minimal amount of impediments possible until you’ve proven that you can do more

There are some great facilitation techniques to find the root cause analysis such as the ‘5 Whys’ and ‘Fishbone’

Create space for diverging before converging on a potential solution

Rank your action items to get a list of prioritization of which one your team should try/focus on first (you can use the ICE Framework for this)

Follow the energy of the team to understand what the team wants to focus on (if no one wants to work on it, it won’t happen)

Uplevel the impediments your team is experiencing that it can’t solve

Have information radiators in place

Ask your team: ‘What, out of everything we just discussed, should we talk about intentionally, frequently, with everybody in the organization, as often as we possibly can?’

 

Mentioned in this Episode:

David HorowitzDavid’s Twitter: @DS_Horowitz

David’s Email: [email protected]

Retrium

Agile Retrospectives: Making Good Teams Great, by Diana Larsen and Esther Derby

The Retrospectives Academy by Retrium

Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth

Dot Voting

1-2-4-All Liberating StructuresRoot Cause Analysis

The 5 Whys

Fishbone

ICE Prioritization Framework

Badass: Making Users Awesome, by Kathy Sierra

 

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!