Agile and Scrum Videos

Watch Mountain Goat Software videos on agile, Scrum, product ownership, estimation, planning, and teamwork.

All Videos

Transcript

Sprint planning is often the longest meetings from teams have each sprint.
So it's important to do it well.
But many teams struggle with sprint planning.
In this video, I want to share the top three signs that your team is struggling with Sprin planning Number one, the meetings are long and painful.
I hear you.
Some of you are telling me that all meetings or painful Perhaps, but while you may not enjoy being in a meeting, team members should at least find sprint
planning meetings valuable.
I don't enjoy going to the dentist twice a year to have her scrape the barnacles off my teeth, But I do acknowledge it's valuable Number two,
the team fails to finish most of the work and achieve the sprint goal in most sprints.
Teams don't need to achieve the sprint goal and finish everything every sprint, but they should finish every thing most of the time.
And too many teams miss every Sprint.
If people think of planning meetings as long and painful, those feelings are going to be compounded when the meetings don' t lead to successfully completing sprints.
And a third sign your team is struggling with sprint planning is that team members fail to leave the meeting enthused and energized about the work of the
coming sprint.
When sprint planting is done well, team member should be fired up, excited about doing the works they just spent time talking about.
If you and your teammates finish a planning meeting and aren't excited to do that work, it's a sign that sprint pointing could be better.

Transcript

A Product Backlog Item's acceptance criteria is a list of things that must be true for that backlog item to be considered done.
But a definition of done is also a List of Things that Must Be True for a Product backlog Item to Be Considered Done.
Are these competing ideas?
Do you need both acceptance criterion and a Definition of Done?
If so, how do the two ideas relate?
Let's dig into the relationship between acceptance criteria and a team's definition of done.
Hi, I'm Mike Cohn.
I am the author of three bestselling books on Agile and Scrum.
Each product backlog item should have an associated set of acceptance These are essentially high-level tests to prove the backlog item does what it's supposed to.
Suppose you're developing an e-commerce website that allows people to buy wine.
One of your backlog items gives site visitors the ability to search for a wine, acceptance criteria for that will include things like users can search
by type of wine such as Cabernet or Chardonnay.
Users can searched by price range.
Users can search by ratings and so on.
On this same wine shopping site, there will be another backlog item that allows users to pay for the items in their shopping cart.
That will have acceptance criteria such as the buyer is charged the right amount, shipping charges are calculated correctly and added,
if a credit card is declined, the buyers notified and given a chance to edit the card's details and more.
Notice that these acceptance criteria are very specific to each product backlog item.
Searching by price is an acceptance criterion for the search for wine backlog items, but searching by prices doesn't make any sense as acceptance for paying
for items in a cart.
Contrast that with a team's definition of done.
A team definition done should contain things that apply to all, or perhaps nearly all of its product backlog items.
On a definition have done, we'll see things like the item has been thoroughly tested, the code is checked in, The website works in Chrome,
Safari, Firefox, Edge and Opera, and other items like that.
You could write these as acceptance criteria for every product back log item.
But it would be a lot of work adding these to every backlog item.
So instead, we elevate common items into a universal definition of done.
Think about the Winebine website.
Every backlog items the team delivers needs to be thoroughly tested, have its code checked in, and so on.
The difference between acceptance criteria and a definition of done is that acceptance Criteria are specific to a particular product backlog item.
The definition Of done Is universal.
It includes things that nearly all product Backlog items need to comply with.
I say nearly All because you'll occasionally have items that don't need To meet every part of the definition have done.
In our Wine website example, the definition of done required that things work in five browsers.
That system will have some behind the scenes features without a user interface though.
Perhaps it sends nightly emails with low inventory warnings.
There's no web browser involved in that little area at all.
Still, because most features will be run in a browser, including browsers in your definition of done is a good idea.
Let's look at a quick example of how I'm using a definition-of-done and acceptance criteria right now.
My acceptance-criteria for this video were, one, explain what acceptance criterion are.
Two, explained what a Definition-Of-Done is.
Three, explains the difference.
But for this video to be complete, I also need to meet my definition of done for every video.
That includes starting with a quick introduction, keeping the video as short as possible to respect your time, creating a cover image for the videos when
I upload it, writing a short description, and adding a couple of these links to other videos.
Oh, my Definition of Done also includes reminding you to click the like button and to subscribe so you don't miss future videos,
I hope your definition of done also includes leaving me a comment.
Let me know how you're doing with acceptance criteria and your definitions of Done.
Or let me what other topics you'd like me to address so I can get those done.
Thanks for watching.
I'll see you next time.

Transcript

You're close, very close.
You've almost finished a product backlog item.
When the sprint ends, do you get to take any credit for that partially finished product back log item?
Hi, I'm Mike Cohn.
I am the author of three bestselling books on Agile and Scrum.
And today I will share precisely what you should do about taking partial credit.
The typical situation is this.
A team has worked on what for them is a medium to large product backlog item.
The end of the sprint arrives and the item is more than half done, sometimes even nearly done.
And the team wants to take partial credit.
If it is, let's say, an eight-point user story, the teams might want to claim five points as done Don't let them.
One of the big problems with partial credit is that teams will usually overstate their progress.
Team members think they're further along than they are.
Overstating progress feels good.
The team is, after all, able to report a higher velocity.
Unfortunately, this won't feel good for long.
As soon as someone divides the work remaining towards some milestone by the team's average velocity, which is now overstated,
the result will be an artificially early prediction of when the will work be completed.
Next thing you know, you've missed your deadline.
Further, it is notoriously difficult to estimate what percentage is truly complete.
Are we 50% done, 60%? That is extremely hard to know and most people overestimate how far along they are.
We might think we're 50 percent done but what that usually means is we are 50 done with the work we see.
There is almost always some amount of work will need to do but that we don't see yet.
We haven't thought of it yet.
So while we may be 50% done with what is known, that will translate into less than 50 percent done, with the full job.
Because of the difficulty in estimating percentage complete, I recommend not doing it at all.
Product backlog items are either done or not done.
No partial credit.
When a scrum master or coach takes a no partial credit stance, it often angers the team.
Sometimes this makes them take a will show you attitude toward the scrumm master.
Team members then proceed to show the scrub master how stupid that rule is by always finishing stories.
And to ensure they always finish in backlog refinement or sprint planning, team members split large stories into smaller ones.
Focusing on finishing and splitting large items into smaller ones are two things a scribe master or coach will want.
So when you enforce a no partial credit rule, teams work in more agile manners.
Score!
But do I ever let a team take partial credit?
Yes I do.
If a Team discovers sufficiently early in a sprint that they will not finish and they want to split a product backlog item,
I will let them do so and then count the part they finish.
But they need to do this early enough that it isn't cheating.
A Team attempting to spit an item on the last day of an iteration is just trying to circumvent the no partial-credit rule.
I want to avoid setting a hard and fast deadline for splitting items and taking credit.
But if pressed, I think a good guideline is around halfway through the iteration.
There's an old saying that coming close only counts in horseshoes and hand grenades.
A team coming closer to finishing is nice, but it's not enough to earn the team any credit toward velocity.
Do you let your team count partial credit?
How has that worked out?
And if you've taken a no partial-credit stance, how did team members react in the short and long terms?
Please share your experiences and thoughts in comments.
I read and value everyone.
If this video has been useful, click the like button.
And, if new to the channel, subscribe so you don't miss out on future tips to help you succeed with Agile.
Have you made it this far?
If so, you earn full credit for watching.
If not, remember, no partial credit.
Thanks for watch and I'll see you next time.

Transcript

Should an Agile team assign all of the tasks on its sprint backlog during the sprint planning meeting?
Some teams should, but others should not.
One key factor determines whether your team should assign tasks during sprint plotting.
Hi, I'm Mike Cohn, and I am the author of three best-selling books on Agiles and Scrum.
I help teams succeed with Agil.
During sprint planting, team members discuss a sprint goal and then select the top priority product backlog items they can complete that will achieve the
sprint goal.
Many teams take this a step further and create a list of tasks that we'll be needed to deliver these product backlog items.
This leads to a sprint backlog that contains tasks like design this, code that, write the test, and so on.
When a team does this the question is whether they should leave the Sprint Planning Meeting with someone assigned to each of these tasks.
With someone assigned to each task, it's clear who is responsible.
You've got your name next to your work, and I've my name, next mine.
This increases individual responsibility, but it decreases team responsibility.
If I see your names next certain tasks, I'm less inclined to worry about them or feel I should take them on.
They're your tasks.
This is a problem because what we could really benefit from is the feeling of team responsibility.
Team members should feel a bit like one of the three musketeers, one for all and all for one.
But you can't get there.
You can get to team accountability without everyone first feeling personal responsibility for their own tasks.
And that helps you decide whether tasks should be assigned during sprint planning.
Yes, they should if team members don't yet feel individually responsible for their own work.
For a while, go ahead and put names on tasks.
That should lead to team member feeling responsible with their names.
Once it seems that personal responsibility has become ingrained in the team, Do not put names on tasks during the planning meeting.
Instead, use the daily scrum for people to indicate which tasks they'll work on each day.
This is a better way to go because it will lead to feelings of team accountability.
But it also retains the most flexibility.
Why should a team decide during the planning meeting who will do a task that won't be done for perhaps another nine days,
or even longer if the team is doing a four-week sprint?
Knowing who the right person will be that far into the future is hard, so the time is unlikely to get it right.
So why bother?
A decision about who will work on something can be made in a just-in-time manner during the daily scrum.
I think it's good during a sprint planning meeting for a team to consider who might do the tasks on its sprint backlog.
Team members might even make a very tentative preliminary plan this way.
You'll do those three tasks, I'll these, our colleague will pick up the rest, and whoever has time will do this last one.
But I don't even write that down.
I certainly don' want to formalize it by adding names to each task in our planning tool.
Tentative verbal planning is just enough for team members to agree they can finish the work of the sprint.
Actual decisions about who will do what should be made just in time during the daily scrums.
If you think it'll be hard for your team to switch to not putting names on tasks, don't go there all at once.
Transition there gradually.
Instead of assigning a name to every task next sprint, put names in half the tasks.
Do that for a sprint or two.
Then cut back further.
Maybe names are assigned to a fourth of the task.
Continue cutting back to the point where sprint planning ends with each person stating just the one task they'll work on during the remainder of that day.
My experience shows you'll find this a worthwhile improvement for your team.
Does your Team Assign work during this sprint-planning meeting?
Are all tasks divvied up among team members?
If not all task, approximately what percentage is assigned during sprint planning?
Please share in the comments whether your team member's sign up for tasks during Sprint Planning and how that's working for you.
If this video has been useful, please click the Like button.
And if you're new to the channel, click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

