Agile Coaches' Corner

In this episode, Professional Scrum Trainer Sam Falco addresses the complaint: "I don't like Scrum because there are too many meetings."

In this week’s episode, Dan Neumann is excited to be joined by someone outside of AgileThought, Yvonne Marcus! Yvonne specializes in teaching home management (which is the process of effectively running a household) with an agile twist. Her mission is to help parents develop flexible home management solutions using agile principles to leave them with more time for themselves, quality family time, less money spent, and a more productive week.

 

Yvonne Marcus shares how you can begin to implement agile into your home with her invaluable tips and tricks in this episode! She shares exactly how you can start bringing the agile process into your home, how to introduce your family to it, and actionable tips to take in getting started. Yvonne truly illustrates how applying agile principles can take your family from surviving to thriving!

 

Key Takeaways

What is home management?

Everything you have to do in your house to make it run (doing the dishes, cooking dinner, taking care of your kids, etc.)

The process of effectively running a household

Ways to apply agile to home management:

You can use Scrum boards at home for your kids so they know what they need to do for the day (and lessen their dependency on parents to guide them through every step)

The kids can contribute to the backlog during their family sprint meetings (ask your kids: “What needs to be done in the next two weeks?” or “What do you want to do in the next two weeks?”)

Families can also discuss behavioral problems at the sprint meetings and discuss what an appropriate consequence could be for said behaviors by involving them in the process (similar to a team working agreement)

Yvonne’s tips for bringing Agility into your home:

Yvonne uses DAKboard for their sprint goal board where she keeps track of their daily schedule, count downs to important events, sprint goals, etc.

She recommends whiteboarding and putting everything either in a Google Sheet or using an application that creates to-do lists (such as Microsoft To-Do)

Do not ask anyone in your family to start using a new piece of software that they do not already use (because if they’re not used to it they will not use it and you’ll fail with your first implementation of trying to run agile at your house!)

You can use Scrum, Agile, Kanban, etc. — whatever works best for your home!

Do your daily Scrum first thing in the morning

An important question to ask yourself is: “How much time do I need to take care of myself today?” (Because if you don’t set aside self-care time at the very beginning of the day you will always find something in your home that is more important that needs to be done and you’ll forget about it)

Create a sustainable pace with the principles behind the Agile Manifesto (it’s not just about the work)Stick with it even if it’s not perfect the first few times

Create a continuous feedback loop by asking your family what went well that week, what didn’t work, modifying, and implementing changes

Ask yourself: “What is the simplest thing you can do to create a solution for the start?” Don’t go over the top; just start with what you have

Take the four tendencies quiz (it can be helpful to understand who is on the “team” and how to communicate in a way that will be most receptive for them)

Where Yvonne recommends getting started with implementing the Agile process in your home:

Start with the daily standup (because being able to reconfigure time so that everyone’s time is valued will be one of the most eye-opening spots)

If you start with the daily standup you’ll see the most immediate success

Everyone should provide input so that everyone knows they have a weight in what is going on inside the home

 

Mentioned in this Episode:

Yvonne Marcus

“Agile programming — for your family” Bruce Feiler’s TEDTalk

The Secrets of Happy Families:  Improve Your Mornings, Tell Your Family History, Fight Smarter, Go Out and Play, and Much More, by Bruce Feiler

DAKboard

Microsoft To Do

Whiteboarding

Yvonne Marcus’ Podcast: Your Agile Home

Airtable

ClickUpTrello

iCalendarGretchen Rubin — The Four Tendencies Quiz

Ethical Hacking Courses on Udemy

 

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 week’s episode, Dan Neumann is excited to be joined by someone outside of AgileThought, Yvonne Marcus! Yvonne specializes in teaching home management (which is the process of effectively running a household) with an agile twist. Her mission is to help parents develop flexible home management solutions using agile principles to leave them with more time for themselves, quality family time, less money spent, and a more productive week

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "Can Scrum and Kanban work together?"