Transcript

Some teams never quite finish the work of their sprints.
I've talked in other videos about how teams don't need to finish everything every sprint.
It's normal and sometimes good for teams to occasionally aim a little high for what they can accomplish in a sprint And I've also talked in another video
about how not finishing sprints can become a bad habit.
In this video, I want to talk about two reasons why many teams overcommit and how you can help them.
The most common reason teams overcome it is pressure from leadership or any source outside the team.
Sometimes this leadership pressure is well-intentioned.
A leader gets excited about the opportunities presented by a product and wants more, or they want it faster because of the good it will do the company
and or the product's users.
Other times, though, the pressure comes from misguided leaders who think pressure isn't an appropriate way to motivate a team.
The second most common reason teams overcommit is pressure from themselves.
Teams may do this for a variety of reasons, such as hoping to please outsiders or desire to meet high expectations of themselves Whether pressure to overcommit
comes from outside or within the team, it's neither a healthy environment for the members nor a good situation for organization.
All organizations need some level of predictability.
I worked with a rapidly growing company that was preparing for its IPO.
Despite a tremendous focus on achieving revenue targets one last time before going public, the CEO told me he'd be willing to exchange some revenue for
greater predictibility.
When a team pulls too much work into a sprinter, strives for an overly aggressive sprint goal, they often miss and that reduces predictability.
Predictability shouldn't become the goal.
If it does, teams make easy commitments each sprint and achieve them.
Instead, team should do their best to plan realistically.
Leaders and others outside the team then need to be understanding when a teams occasionally misses its goal When a team announces its plan for a sprint,
everyone both on and off the team should expect the teams to achieve that goal but know that it won't always happen.
When I go to my favorite restaurant, I expect them to have my favourite fresh sea bass, but sometimes they're sold out already or perhaps the fresh fish
delivery was delayed that day.
Here are three things you can do to help a team that too often does not meet its goals.
First, get everyone to understand that sprint commitments are goals, not guarantees.
The word commitment is not synonymous with guarantee.
A commitment as a teams promise to do its best to achieve a goal.
If the team is forced to make a guarantee, they will make guarantee less so that the guarantee is safe.
There can be a time for guarantees.
Sometimes a client or customer does need some capability by a certain date.
The finance group may need to run year-end reports in early January, for example.
In general, though, we don't want to force a team into a guarantee.
Instead, want a Team to commit to something reasonable and then we should be understanding if they miss it.
You will most likely need to convince some leaders of this.
A good way to do this is to put the commitment guarantee difference into an example a leader can relate to.
For example, ask them to imagine asking the sales group how much they can commit to selling in a given period.
Then imagine ask if the sale group will guarantee that amount or would they prefer to guarantee a different amount.
A second thing you can do to help a team that doesn't routinely meet its goals is to never treat missing as a failure.
It can be disappointing when a Team misses, but it's not a Failure.
Yeah, I know I put the word Fail in the title of this video.
I did that because my SEO person said people search for it.
Still, don't call it a fail when your team does its best but comes up short in meeting a goal.
A third thing you can do if your team misses their goals too often is to help them identify root causes.
Sometimes it's just bad luck for a handful of sprints.
More often, though, it is because teams feel optimistic about what they can achieve.
They plan their sprint to be best-case scenarios.
If you think that could be your team, InSprint planning meetings try asking questions like, what could go wrong that can cause the team to miss its goal?
Or what has to go right for what the teams is considering as its new goal.
These are similar questions can help a team see any risky assumptions they're making about how easy the planned work needs to be.
It's important for agile teams to perform their best while also allowing the organization to create reliable plans.
To do that, you want a team that goes for it, that isn't afraid to try hard things.
You also need an organization and team members themselves who understand that an ambitious team will not accomplish its goal every sprint.
Remember, they're commitments, not guarantees.
In the comments, let me know how your team is doing.
Does it achieve its goals, most iterations?
Do you struggle with outsiders who expect your teams to make it every time?
If not, how have you convinced outsiders to have appropriate expectations?
I'd love to read your thoughts in the comment.
By the way, my name is Mike Cohn, and I help teams succeed with Agile.
If this video has been helpful, I'd appreciate it if you'd click the Like button and subscribe so you don't miss out on future tips to help you succeed Agil.
Thank you for watching, And I'll see you next time.

Transcript

You've trained people, you've created Scrum teams, you have product owners, Scrum Masters, a product backlog, sprint planning, daily scrums, sprint reviews, and retrospectives. By any reasonable outside measure, you're doing Scrum. So, why isn't it working? Why isn't work reaching customers faster? Why does so much work carry over from sprint to sprint? Why are people starting to feel like Scrum is mostly meetings? When Scrum isn't working, the problem often is not that the team is doing Scrum wrong. The problem is often that the team is doing Scrum inside an organization that keeps making Scrum impossible. I'm Mike Cohn. I've spent decades helping teams and organizations use Scrum more effectively. And when Scrum feels heavy or bureaucratic, I usually inspect three things. Whether the Scrum events are useful, whether the sprint goal is protected, and whether the organization's actually focused. Let's start with the Scrum events. A lot of people say Scrum has too many meetings. Sometimes that's true. But more often, the real problem isn't the number of meetings. It's that the meetings are not producing enough value. A useful Scrum event should create clarity, energy, or both. Sprint planning should leave the team clearer about what they're trying to accomplish and how they'll begin. The daily Scrum should help the team coordinate the day's work. The sprint review should produce feedback that can influence what happens next. And the retrospective should lead to something worth improving. When those things happen, the meetings feel useful. When they don't, they feel like overhead. Sprint planning becomes a negotiation over how much work can be stuffed into the sprint. The daily Scrum becomes a status meeting. The review becomes a demo no one cares about. The retrospective becomes a place where the same problems are discussed again and again, but nothing changes. At that point, it's no surprise people blame Scrum. But before canceling a Scrum event, inspect it. Ask, "What is this event supposed to help us achieve?" If the Sprint Review isn't producing useful feedback, don't just shorten it. Change who attends. Show work earlier to stakeholders. Ask better questions. Make it a conversation about what should happen next, not just a presentation of what was finished. If the retrospective isn't leading to improvement, don't just go through the motions. Pick one problem the team can actually do something about and do something about it. Scrum events should help the team work better. If they don't, fix the event. Don't tolerate bad meetings and then blame Scrum for having meetings. The second place I look is whether the Sprint Goal is protected. Agile approaches are meant to help organizations respond to change. A customer asks for something important. A production issue appears. A competitor makes a move. Something that seemed important 2 weeks ago suddenly matters less. All of this happens. But Agile doesn't make change free. A Sprint gives the team a short window of focus, not a prison sentence, not a guarantee that nothing can ever change, but a period of time in which the team should be able to pursue a meaningful goal without being constantly redirected. When new work is pushed into the Sprint again and again, the cost is bigger than the work itself. Teams stop trusting the Sprint Goal. They stop believing Sprint planning matters. They start holding back because they've learned that whatever they commit to today may be replaced tomorrow. That's when you hear people say, "Why are we doing all these Scrum meetings if everything is just going to change anyway?" And it's a reasonable question. Scrum should make the trade-offs of change visible. So, when urgent work appears during a sprint, don't pretend it has no cost. Have the conversation. The product owner, team, and ScrumMaster should ask, "Can we accommodate this change without affecting the sprint goal?" If yes, fine. Make the adjustment. If no, the change may still be worth making, but now the trade-off needs to be explicit. If the emergency request goes in, maybe a reporting feature comes out. A stakeholder may need to be told that a previously expected item will not be finished. The sprint goal may need to change. In rare cases, the sprint may need to be canceled. What damages trust is acting as if more work can be added with no consequences. That's not agility. That's wishful thinking. If this is what Scrum feels like in your organization, we can help. It's one thing to understand Scrum in theory. It's another to apply it with your teams, your product owners, your stakeholders, your interruptions, and your actual constraints. We help organizations make Scrum more practical, focused, and useful in the environment they really work in. There's a link in the description if you'd like to talk with us about helping your teams do this better. The third place I look is whether the organization is actually focused. Frequent interruptions are often a symptom of a larger problem. The organization is trying to do too much at once. Too many initiatives, too many urgent requests, too many stakeholders, too many priorities, too little willingness to say not yet. Scrum makes this visible. A product backlog makes visible what matters most. A sprint goal makes visible what the team is trying to accomplish next. A sprint creates a short planning horizon for deciding what a team can realistically pursue right now. Those are useful constraints, but they're uncomfortable in an organization that wants everything at once. Everyone wants the benefits of focus. Not everyone wants to make the tradeoffs that focus requires. And when leaders avoid these tradeoffs, the difficulty gets pushed onto teams and product owners. Product owners are asked to satisfy too many stakeholders. Teams are asked to start more work than they can possibly finish. Leaders ask for predictability while priorities keep changing. Then everyone wonders why Scrum isn't helping. But Scrum can't create focus if your organization refuses to choose. Product owners, Scrum Masters, teams, and leaders all have a role here, but the organization has to make real priority decisions. Scrum can make the lack of focus visible, but it cannot choose for you. Scrum doesn't solve those problems by hiding them. Scrum helps by making them visible. Then the organization has to decide what to do about them. So, what should you do first when Scrum isn't working? Don't start with a giant Scrum reset. Don't try to fix the events, the backlog, the roles, the metrics, the tools, the stakeholder relationships, and the leadership relationship all at once. That usually creates more confusion than progress. Use Agile to improve your use of Scrum. Inspect, adapt, improve one thing at a time. If Scrum events feel wasteful, pick one event and make it useful again. If work keeps carrying over, pull in less work and see whether finishing more creates more trust. If the sprint goal doesn't guide decisions, make the goal clearer. If urgent work keeps interrupting the sprint, start making the trade-offs visible. If the product owner is being pulled in too many directions, help the organization make real priority decisions. Trying to perfect Scrum in one giant batch misses the point. Scrum is built on inspection and adaptation. Use those same ideas to improve Scrum itself. When Scrum is working, it feels like progress rather than bureaucracy. Teams finish work, stakeholders respond to what they see, problems surface earlier, decisions become more clear, and people can tell that the way they're working is helping them do better work. So, if your organization is doing Scrum but not getting the benefits you hoped for, don't start by asking whether everyone is following every rule correctly. Instead, ask three questions. Are our Scrum events creating clarity and energy? Are we protecting the sprint goal enough for it to matter? And are we trying to do too much at once? Then pick one thing to improve, not 10 things, one. And here's a simple next step you can use right now. Take this question to your next retrospective. What's getting in the way of Scrum helping us deliver value sooner? Start there. Then inspect, adapt, and improve one thing. That's how Scrum starts working.

Transcript

At some point, you've probably wondered if you might be able to be both a team's product owner and its scrum master.
Banish that thought.
To see why, let's look back in history at the job of being a pirate ship captain.
A Stanford professor studied this by having his MBA students design the jobs of a 17th century pirate captain ship.
They designed a job that lumped together two areas of responsibility.
The first type of tasks are known as star tasks.
These are the strategic work of deciding which ships to attack, commanding the crew during battle, negotiating with the other captains,
and so on.
The second type tasks, are know as guardian tasks These the operational work distributing the pirate booty, settling conflict,
punishing crew members, organizing care for the wounded.
The problem with this job description is that it mixes star and guardian tasks.
There are very few individuals who excel at both types of task.
Star tasks require risk taking and entrepreneurship, whereas guardian task require conscientiousness and consistency.
A pirate captain good at identifying ships to attack and at leading his crew into battle would likely be bored by the administrative minutiae of the Guardian tasks.
To make matters worse, people tend to spend most of their time doing what they're good and what enjoy.
This means it is even harder to succeed when mixing roles that require different skills.
Pirates solve the problem by having two leaders on each ship, a captain responsible for the star tasks and a quarter master general responsible the guardian tasks.
Scrum teams should do the same.
Have a product owner perform the Star Tasks of establishing a vision for a project, defining the best outcomes the product can create for its users,
and defining features that will get it there.
but also have a scrum master to perform the guardian tasks, those tasks that protect a team from distractions and that improve collaboration and focus.
I have, of course, seen teams with one person as both scrumm master and product owner.
Each has been an exceptional person, perhaps the blackbeards of Scrum.
However, in each case, my reaction was to think how much better that person could have done their job if enabled to work in only one of the two roles.
I think something is lost when doing both roles, remember most people don't excel at both star and guardian tasks.
So can you fill both role?
Perhaps, but consider what you might lose when both doing roles?

Transcript

Can you do Scrum without a daily Sc rum meeting? Yeah, kind of. In today's hyper-connected world, team members communicate with one another frequently, but we rarely sync up fully with everyone on the team at the same time. The daily scrum meeting is a time for doing that. A short meeting allows team member to make many plans for their days. You don't want two people unknowingly working on this same thing. you don' want the most important work of the sprint ignored because each of us thinks someone else is doing it. A daily scrum can also create a tiny amount of peer pressure, a good amount. When I tell my teammates today that I'll get something done by tomorrow, I don't want to let them down. So I stay a little more focused on what I said I would do, because I won't have to say tomorrow that didn't finish it. I think you can be successful if you do these meetings a few times a week, but I also think that you'll be even more successful, if do them daily.

Transcript