Introduction

In my classes I often get asked about the differences between Scrum and Kanban.   Can Scrum and Kanban work together, how can that work?  Typically people will talk about one team doing and Kanban, typically an Operations type team along with other Scrum teams, typically feature teams.

Scrum and Kanban can Coexist

The short answer is Kanban and Scrum can coexist.  Scrum.org has a class called Prfessional Scrum with Kanban.  This was created by Kanban expert Daniel Vcante and Yuval Yevet a Professional Scrum Trainer.  Both of Daniel and Yuval have extensive kanban experience and have been working in the Kanban community

Yes, Kanban and scrum can coexist. How does that actually work, you are asking? Let's think about this. Kanban is about flow and Kanban principles and practices do not conflict with the Scrum framework.  The principles for Kanban are: start with what you know and agree to pursue incremental evolutionary change and respect the current process, rules responsibilities and titles. Within Scrum, we  have a built in way to achieve evolutionary change, because we inspect and adapt.  The retrospective and daily scrum are ways that this can be achieved. 

Limit Work In Progress

There is some limit work in process in Scrum, in Kaban it is more explicit.  Making processes explicit is another Kanban practice that makes sense, Kanban implements feedback loops and we improve collaboratively and evolve experimentally.  Again all of these seem very compatible with the scrum framework

So we're not staying with Kanban and scrum together, you are  getting rid of anything within the framework.  We are saying kanban practices and some of those tools can help you achieve flow within a scrum framework.   And you get the benefits of the focus of scrum what scrum team practices that they're used to.

Getting Started

How will scrum team begin with what they do?  What is one thing they can do is begin with Kanban in scrum.  For instance, if the teams forecasts five stories done in the current sprint, but the team  consistently misses one or two stories in a sprint, these Kanban metrics can help with the cause. 

Metrics for Scrum with Kanban

For instance the Aging working process metrics used in a daily scrum so that can help the scrum team focus on that question with data, are we going to meet our forecast or not?  If not the team can decide to focus and swarm on one item, get that item to done and continue to finish PBIs in the sprint. 

Hopefully this helps the team focus on getting to done, and issues that prevent the team from achieving their forecast.  I would recommend the aging working process metric as a great way to start work with your scrum team using Kanban in your daily scrum. Other practices like visualizing your workflow and limiting WIP will help that focus as well. 

Conclusion

If you are want to increase your teams focus, I recommend reading up on Scrum and Kanban.  Even taking the Scrum with Kanban course, which goes in depth on methods to help Scrum team utilize metrics to increase their focus. 

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: "Can Scrum and Kanban work together?"

In this episode, Dan Neumann is excited to be joined by special guest, Felipe Castro! Felipe is an expert on OKRs or Objectives and Key Results. He is an OKR trainer, speaker, and author who helps organizations transform how they use goals by adopting OKR! He has even created his own OKR tool called the OKR Cycle which is a simple method to avoid OKR’s most common pitfalls.

 

As a master of all things OKR, Felipe Castro is here to speak about — you’ve got it — all things OKR! He goes over what OKRs are; important aspects you should consider; tips and advice regarding them; common mistakes, misunderstandings, and pitfalls; and how to overcome them.

 

Key Takeaways

What are OKRs?

Stands for Objectives and Key Results

An Agile approach to setting goals and creating alignment

OKRs are about the outcome you want to achieve

A framework for defining and tracking objectives and their outcomes

Focuses on outcome-based planning as opposed to tracking tasks and activities

Instead of giving the teams a feature to build, you are giving them a problem to solve or an opportunity to tackle

Important aspects of an OKR:

The objective should be memorable, compelling, motivating, and inspiring

The ‘why’ comes from leadership and the team figures out the ‘what’ together

Asking ‘so what?’ can help your team create better key results

Give your engineers autonomy to solve problems

Psychological safety is crucial for fostering an environment for high-performance teams

Felipe’s OKR tips and advice:

Start with targets that are regular goals (hard, but achievable)

Don’t copy another company’s method around OKR — adopting OKR is a journey that will be different for every company

Adapt the principles of OKRs for your specific context

You need to unlearn, adapt, and evolve — especially if you come from an Agile background

Common OKR mistakes, misunderstandings, and pitfalls:

Treating it as a glorified to-do list

Using OKRs as a copy of Jira (which doesn’t add any value)

Seeing the role of engineers as assisting only with the coding rather than problem-solving

That the sweet spot for achieving a target is 70% (which has zero science behind it)

 

Mentioned in this Episode:

Felipe Castro

The Beginner’s Guide to OKR, by Felipe Castro

SVPG (Silicon Valley Product Group)

INSPIRED: How to Create Tech Products Customers Love, by Marty Cagan

McKinsey’s Three Horizons Model

Doc Norton

“How Can You Test Business Ideas? Interview with David J. Bland,” by Felipe Castro

Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr

 

Felipe Castro’s Book Picks:

Testing Business Ideas: A Field Guide for Rapid Experimentation, by David J. Bland and Alexander Osterwalder

Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing, by Ron Kohavi, Diane Tang, and Ya Xu

 

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, Dan Neumann is excited to be joined by special guest, Felipe Castro! Felipe is an expert on OKRs or Objectives and Key Results. He is an OKR trainer, speaker, and author who helps organizations transform how they use goals by adopting OKR! He has even created his own OKR tool called the OKR Cycle which is a simple method to avoid OKR’s most common pitfalls

In this episode, Professional Scrum Trainer Sam Falco addresses the questions: "What does an effective Daily Scrum look like?"

Introduction

Recently, I saw a great question on Twitter from Ebenezer Ikonne. I love following him because he often asks thought-provoking questions about agility in theory and agility in practice. His question that day was about practice of daily standups. He asked, "Is there anyone in my network who has experienced a standup done well? And possibly consistently?

now I'm curious... is there anyone in my network who has experienced/participated/facilitated/observed...a standup done well? possibly consistently? if yes, would you mind describing what it looked like?

— Eb (@eikonne) April 26, 2020

 

I thought that was a great question because the Daily Scrum in Scrum is so often a ritual devoid of meaning other than people standing around giving a status report to someone else, often the Scrum Master.

I responded with a short thread describing an experience with one of my teams, years ago that was very positive and a very effective use of the Daily Scrum. I think that it's worth repeating here and elaborating on.

The team in question had been practicing Scrum for quite some time pretty successfully. We were delivering on a regular basis. We were delivering fairly high-quality stuff. But our Daily Scrum fell into the typical rhythm: The Development Team members took turns answering the classic three questions and then it would be on to the next person, without really collaborating. Because what we were doing most of the time was merely mentioning task IDs from our electronic tool: "Yesterday I finished 1037. Today, I'm going to pick up 1052 and if I finish that I'll get started on 1053. No impediments."

We were following the Scrum Guide, but only in a rote fashion. The Product Owner was attending our Daily Scrum one day because we’d asked him to be there to answer some questions about the scope of one of the PBIs. He said he was really confused at what he had just seen and asked if it was really helpful to us. We realized that it wasn’t, and that we needed to change.

The next day, we started at the top of the Sprint Backlog and talked about the first unfinished Product Backlog Item. We talked about what was remaining. What did we still need to do to get this PBI completed? Could we do it today? Failing that, what could we do to advance its progress? When we finished talking about that item, we'd move on to the next, and the next one after that, and so on, until our fifteen-minute time box expired.

As we continued this practice, the effect was dramatic. We came out of the Daily Scrum every day energized instead of bored and disaffected. We were collaborating, and it led to further collaboration throughout the day. Instead of people working on their individual tasks in silos, we were working together to deliver that integrated increment. We started finishing PBIs faster as a result.