Welcome in Agile Mentors.
We are back.
Thank you for bearing with us for a little bit of a break there.
If you notice, we have not been releasing episodes the past few weeks because we've been practicing sustainable pace, but we are Back and we're ready to
dive into some really, really gritty topics, some things that we think will be really beneficial.
Who better to kick us back off to bring us Back around than a friend of the show, Lance Dacey, who is with Thank you, Brian.
How was Hawaii, that big sabbatical y'all took in July?
Yeah.
Yeah, Hawaii is always great, right?
My tie's on the beach.
That's where you were.
Absolutely.
Isn't that what everyone did?
I did.
I mean, I didn't see yall there, but yeah.
Well, we're glad to be back and we were excited about what we are going to talk about today because we figured why start with something that was not controversial.
Why not find something very controversial and just set ourselves up to receive lots of.
disgruntled emails that we were probably going to get this wrong.
We're probably awesome feedback, Brian.
Awesome feedback.
But you know, I'll just go ahead and start by saying, hey, we hope you give us a little grace on this topic.
we're just talking from our experience, our opinions.
And I know there's lots of opinions on.
This, but we wanted to kind of focus on the fact that, Hey, were five years removed from the COVID outbreak.
And when COVID happened, that was a massive disruption in work.
We all had to learn how to do work in a different way.
But five years in, what have we learned?
What's changed?
And now we're seeing lots of things like return to office mandates and hybrid working agreements.
You must be here for this many days a week or other things or companies that say, no, we are now fully remote and we doing things this way,
But I saw this kind of really interesting question that made me think about this.
If you were designing the workplace from scratch today, would anyone build cubicles?
And I thought, well, that's a really interested question.
So Lance, what do you think we've learned in the last five years?
Where do we think are today with this whole work from home versus return to office?
I tell you what, Brian, I sit there and think, man, five year is a long time to have empirical data.
And I don't believe we have it.
Yeah, data.
Let me say it this way.
We got the data, what does it mean?
You know, so and I'm a data guy, y'all know that.
And i'm sitting there trying to look at it going.
I Don't know how much we've learned.
What we learned is there's no right answer.
And everybody's especially organizations.
We're looking for the right answer.
Just give me the answer and let's go for it.
You and I, we coach and consult and people hire us to tell them sometimes what they need to do.
And sometimes we're like, no, not gonna tell you what to.
Do we going to learn what the issues are and then based on that, what should we go from?
And I find, you know, if I had to sum up what we've learned.
Remote can be great, right?
Um, office can't be.
Neither's a silver bullet.
That's what I want.
So I'm going to go back to my coaching stance and say, well, let's define the outcome measure with a multi focus, multi factor,
you know, multidimensional metrics of what we're trying to actually accomplish with our people.
experiment and then keep an eye on the team health.
I still feel like that's what we're doing.
Five years sounds ridiculous that we haven't figured that out, but I think it was so disruptive that five years isn't enough.
And I the work on top of that is changing so radically.
We have too many variables up in the air.
So for now, if I had to make a decision, I lean toward co-location.
When the work is ambiguous, when relationships are important or new, that's another one.
If we've got a lot of new people together, working remote is going to be a very difficult thing for a while.
So, you know, I'd say, Hey, if I'm starting a company and the work is ambiguous, kind of like a software or product company,
the word, we're not quite sure what we are doing and needs a lot of collaboration and, and a lots of hands-on, trust with each other.
Then I am probably going to say let's, let us be in the same area sometime.
You know what I m not saying every single day.
That's how I will lean towards.
And then I'll say if your work, is predictable, repeatable, doesn't require a lof of that and you need intense focus, well then maybe Remote is fine for you.
So how's that for an answer?
I don't know.
Look, I think you're ever worse off by being able to admit that, right?
To just say, you know what?
And I sometimes that's part of the problem with the way that we approach certain issues is that people are reluctant to say that.
They're reluctant just to just admit, You know, what, don' really know!
I really don have the answer on this yet.
And I think you're hitting on something that's really important is that there is, you said no silver bullet there.
I also think there's no one right answer.
Right?
I don't think that.
There is a right.
Answer to this question of, should you be in the office or should be remote?
Right.
It's not binary.
So I agree with you on that Yeah.
There are certain industries, certain, um, products, job types that I think are better in the office.
And there are others that are I better remote.
I love your return to kind of a coaching stance and looking at this.
What's the goal?
And I that's what you have to try to, to distill it down to is what's, the purpose, what the, goal we're trying to reach here.
If it's productivity, then let's talk about productivity.
If its morale, if it enhancing communication, it starts from there.
Define what it is that we want as our end goal.
And then we can start to find data.
We can find empirical evidence that either supports or detracts from whatever hypothesis we think we have about this, and that should be what leads us.
And it could change.
You know, that's the other problem.
One quarter, it may be better the stuff we're working on.
We're in the office more often.
The next quarter maybe we agree too much.
Now, the problem is you go survey people.
Yep.
Let's talk about productivity.
Yes.
Let us say a programmer.
Okay.
I'm just going to say garden variety programmer, highly skilled.
You ask them where they are most productive.
And most of them, I am not going indict everybody, most them will say I want to be left alone, no meanings, in silence, coding on my keyboard.
They may be going a direction completely opposite of where we need to go, and we won't know that until they come together.
And so the other problem with this is we're asking sometimes the wrong question with the right people.
You ask a single programmer where they're more productive.
It's sitting in my office being able to get a coffee when I want, not sitting and traffic.
Hey, I'm all for that.
Who's productive in traffic other than, hey, i'm listening to books, you know, so I am growing myself.
But nobody, I'd be hard pressed to find anybody saying I love sitting in traffic.
So let's put that aside.
Nobody wants to drive two hours a day to their office and back home.
That's terrible.
But if you ask a programmer that, would you concur that most of them would say I'm most productive, just leave me alone.
Let me write all the code I want.
What do you think of that?
I think that's probably true.
I thing most developers would say that, yeah.
So now, that is the wrong question then, because now we're working in an agile type, let's say in a agile context, where we are working with an empirical nature,
which says we don't know what we were doing, so the more iterative and incremental feedback, the better we understand are we on the right path or not.
And so if I was to say, is it more productive to let the individuals be efficient at what they are doing and then come together later to learn that we
got a big gap where were from, Or do we sacrifice individual productivity with a lot of collaboration, which they may term as meetings?
I don't like to call them meetings, they're working sessions, right?
We had a backlog discussion about this, I believe, not long ago.
Backlog refinement is not a meeting.
It's a working session to say, hey, customer needs this.
How are we going to do it?
You know, and what is it that they need?
So I find I'm debating with people on LinkedIn a lot.
I love this, so this is why it's top of mind is even if the customer knows 100 percent of what they want, which let's just say they won't.
But if they did.
you do not know how to build it.
One programmer may, but when you got four programmers, some testers, and database people, architect, all these cross-functional skills,
how can you sit in a vacuum and do that?
So if your work requires multiple skills to come together and you're trying to built a done increment by the end of one,
two, three, or four weeks, having an individual productivity to me could be harmful.
So you look, I told this guy on LinkedIn that, that I don't believe productivity is one dimensional.
So he referenced a Stanford.
Let's see, this was in 2023. He was saying that the Stanford study showed that people were more productive working at home.
Well, It was actually a 10% decline for call center staff, by the way.
So that work is not as collaborative.
I would say maybe that same study though, found 35% lower attrition, higher employee satisfaction, which raised the long run throughput.
So while they declined in productivity at home 10%, most executives would go, no, like I got to come to the office.
We can't have that.
But what if I told you, you say 35% on whatever the number is, attrition and employee satisfaction in the long run.
Would you rather take that gamble or not?
You know, Gallup did the same thing.
He was referencing a state of workplace and They find, you know, customer loyalty and margin was better for people that were in the office.
They may be less productive individually, but the customers saw a better outcome.
So what are we measuring?
Right?
So Brian, that's what I look at with these productivity debates.
I'm like, oh my gosh, what does productivity mean?
Are we optimizing for delivery to the customer flow?
Or are optimizing the individual utilization of the people on the teams?
And I think executives have to make a choice and I say executives because they're the ones who influence heavily, whether we,
I'll talk about culture in a second.
But I find that if people steer towards individual productivity, we might be sub-optimizing, right?
We know this.
I mean, if we know flow and systems thinking and, you know, all the things that we read in books with lean and efficiency and cross-functional teams,
but what is productivity?
I don't know.
You have to define that.
So that's where I go back.
What are you trying to achieve?
Individual utilization, work from home.
Let's go.
Delivery to your customer?
Maybe not.
Right right no, you're making an excellent point and so I'll throw.
Maybe a massive curve ball into this discussion because I would propose.
That's we may not if we're looking at productivity as whether an agile organization, we should return to office or not.
we may be looking at the complete wrong thing because productivity, I would propose, and I'd say this all the time in classes,
productivity isn't the answer.
What do we hear all all of the times now about AI and developers is that AI is enhancing productivity.
It's allowing them to do more in less time.
Well, that's individual productivity individual individual, right?
But that's a volume calculation, right?
When we talk about productivity, that usually we're referring to a Volume type calculation.
But you and I both know very well that the missing gap there is actually the value gap.
And so the question is, if we are producing a larger volume of work because we were remote, does that matter if the volume work that we produce is things
no one cares about?
You know, we're all familiar with all the studies that shows I've seen multiples.
It's somewhere between 64 to 80% of what people produce and software is rarely or never used.
And you know depending on the study that you follow there with that and if that's half wrong, it's unacceptable.
Exactly.
That's what I'm doing.
Right.
And so if that's the point, does it matter if we are more productive from home?
Does it a matter of we're less productive?
From home, I don't know that it does.
I think what matters more importantly to an agile organization is are we more producing more value in a remote environment?
Are we producing?
More value and an office environment.
That's something I know there is a study on.
Well, how would you study it, right?
We were just talking about this before we were trying to, you know, what is it exactly that we're going to cover?
Because we just, it's too big, right?
It's maybe a multi-part thing, but it.
Even if you did the study, who are you surveying?
Is everybody the same?
Like we go into organizations all the time.
Yes, the organization's unique.
Y'all do unique things.
You're great.
Your problems are not unique, how we approach solving the problem.
We can borrow from other things that.
But when you go do a survey.
Are you really ensuring that you're getting all the different psychological profiles?
Because I'm going to wrap that discussion up by saying somebody's preference may override everything.
So who are you serving?
Are, are, you getting a good sample that mimics what you might see on a team?
So going back to that Stanford study, You have to ask the executives, would you sacrifice 10% lower productivity for work from home call staff?
And I know that's different work than software, but let's just where these are real studies out there.
If that same study found a 35% lower attrition and higher employee satisfaction, what if your people are happier working,
but less productive and it saves you in the long run from attrition?
Is that metric matter?
Your CFO would argue, yes.
You know, it costs a lot of money to hire somebody, bring them on board and you lose all of that knowledge.
So yeah, I have the problem of working at home.
This is me.
I don't like working in home, Okay, I do it for a living.
And I have my own little office, and I try to shelter myself away, but I love to compartmentalize work, or else I'll work all the time.
So when I work at home, just nothing, it's hard for me to have barriers.
That's just a discipline and rigor thing.
When I went into the office I could hit it hard.
I'd go in early, wouldn't take lunch, put in my time, be very productive, leave four or five, home and then I was done.
Of course you answer emails and stuff like that, that's me.
So are you surveying me?
Right.
Would you rather have me happy and be at home and yeah, I'm going to go run this errand right now.
I was less productive today because I chopped up my time and lost flow and context switching, but I am a happier employee and I contribute a lot to the
bottom line.
So what are we measuring?
So I feel like all that to say is I think you hit it on the head.
What is it that you're trying to measure?
If it's just productivity, yeah, they'll go in the office because this study says 10% less.
But the same study, says better attrition rate, higher employee satisfaction.
Do your people matter?
Well, if that's the case, are you going to sacrifice 10 percent productivity?
I would.
I want happy people working for me.
Yeah.
No, no, that a great point.
And, you know, happy, people do a better job.
Happy people, uh, take care of your customers better.
There's enormous benefits from that and there's lots of speakers and authors out there that will point you to the fact that in leadership,
the job is to try to put your employee first and take care of the employees.
If you take of your employees, The employees take care of your customers and that's what you want them to do.
Um, and I agree with that.
I think that a good approach.
Yeah, I, think you're right.
You know, there there's, impacts here across the board.
And as you said, it's a really broad topic.
Well, let's go back to that other thing just real quick.
Lance would rather go into the office.
Right.
Let's say Brian.
I don't know.
We haven't dove into your preferences yet.
Brian wants to work at home.
He wants be with his kids, pick them up at school.
That's right.
You know, that's a righteous thing.
All right, so the company would value having both of us.
So now what do we do both?
You know, we allow an office space and pay for the real estate and all that to let Lance come in because that's what he likes.
And we also let Brian stay at home.
Then at some point, where do you get them together to solve big problems?
I mean, that the age-old issue is I think the organization based on what they're doing for that set of time in the initiative has to define what is it
is most important to us.
You might even have to shift people around to different work to do that.
Say, well, Brian's not a fit for this new thing we're working on because he likes to work at home.
So do we have a mechanism and offices to that?
I don't think we are good at doing that You just hire people and say, here's your job and your pigeonhole for it and career growth and where you get so busy,
it's hard for managers to focus on that.
You know, I don't know.
I mean, the thing that I've heard most from people who have been on one side or the other side of this issue is kind of the frustration that they feel
sometimes with, with mandates one way or other.
That they're not based on fact, they are not on anything but one person's preference who happens to be then the leader.
Right?
So if Lance is the leader and Lance prefers to be in the office, then Lance might say, that's it.
Everyone's come back to the.
Because I just think that it's a better way of working.
I mean, leaders are like that, right?
Right.
It's just like, they mimic that that preference.
And, you know, it such a hard thing.
Uh, I think of the other thing, this debate I was having with this, uh, gentleman on LinkedIn, really good one, by the way.
I'm always wrong.
I am okay with that.
But I feel like how we would sum that up is that context beats location.
So you got teams.
Let me find the study here.
Microsoft did a study called the New Future of Work.
This was just in 2022, by the way.
It is a little bit older, but they said teams with tight, rapidly shifting interdependencies.
Things like early stage product discovery, like a lot of us do.
They pay a coordination tax when every issue becomes a chat thread.
there's a coordination tax.
I've always said in software there is a release tax, you know, what's the tax of the release to actually get the software into the hands of user is usually
pretty big and it doesn't reveal itself until the end.
So coordination taxes exist for those kinds of teams.
Now conversely, the study says, work that lends itself to deep focus, just like you said at the kickoff, with asynchronous handoffs,
like a good parallel flow, a relay race type thing, sees a gain of 15 to 40% with remote workers, according to ActiveTrack 2023. You can find,
by the way, any study to support your view.
Sure.
Let's just agree with that, that confirmation bias is rampant in this discussion, but Brian and I are actually trying to be what's the word,
neutral as much as possible with our own preferences to just showcase.
So go find a study that matches what you want and you're gonna be fine.
But the really smart people are gonna find the ones that argue against your point and then let you figure out just like we do with stakeholders,
there's a trade-off.
There's not one perfect answer.
You want this or that?
You can't have it all.
Well, I don't know.
If I'm a leader in an organization today and I am trying to make this decision, should I bring people back to the office?
Should I not?
I know there's lots of things to think about.
Did we sign a...
20 year lease with this building that we're going to be paying for anyway.
That's $180,000 a month for an empty building.
Right.
Obviously a concern.
Now from the counterpoint that you can say, well, that's your fault.
Why did you make that decision?
That was a bad decision, right?
And maybe that true.
I don't know, but that certainly part of that.
Decision is, Hey, this is our bottom line.
Or tell me that that took bad decisions because if we pay $180000 a.
You're not going have a job.
We're out of business.
It's like, Right.
But what I'd be trying to do is find what's the best thing for my company, for this set of employees.
That's really the question that's most important.
And, you know, I think there's, we talked a little bit about this before as well, and we discussed a bit that there are preferences,
but there is also the psychological impacts of doing these things and what that kind of reflects on your workforce.
I know I saw the study that was from McKinsey.
This is from 2021, and their study showed one in three American workers felt their mental health worsened after returning to in-person work,
one and three.
Now, again, let's stop, right?
That's a statistic, but let us look at even what this said.
One in 3 felt their mental health worsened, right?
And that's not an objective fact.
That's a feeling that is one person feels this way, the another person, feels that way.
It is something you can track with a statistic, but it's still kind of subjective when you think about that kind.
I think probably a lot of people, I would Assume feel like people People's mental health is in general Better without commuting and being at home that
they would tend to trend towards that overall but Like we were saying before there are some negative impacts of working from home as well.
You're less connected and or you're more isolated.
Don't.
Yeah.
You don't get, you don' get feedback often, uh, as often as you would, Uh, You Don' learn as much cause youre not, don have just the ability to have some
of those things.
There are people who miss the structure, the routine that comes from being in an office place.
You mentioned the work-life balance thing.
I think that that's true as well.
We often tend to think work life balance only is if you're remote, that it's a better work, life, balance.
But yes, it is a real concern as I work out of my house.
So I am always at work.
And I'm expected to always respond to emails.
Somebody believes that, right?
But going back to the study you just cited, when you ask somebody or when say, hey, you're not learning as much or disconnected,
the individual may be OK with that.
They're like, yeah, that's great.
I don't have to do all that but then what you are sacrificing is the actual ROI of whatever it is you building.
So I want to go back.
You just said something.
This is amazing.
First of all, 2021, we were still in the pandemic.
Mental decline was already Uh, you know, everybody was probably stressed.
I hate to use the word everybody and always, but that was a hard time for a lot of us, right?
So your, your mental condition in 2021, I would argue is already affected and clouded.
Now I'm going to tangent a little bit, uh, with the discipline and rigor of exercise and eating healthy.
Okay.
So let's say that I want to get better and I'll go to the gym.
you know, five days a week for 30 minutes and just try to get in that habit.
If you were to ask me three days after going to the gym, you how do you feel?
I'm gonna be like, it's terrible.
I hurt, I am getting up at 4.30, and I lack sleep, so it is a recursive problem.
You gotta get good sleep to lose weight and get physically fit and all that, but I have to learn how to go back to bed.
But you asked me early on, that I was probably miserable.
with any kind of change effort.
We know that, you know, we're in the change, effort business.
Rarely is anybody like right at the beginning of the chain going, yes, it's like, so I feel like that's a little bit biased as well.
Of course, they're probably saying, Oh, this is terrible.
Cause I'm used to being at home all the time.
You know?
Well, and we were talking before, even the productivity kind of studies, right?
And please, I feel like that if you're listening to this, you may think that I'm trying to make a case for one versus the other.
I really am not.
Well what you said earlier, You tend to like more of the opposite.
And I'll share, but I tend more like the remote.
So I had that right.
You got it right?
You definitely had it, right, but like even some of the studies that are on productivity, the question or if you, you read what the data is showing,
it's saying they're asking employees, do you feel more productive if your in the office or at work?
And even there, The workers will often say, no, I feel More productive at home.
And the managers will Often say well, my employees I Feel my Employees are more Productive in there.
when they're in the office than when the remote.
And that's a, that a feeling that not a hard data point.
It's, uh, a data of people's emotional kind of feeling in relation to it, but it's not data.
Point of what the actual productivity is.
and so even there, I think we have to be careful.
My favorite phrase I use all the time in classes data or it didn't happen.
When you, when you read statistics, and I.
Really important for us to, to zoom in on it.
Say what exactly is this showing?
What's the question that's being asked here?
How was the data collected even there?
Was this a scientific study or was this Internet poll where anyone who could come online could take the poll and it's not a Right.
There's several of those in our industry.
How many people prefer this in agile versus this natural, but Hey, go to the website and fill it out and sign up.
Well, that's not a scientific survey.
You know, people could create bots to go in and answer it a certain way, a million times.
And all of a sudden, Hey data shows.
No, it's because you didn't do a scientific survey.
So I think it is always a valid point, especially in these kind of really hotbed kind issues and discussions, to really question the source of the data
and say, what is the point behind it?
What is it that we're trying to...
What's their end goal?
And if there are studies, What was the methodology of that study?
Is it really proving what I'm trying decide here or was it proving something entirely different?
Just like a new prescription or something, right?
You want to go read who bought the study because it's like, a lot of times that can affect it as well.
But I think what you mentioned, you know, we haven't the points I was starting out with were productivity context beats location.
So instead of asking, should we be at home or in the office?
What's the work we're doing?
There is no doubt.
When we say hey Brian and Lance Lance likes to go to the office Brian likes stay at home There's no doubt there's times where there is no traffic walking
up the stairs and into my office and I can crank out three hours worth of productive work just focus but imagine if you're solving a hard problem stumbling
with something and if You just hopped on a 30-minute zoom call or if he went into the Office and brainstorm you might would have saved eight hours of You know,
productive work.
So I think a lot of times people have this stigma about meetings and that's why I like to change them to they're not meetings there.
If you're going to a meeting, that may be one thing, but the stuff we're trying to do like in Scrum or something, you know the sprint review,
the retrospective, The Daily Scrim, those are not meeting.
Those are collaborative working sessions that have a general outcome.
But what you just talked about, I'm going to call it culture is a force multiplier on this thing as well that can also change based on the type of work
we're doing.
You know, Amy Edmondson does a lot of great work in this, her book, Fearless Organization or something like that.
She talks about this concept that psychological safety can predict error sharing and innovation, whether you're on site or remote.
So it doesn't matter.
And, you know, Jeff Sutherland does a lot of talks about this, that as far as Scrum's concerned, the small cross-functional,
co-located teams, That was a workaround because of the technology they had back in the late 80s and early 90s.
I remember the days of ISDN lines where it was $400 a minute to get on a video call.
Well, there's a whole lot better tools these days that we can still collaborate remotely.
with the guy on LinkedIn that I think a team sitting together has osmotic communication as well.
Just sitting in the room, hearing things sometimes can help you.
But of course, if you're just working on something that you need focus in, that's a distraction, right?
So I can simulate much of that stuff as far as the culture is concerned, only if we have norms.
So the other thing is working agreements.
Can we an agreement as a Team that we're going to have cameras on, we are going have rapid feedback?
They need to be explicit and that might be the solution.
You know, so you have to build a culture around whatever mechanism you're going to use.
And I still think hybrid is probably the answer.
So you can just say we're gonna go hybrid and it depends on the work for the quarter of the year, whatever your planning cycle is,
and try to mix and match teams to do that.
I think we've reached a maturity, especially in the product development world, where we are less distracted about the technology.
Let's focus on people.
That's the hard thing now.
The hardest problem is the people coming together, not Are we going to be cloud or whatever those those questions have been answered.
So I think the culture is a force multiplier is the third angle to this that you just need working agreements.
You need norms, you need agreements on it.
And then that way you don't have these people building resentment because I can't tell you how many people I talked to that they're like,
oh, my company's asking us to return to the office.
Well, if they would tell you why and you had a say in it, or if, you know, I don't know.
It's just, it's such a hard thing for executives to deal with.
Well, that's the old thing from a parent point of view as well, right?
When you tell your kids, hey, do this thing.
Why?
Why am I going to do it?
Because I said so.
You know, if your parent says, just because I said so, how do you feel when you're a kid and you hear that, you think, well,
that's not good enough.
I want to know the logic behind it.
That's even more the case.
We don't want to do something just because someone dictates it to us.
we want understand why it's important and what value comes out of it.
And that it is a valuable use of my time.
I mean, that's the thing I would say to any leader that is listening is if you are going to make a decision one way or the other on this,
make sure you share your reasoning.
Make sure that its not just, hey, because this is my feeling personally on it and you just got to go along with what I say.
have some reason, right?
The kids, you know, I can understand, we'll go back to the shoe-haw-ree thing, so at some point you're raising your kids.
You're like, first of all, just do what I say without delay or challenge.
I remember teaching my kids that because there may be a time where I'd say, don't run out in that street or stop, and I don' want you to turn around and go,
well, why?
I want to do this and that.
Because there's an 18-wheeler flying by, i don''t have time to argue with you.
So you start building that discipline.
And I understand that, but we're way past that with professionals that are working in the workplace.
If any executive feels like that their answer, just like you said, because I even hated it as a kid, I want to know why I can support it.
Maybe I disagree with it, but if you tell me why you're doing like, oh, well, that makes sense.
And now I could be your biggest champion.
Right.
So so many executives just do it because i said so.
I'm your boss.
Well, you need to find a new job, sir.
You know, so I don't I think we have have to grow beyond that.
That's a great point.
that we have to mimic that along with culture.
But I think, you know, the angle to that as well, as far as context beats location.
The fourth one, I was going to told this guy on LinkedIn that experience matters as in this debate.
So if you're brand new versus if been doing the work for a long time, we'll call them veteran.
Developers, you know, veteran people who do say they develop what's known as a tacit bandwidth, right?
The ability to, to read the room, see what going on.
I've seen that problem a hundred times.
They intervene early.
There's a book out there called team genius, and they talk about this tacet bandwidth that veterans have.
And a lot of people find that easier to be done in person.
And junior colleagues actually learn faster that way if they can see it and be gravitating towards that.
Whereas, you know, the people that are brand new and they don't have that, it takes them a lot longer to solve a problem.
So again, what does productivity look like?
Do you want individual productivity or you wanna solve big problems together as a team?
And I think that's how we kind of wrap this whole thing up is it depends.
How about that?
We're consultants a lotta times and we don' have the right answer.
We have to learn what your goals are.
That's why I went back to the coaching stance because that's kind of how you start with coaches.
You know, they embrace and give you a hug where you are.
Say, I love that you've accepted that.
Now, where do we want to go?
And you have to make small iterative incremental slices to get there.
So I don't know that there's a good answer for this debate.
Well, I think your, it depends, is the right answer because, you know, and if someone's frustrated with the fact that, we tend to fall back to that a lot,
just, no matter what the question is, That's an agile approach is to say it depends because the opposite is we're going to have one right way.
And that's always the answer.
Imagine if when you were a certain age kid, everyone's going do this job.
I don't want to do that job.
I want do a different job doesn't matter.
This is the right answer.
What job should I do this job?
That's the answer for everyone.
You know, and that's, the approach sometimes people take with these kinds of problems is should we have remote work should?
We have in office work.
Here's.
The right.
Answer.
That.
Never going to be the case.
There's a right?
Answer in that one scenario that situation and it's going.
To depend on all the particulars of that.
Well, for the organization, because the other side to that is now I got to worry about attracting talent that fits my model.
Right.
So make your decision.
You know, who's who is here to say good or bad?
Just say as an organization.
We believe in these things and that's why we're going to do this.
Put that mission statement out there.
And if I'm looking for a job and I don't fit with that, I just don' work there, you know.
Yeah, You lost talent.
you'll find somebody else.
Somebody needs a jobs somewhere.
You look at these studies, like the GAO case study we were debating a little while ago, you know, the quit, I'm going to read just some stats here,
and then you have to take those and say, what are we trying to do?
So the quick rate drop when staff get two days remote.
Okay.
So they're down 33%. That's cheaper than a retention bonus.
And it works instantly.
That something people can do right now and.
You know what?
We'll get to days, remote and that number pops, right?
Commute time that is saved per teleworker is 55 minutes a day on average.
That's a bonus week off every year without any payroll costs.
So you can make an argument that that's good byproduct of doing the remote work.
And we're talking about CFO level type things here.
Activity jump or bump for jobs with clear outputs is 12%. So same payroll, more widgets or user stories, whatever.
12% better.
Office footprint after going hybrid.
50% down.
CFOs suddenly love facilities again, right?
Disability employment since mass work from home is 12% and 40% in tech roles.
That's the biggest lever that a lot of people aren't talking about.
They're not having disability on the job.
Right.
And then company that forced a five-day return to office lost 50% of its workforce, including top performers.
That's a painful, painful case study from the federal news network.
So a company, that force five days RTO lost, 50 percent of it's workforce.
Well, you could say, fine.
that's what that company wants.
Go rehire the other 50%, that want to work there and let's move on.
Yeah.
I don't know.
You know?
Yeah, no, I agree.
that all comes back to what's the purpose.
And in our scenario in, our situation, what the, the driver, you know, we started this by that quote I found that just said,
if you were to design a workplace from scratch today, would anyone build cubicles?
If I'm starting, it depends on the business.
If, I am starting a kind of a software as a service business, We're going to, build software.
I'm probably not going to have an office and probably going have a office for quite a while.
If I am an entrepreneur who is starting a new business because quite frankly I can get better talent, I could have cheaper cost and I don't need it.
Or there's probably a time when I might switch that.
But you might have increases somewhere else.
You could go find some space, right?
You say, hey, two days a week, we're going to come in like a WeWork or whatever those workspaces are.
So I totally agree with that, it's like, well, first question you have to ask yourself, what do we want to accomplish?
What gives us happier people?
Go find that data.
what helps us to be more productive in the way of outcomes.
Go find that data, broadcast it, say, here's what we're doing.
If you like it stay on board.
if you don't go find somebody else that has a style that you want.
We've been doing that for years.
This isn't any different.
Yeah.
Yeah, I agree.
Well, this has been a great discussion.
And I know that we only can kind of scratch the tip of the iceberg in this.
Again, for anyone listening, please offer us a little grace in these, right?
I mean, we're not covering every aspect of this and I people have very strong opinions on this, and from my perspective,
that anyone who's making a decision needs to take into account all these factors, take in to account the mental, health aspect of your employees and the
morale of the employees, and, the gains they get one way versus the other.
And if you cannot balance it out and make the case that, hey, there's more gains in one wave versus other, I don't think it's the right move to make to,
make a big switch in this until you can say, here's why.
All right.
Well, Lance, thanks very, very much for coming on again.
It's always great to have you.
Always a pleasure.
Maybe next time we'll bring a CEO or something and get their perspective because we'd love to hear executive standpoint from this too.
That's an awesome idea.
Yeah, let's make sure we do that.
Thanks, Lance.
All right.
Thank you.

Transcript

User stories were invented by a team at Chrysler.
When you invent something, you should be allowed to define the vocabulary.
And they did, defining the terms epic and theme.
Epic was used to mean big user story.
Think about watching some awesome superhero movie in a movie theater.
As you leave the theater, turn to a buddy and say, dude, that movie was epic.
It was big.
There was lots happening on the screen.
It's the same thing with an epic user story.
The other term they defined was theme, which meant a group of related user stories.
Suppose you're working on a system that has 10 stories about account management, and maybe there are 15 user-stories, each describing a report that users need.
These are themes, groups ofrelated items.
Next up is the term feature.
Most commonly, this means a product backlog item that is big enough it can be released to users.
If you're building software to control the color of smart home lights, you probably wouldn't release a backlog that let users set only the red value of
the light.
But letting users control full color spectrum by setting red, green, and blue values is enough to release.
So that would be a feature.
I recommend you think of these terms as labels or tags that can be applied rather than as a strict hierarchy.
This is because some features are bigger than some epics or themes.
There's not a magic size when an epic becomes a feature or the other way around.

Transcript

I've learned not to go to the market when I'm hungry.
If I do, I buy too much.
When hungry, everything looks too tasty, and I'd buy more than I can possibly eat.
Agile teams often behave similarly in retrospectives, especially when beginning their agile journeys.
During a retrospective, team members identify so many promising opportunities for improvement that they decide to tackle every one of them.
These teams would be far better off improving at one, two, or maybe three items.
If team member's attempt to improve at more than that, their efforts will be too diffused.
On the other hand, and as much as I like focus, I don't want to go so far as to say a team needs to select a single improvement opportunity.
Many improvements a Team may attempt do not require time from every Team member every Sprint.
For example, the team may agree to focus on writing more and better automated unit tests.
Since unit test are generally written by the programmers on a team, this fantastic improvement won't require the attention of everyone on the Team.
That will leave room for a second improvement idea, especially if it's one that requires minimal effort from those already focused on their first.
Additionally, some improvements are worth keeping in mind for multiple sprints.
Writing better unit tests is again a good example.
Suppose the team achieves its goal of doing this.
That's great, but it doesn't mean the teams will do it again in the next sprint.
Some improvements take time to become ingrained as habits.
Writing better unit tests could then be something a team wants to retain focus on for multiple sprints.
I coach teams to maintain a continuous in their retrospectives.
The continuous contains items the team has improved at, but that aren't quite habits yet.
So writing better units tests, could be placed on the continuous after one or a few sprint, just to keep it visible a bit longer as a goal.
Once team members feel that writing better unit tests has become a habit they won't forget, it can be removed from the Continuous.
You don't want the continuous to bulge with items from long ago.
So pick one to three new improvement ideas.
The fewer the better, but up to 3 can also be okay.
Supplement this with a short list of things team member are continuing to improve at that aren't yet habits and so warrant a bit of visibility on a continuous.
By the way, I'm Mike Cohn.
I am a co-founder of the Scrum Alliance and Agile Alliance.
So that I may better help you, please consider leaving a comment about how your team is doing with its retrospectives.
How many items does the team pick to improve at?
Do they usually succeed at improving multiple things at the same time?
And since one of my own improvement goals is always to make videos you find helpful, let me know in the comments if there are topics you'd like me to cover.
If this video has been useful, click the Like button.
And if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