We also very quickly realized that it was pointless to have more than a few PBIs in progress at any given time. We only had time to discuss three or four of them each day in the Daily Scrum. Previously, we had enacted a work-in-progress limit based on the number of tasks per person. Instead, we started limiting the number of PBIs in progress. That increased our focus on collaboration. It increased our focus on completing PBIs together, not getting tasks done. The change of focus helped our throughput increase, and it increased our quality.

We changed from a mechanical practice of the Daily Scrum "by-the-book" to one that honored the spirit of Scrum, which is true team collaboration. Although we weren't individually answering the "three questions," we were still answering them--as a team.

Conclusion

If your Daily Scrum is stale or you feel as though it isn't providing value, try changing it up. Ask yourself how you can structure the discussion around what the whole team needs to do today in order to get a little closer to the Sprint Goal.

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 Sam Falco addresses the questions: "What does an effective Daily Scrum look like?"

Recently, I saw a great question on Twitter from Ebenezer Ikonne. I love following him because he often asks thought-provoking questions about agility in theory and agility in practice. His question that day was about practice of daily standups. He asked, "Is there anyone in my network who has experienced a standup done well? And possibly consistently?

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!

 

So, in their discussion today, Sam and Dan will be walking listeners through the various possibilities beside technical or not technical, and providing their advice on how to find the perfect balance between the two!

 

Key Takeaways

A technical Scrum Master: benefits, challenges, and advice:

It can be beneficial to know the product and the knowledge domain your team is working in so that you can help the team when they have an impediment or are struggling with something

Knowing the domain also makes it easier to help the Product Owner understand good backlog management, communicate to the development team, and encourage refinement to happen

With technical knowledge, you can call out your team if they are sandbagging

Challenges and pitfalls that can come with having a Scrum Master having a technical background is that there is a possibility that they might want to get in and do it themselves (which is not their role as a full-time Scrum Master) which can damage a team’s ability to self-organize and ability to innovate

As a Scrum Master, if someone on the team approaches you and asks how to solve it, your response shouldn’t be to directly solve it, but to instead ask: “What are you going to try?”

A Scrum Master who has no technical knowledge: benefits, challenges, and advice:

They can be helpful in removing impediments because they have some knowledge about how things work (which may help them with knowing who to go to when there’s a problem in a particular area)

The danger in not having any technical knowledge (but having domain knowledge) is that they may step on the Product Owners toes

A non-technical Scrum Master could be challenging the team where they shouldn’t be

Another concern is if the Scrum Master only knows Scrum and they’re only concerned with the team getting value out of Scrum

Sam’s Scrum Master tips:

A valuable skill for a Scrum Master is knowing when the team is confused or misunderstanding things and pausing to check and make sure that everyone is in the same place

You have to be good at what you do and you have to be doing it to serve the team; not making sure everyone does everything by the book (without understanding why)

As a Scrum Master, you should be asking yourself: “What are we doing here?”, “Why are we doing this?”, “How can I help my team?”, and “How can I serve best?”

Take some time to reflect on: “Is the Scrum framework is being applied well?”, “Is the team delivering value incrementally?”, and, “Are the Scrum values present?”

In Conclusion, should a Scrum Master be technical or not?

The question itself is a bad premise because it implies either ‘yes’ or ‘no’

The answer is ‘yes’ and ‘no;’ it depends

If you’re a Scrum Master that feels that your lack of technical knowledge is inhibiting your ability to serve your team, then it is okay to take some basic classes to understand the challenges your development team is facing

If you’re a Scrum Master who is very technical, take some time to reflect on where your service is best applied and ask if yourself if you’re relying too hard on your technical knowledge

 

Mentioned in this Episode:

“The Expert (Short Comedy Sketch)” (Seven Redlines Video)

Agile Coaches’ Corner Trainer Talk Episode: “The Risks of Having Scrum Masters as Schedulers”

The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, by Don McGreal and Ralph Jocham

 

Sam Falco’s Book Pick:

The Janes: An Alice Vega Novel, by Louisa Luna

 

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!