Transcript

Welcome back, everyone.
We're here for another episode of the Agile Mentors Podcast.
I'm here, as always, Brian Milner, and today I have back with us Mr.
Hunter Hillegas with me.
Welcome, Hunter.
Hey, Ryan.
How are you?
Doing great.
Good to see you and glad that you're back here with this.
Thank you.
Hunter is the CTO at Mountain Goat Software and Hunter has done a lot of programming and work with AI and some of the tools and technologies that MountainGoat
has used most recently.
So we like to have him on to having discussions around AI, and how that's changing and affecting the way we do things here in an Agile Scrum world.
And today what we thought we'd talk about is maybe a Topic you wouldn't expect us to cover, but really where AI is potentially actively making teams worse.
There's a lot of good things that it can do, there's dangers, downsides to this as well.
We want to make sure we cover that and talk a little bit about that.
I know, Hunter, we've talked a lot about how AI helps teams move faster, but we want to talk a little bit about what makes them,
how it's potentially making them worse.
What comes to your mind when you think about that initial kind of framing of that?
Are there things that initially pop in and you'd think, oh yeah, definitely here, that's a way that this could actually make the team worse?
I can think of a few things.
And some of them are maybe theoretical, so feel very human nature-y.
So I don't think they're too far afield.
And we'll have to, I think with like, with a lot of this stuff, we're going to kind of have.
See how it shakes out.
Absolutely.
I can think of a few things.
All I'll rattle off a view and we can kind see what we want to dig into.
The number one thing, or one of the first things I.
Think of is this idea of, especially if you're a software developer, if kind think about that as.
exercising that software development muscle.
If you give a lot of that over to an AI coding agent and you're not really writing the code anymore, how does that impact your ability to judge whether
the stuff that it's doing is what it needs to be doing?
Right?
I mean, I think that's one of the.
real advantages of a experienced developer using these tools is they can tell if it's doing a good job.
They can be like, oh, the way that you implemented this is how I would do it.
Or this won't work because X, Y, and Z.
If you are not in the weeds as much, or maybe at all, over an extended period of time, Does that limit your ability to be able to,
be effective as it's sort of like overseer?
I think that's an interesting question.
Right.
And you can see this in other industries too, right?
We were sort joking before, before we started, you know, if every associate lawyer in the firm is an LLM, how did they ever graduate to being the senior partner?
Right?
That same idea applies across all industries, I would think.
Yeah.
Yeah, junior developer and software, right?
I mean, I think that there, you know, we, i've talked about this a little bit.
I, think there there's a potentially, maybe not today, but at least down the line, there is, a potential to set yourself up for real heartburn somewhere down.
The road, because if, if you, and by the way, this is a mistake, Right?
If a, software company says, AI can help me replace my junior developers.
I don't need junior developer anymore.
Then I think what happens then is, all right, we keep our senior developers, but our seniors developers eventually are going away,
right?
Even if they stay with us the entire career, they're going to retire at some point.
But what's more likely is they move on.
They move onto another company.
And when that happens, I have no backfill.
I had no one who's coming up who kind of understands it to a smaller degree that we could then elevate and groom into being more successful and more established.
So I think there's a potential gap there that's going to happen for certain software companies where they've gotten rid of those junior people.
And once that senior level kind moves on, what happens?
Where do you have the back fill of the institutional knowledge for the code base?
I think it's a critical thing that a lot of companies are going to have to reckon with, you know, the balance between benefit of the tools,
but also making sure that you're still training up the people so that, that junior developer becomes a senior developer one day and all of,
all the good that comes with it.
And the other thing I wonder about is kind of related is, The sort of a potential accountability gap.
So, like, if I am like who wrote this code, right?
Oh, that thing over there did it.
I didn't do it that's not my problem.
If something doesn't work, not just because you want to yell at somebody, but if you're in service of your users and trying to make something great.
If you are, if you're constantly being able to say, Oh, well, you know, I didn't do it.
It's this thing over there.
I'm not sure how helpful that is.
Right.
The problems, the underlying problems are all still there, but if, If, don't have that sort of same, um, it gives the sort,
of cultural escape hatch for like though the model did it, that doesn't seem like a super positive thing either, which makes me wonder about,
being, able, to combat that in a way that, uh, You still have the, sort Of natural team dynamics with, when you've got these teammates,
Which are not human.
Yeah, I mean, that's a misunderstanding of AI in general that I think a lot of people don't really see honestly, because they wouldn't do that in any other area,
right?
I wouldn' t say I use this prioritization technique to prioritize my backlog, So I have to prioritize it the way it came out of this tool.
It's the tool's fault for prioritizing it this way, not mine as the product owner.
That would be silly, right?
I mean, nobody would think that, but I think you're right, that there is sort of an implication there sometimes where people think,
well, I didn't come up with the code.
The LLM came up a code on this.
So that's who's responsible.
No, you are still responsible, usually in the case of- If the balance sheet is wrong, then you can't blame Excel, it's like how that works.
Right.
You use the case of lawyers and I think that's a good example because we see these cases of where lawyers have submitted briefs that have made up things
that LLMs have given them, made-up case files, and the judge doesn't say, oh, well, I'm going to hold the L.L.M.
in contempt.
Right?
The judge says it's the lawyer who submitted this to me who's responsible.
And I that same thing applies to software.
Yeah.
I also wonder about just the team dynamics in general, right?
I mean, the communication part is a big part of all of the stuff that we teach.
If you're spending more and more of your time talking to your friendly chat bot, instead of talking your team members, what is that?
What effects will that have over time?
Will that cause knock-on effects that are hard to reason about now, but could actually be quite detrimental over long periods of time.
Yeah, I think another kind of area here is sort of the illusion of productivity.
that is sort of a fool's gold a little bit in this area.
I think a lot of people see AI as this silver bullet to solving the productivity problem when it's not, and it never is the key.
It never has been about the amount of code that can be output, right?
It's the effectiveness of it and the value that comes from it.
And AI isn't necessarily going to change that.
If you amplify, if we're already producing stuff nobody's using, then if AI increases our productivity, well, congratulations,
now you're producing twice as much of stuff that nobody's using, right?
So it's more of a, you probably will end up getting better results by just tightening up your product side of the house to make sure that what you are
working on is really valuable.
Yeah, this sort of potential disconnect between some of the metrics that a lot of Scrum and Agile teams track, like velocity and points and whatnot.
Like you could see those sort being inflated by some these tools, even if the customer outcomes don't really improve with the same.
So I can see some, these things being used in ways that sort to distort some those metrics in a way that are not healthy long-term.
especially which is something to you know definitely be aware of there's the also the sort of these so for those who haven't heard me on the show before
i am a i don't want to make it sound like i'm an ai doomer anti-ai person because i've really not ii'm a big great proponent of tools of course they're
like anything else they are tools and there is good stuff and bad stuff about them And so I also wonder, you know, even as good as their tools get at,
as they are these days for writing software, there is, it can be a, they're sort of this, oh, looks right.
Cause a lot of it sometimes might not be totally wrong.
It might be real close, but it's not quite right and so if you don't have a really great verification system, whether that's really good automated testing.
human review, whatever the acceptance criteria are.
That stuff's really important.
And you can, you know, of course, if you've got strong practices there, can help combat this.
But for teams that maybe don't or are not as sophisticated in some of those areas, it can be sort of even more dangerous because it,
It can close, but not right.
So you could be like, oh, that seems fine and turns out not fine.
Uh, and if that's not getting caught by the testing that you are hopefully doing, then that can get into some trouble.
Yeah.
You know, I think there's an element of this I've tried to describe, and I don't know if I'm describing this accurately,
but I'll kind of frame it this way.
I know a lot of people humanize their, just for example, their car, right?
They give their card name and say, oh, that's old whatever, you know?
And kind call it a name or something.
But no one, no, one thinks.
You know, the car has driven me to work the past 30 days successfully, so I trust it that it's definitely going to be able to deliver me my work today successfully.
But that same thing is not true in AI.
I think because the fact that AI does respond to us in a human-like way, that we have a tendency to over-inflate, I think,
the trust that give it.
You know, if I have given it a prompt and it's given me good answers the past 50 times I've done it, then I tend to, as a human,
kind of give a sense of trust to say, maybe I don't need to review it as closely next time because it has given to me 50 time correctly.
Right.
But the reality is you need to check every time.
Yeah, because that's not how the system works at all.
It feels like a person or, you know, varying degrees of success there.
You know it's a non-deterministic math problem, basically.
Right, exactly.
And the percentage is the same that it could be a problem every.
Time it is like flipping a coin, right?
Yeah.
If you flip a point 50 times and it comes up heads, what's the odds that is going to come up as the 50 first time?
Well, it still 50-50, Right?
Right!
There is no memory there, Right, exactly.
And that's kind of the same thing with AI, I think.
Yeah.
The other thing I worry about a lot is sort of, the premature outsourcing of judgment.
That's we, we kind of rely on, on it in an over aggressively way.
And we sort of aligned to what you were talking about at the beginning of the podcast, meaning a gap between our knowledge of senior and junior people.
But I think that that can even infect a little bit senior people in that if we start to release and turn over judgment, then we.
Kind of dull our ability to make those kinds of judgment calls.
Yeah.
And that's the thing that I think AI is really kind of lacking at is, is its ability to judge the differences between right and wrong and good and bad.
Yeah, they definitely don't have that ability, at least in no sort of, not in anywhere close to the same way that a human would,
I don t even mean to that same level, but even in its way, you know, it's completely approximated, right?
A lot of stuff seems like it can do these things because how it s been trained and the reinforcement learning that goes into it,
But it has no innate ability do any of that thing, Right?
It s not a person.
Again, I'm bullish on a lot of these things, but I think being very eyes wide open about the potential downsides is critically important,
right?
And it only could become more so as the tools get better and we see them integrated into more parts of our teams and frankly,
the whole economy.
Yeah, I think the vibe coding thing is really kind of an inflection point in this area because if you don't know anything at all about coding and you go
in and use vibe-coding, well, if there's a problem, let's use our scenario.
It does it great 50 times in a row.
Well, lets say you're building a pretty complex web app or something and 50 time in row, it's made great changes, its worked beautifully.
But then you get a bug and if the AI can't figure out how to do that, you're lost at trying to figure.
Where that bug is.
Cause you don't really understand the principle behind how things are coded.
Right.
I've seen that a lot.
Um, I'm seeing that.
Uh, some pretty harrowing accounts of people that I just, there's like Reddit threads and stuff.
on some of these topics where you feel bad for these people, right?
They built some holes, some app, usually by coded, and then you'll see their posts saying, yeah, I just deleted all of my data.
Like I don't understand why I did that.
And it's just like, you know, sorry, that can happen.
Yeah.
Yeah, I agree.
And from an actual point of view too, it can sometimes magnify, enhance some of the bad practices we have because if I'm using AI to do things that I would
normally have gone and talked to someone else about, well, now I have a communication gap and a shared understanding gap.
I don't know what you think about that, but that really worries me is that lack of shared understand that maybe falls by the wayside with AI.
Yeah, I think there's a potential for misalignment to become more prevalent and for it to not be discovered until much later in the process.
If each person, instead of talking to their teammates, is talking their own, private, effectively AI, they're all getting,
even if the answers are kind of in same ballpark, you're still all get different slices of stuff, right?
Whereas if you'd come together and talked about it as a team, that you would have come to a shared understanding, and at least we hope,
everyone would be on the same page, on going forward.
So I do think that's a problem, right?
In some ways, it's the ability to silo yourself more, which is kind of the antithesis of what we're trying to, you know,
unlock in these teams.
fighting against that natural tendency, especially, and I'll just speak for myself, you know, that, I think there are a lot of other software developers
like me, like I would rather not have to talk to anybody else.
I mean, it's just like my personality type, right?
So to be able to have a tool that lets that feeds that is dangerous in some ways.
Yeah.
Yeah, I mean, shocker there, right?
Yeah.
But yeah, and I think you just kind of set yourself up for that as being a bigger problem somewhere down the road because,
well, it starts to get to really fundamental questions, do you believe that it's better to have There are people who would say,
no, I think it's better to have one specialist who knows how to do that thing.
And I know that.
I'm not that way.
You're covered then if something happens to that person or if they leave the company or anything else.
There's just a lot that you're setting yourself up for failure if you have these kind of silos of information and knowledge.
And I think AI could feed into that a little bit.
I could perpetuate or even encourage a bit more of those silos, like you said, buckets of knowledge and I think teams really have to fight against it.
I they have be deliberate about communicating more, having more deliberate times to talk over what's going to happen and how it's gonna happen,
and the strategy, the architecture, all those things have you have put extra effort into having deliberate discussions around those.
You're right.
The rule book here is still being written as this stuff becomes more and more prevalent.
more successful teams are going to be the ones that figure that out and understand that it's not a replacement for communicating with their teammates.
Maybe they need to find new ways to do it, right?
So that they could continue to get the benefits of these tools, the added velocity, but without some of the potential downsides.
And so there may be some, some new stuff that evolved out of that, which is exciting.
Yeah, but I don't want to be all doom and gloom.
Like you said, I want make sure that we don´t leave anyone the impression that were saying, you know, stay away from AI like the plague or anything.
No way.
Yeah.
I think that there's a lot that it can do to to helpful.
So maybe that's that´s a good area for us to kind of shift gears a little bit and kind to think about One of the things we do in software development is
we try to establish guardrails to help us prevent disastrous things from occurring.
And if we have those guard rails in place, then they can kind of guide us and help to go off the deep end.
So let me start there with you and say, what kind boundaries do you think healthy teams put around AI use?
TBD to some degree.
I mean, I think some of this stuff is our best practices that have already existed.
In many different contexts, we talk about automated testing, whether it's like continuous integration, other kinds of checklists,
stuff that is repeatable, where we can say with some certainty, of course, It depends on the quality of your test suite,
but that you can say with some amount of, uh, you know, conviction, like, Oh, this does work.
This is working.
I didn't just break everything with the change that I just made.
That I would bet is only be going to become more and more important as this continues, right.
And the teams that haven't maybe been as diligent about automated testing for whatever reason, we'll probably find more,
more value in going that route as much as they can.
Right.
Are there things that you think that the team should try to avoid AI doing?
Are their tasks or focuses areas that should always stay more human-led?
That's a good question.
And maybe one that I would give a different answer to a year from now than I went today as we see the sun shake out a little bit more.
I think your example before with the, and it kind of ties into what I was just saying, but your sample previously about the lawyers who are sending out
legal briefs without with made up, hallucinated cases.
If you are presenting LLM output as a work product with zero verification, Don't do that.
That's going to get you into trouble at some point.
I mean, if you're just by coding something for yourself on the weekend and there's no stakes, then I guess it doesn't matter.
But if this is something that you are doing in your career, please don't.
Eventually you will get burned, even if your lucky the other 49 times.
So I do think that's important.
And also kind of touching on what we were talking about earlier.
Don't use these tools in a way that they try to, to replace your communication with your teammates, your, you're the product owner on your team.
You know, the various people that you are working with to get this stuff done.
That may seem like a convenience.
It may seems like productivity win.
Oh, I didn't have to.
Go to this meeting or, and I mean, I know we all love meetings and there are probably some that I wish I could get out of.
There's a lot of value there.
And if the meeting isn't valuable as a whole separate issue, right?
I don't think that's, that something else you could talk about in a of other contexts, but maybe this means that there's more time in some of those get
togethers to talk, about stuff that you wouldn't have the time to get to.
Right.
I would rather see that than a, Oh, just don' have to communicate with anybody anymore because I've got my, my magical box over here.
That's my work for me.
Right.
Right?
I know that one of the things that AI is helping us do a lot is to automate a of things previously we would take hours to do.
And I now you've done that with a a stuff that you done inside of Mountain Goat.
I'm wondering, have you run up against any use cases of thing that's you deliberately decided not to automa because it would be a better,
it's better to have in the loop more closely involved or something of that nature.
There are definitely some things that I would, I still consider high risk or too high a risk for me to feel, for trust the model.
And I am probably more trusting of it than some of my peers.
Like I know people that are significantly less trusting.
So there's, there a spectrum there, but even in my position where I feel like I've got a pretty good handle on what it's good at and what is not.
There are some things that I still wouldn't like.
I'm not letting it run wild and completely manage our online store inventory.
For instance, like not that we couldn't figure out a bunch of guardrails to protect against that, There are certain things that are high risk and they're
not so automatable in terms of like, there's not an obvious automation win where it's taking so much time where.
I definitely need to find a way to automate this.
It's just like I think I'll just keep this as a human task for now.
And who knows?
My opinion may change as some of these tools get better, but I do a risk assessment with a lot of that stuff to determine if this goes horribly wrong,
what's going to happen?
And I that's a healthy way of looking at it.
Yeah.
Well, I want to be respectful of time of people here listening to the show and everything.
And so I wanna kind of start to drive us into the finish line here about this, but we're here talking about kind sort of more of the problems with it and
how AI might actually be contributing to problems a little bit more.
People are listening of this Hunter and Hearing us talk about that and hearing us talking about guardrails and everything else,
if you could give them one piece of advice that you've learned and kind of how you have implemented AI, what's something that's kind hard fought wisdom
that feel like you learned in the stuff you done with AI so far?
Well, I do find it to be a very helpful sort of coding assistant slash junior team member.
I mean, still consider it.
To be in that role.
For me, it's sort of healthy to know what you don't know and to be aware of, you know, the places where, excuse me where.
It may not be a top performer.
I mean, I remember the first time somebody wrote a newspaper article about me and I read it and there was a ton of stuff that was wrong,
right?
And it wasn't maliciously wrong.
It was just like, they make mistakes.
And then I realized, oh, every other article I've read is that subject to that article is probably like that's not what happened.
Right.
So it kind of flipped something in my mind where it's like aha.
It is, you know, to be aware of what you don't know is so incredibly important.
And so I do go up and my usage of these tools kind of goes into that as well.
If it's trying to do something that I don' understand, then there's a much higher chance that things could go wrong in ways that i can't anticipate.
Right.
30 years now of programming experience where I, you know, I kind of know how it should be put together.
And I can say, Oh, that looks right.
Or that does not look right, or I.
I see why I did that, but it doesn't know about this other thing that I know that.
So I notice isn't going to work.
If there's areas where.
I don't have enough of that knowledge, you know, it might work out okay, but the risk level is going to be a lot higher.
So I do think that that's useful and important.
And then I also think this stuff is really fun.
fascinating to see what these things can do, especially how quickly they're changing and moving.
So if that's the kind of thing that, you know, the listener find fun as well, then if this is not an area you've jumped into,
I think you'll really appreciate it.
And I guess the last thing is just, Especially with software is sort of because these tools can take on a lot of this work themselves to varying degrees,
but they can.
The bar for like what level of software we can create gets lower, right?
It's, it's not as expensive to make software anymore.
And so there's stuff that I never would have built because it just would've taken me too long, fun projects at home or whatever,
something I'd never, would it done.
So I'm like, I don't want to work for two weeks on this, but I can do it now in an afternoon.
and so it.
That means that, that means I am doing stuff I would never have done otherwise, which can also be a lot of fun.
so I do think there is a, if you'd like to experiment and tinker with these things, there are a lots of opportunities there too.
Yeah.
I mean, I remember I've had conversations with several people that are just friends that aren't in technology in any way,
shape or form that, Hey, made this website for my wife, or I made for this little side project.
And they're able to do that now using AI in a way that they could have never done previously.
Right.
So I think it is an amazing tool and it does open a lot of doors in that way.
But you know, I do think we're still at the buyer beware kind of juncture of this and, it's not perfect.
And I, think as long as you realistically understand the limitations, then you can set up the right guard rails for whatever your circumstance.
Yeah.
I think that's, I totally agree.
You know, the hype cycle is strong, but as long as you can kind of see past that, and then I there's a lot of useful stuff that can do today.
There's going to be a few more things that you do tomorrow and a bunch more thing you could do the day after that.
So I'm pretty excited.
That's awesome.
Well, Hunter, really appreciate you coming on again and sharing your time with us.
This has been fascinating and hopefully we can have you back soon.
Thanks, Brian.
Really appreciate it.