The Daily Standup

How Can an Agile Coach Build Self-Efficacy of The Team? What is Self-efficacy? “Self-efficacy refers to an individual’s confidence in their ability to complete a task or achieve a goal. This concept was originally developed by psychologist Albert Bandura” 1. One way is to create a blameless postmortem, rather than pointing fingers on each-other for the mistake which is already committed, explore all contributing factors to the incident, factors can be technical/non-technical, process failure or the human error, irrespective of who is in-charge of each of these activities, Agile coach can help the team to focusing on the issues and bring them back on track, let’s say if the team is oversimplifying the root cause and if they are concluding that the issues is caused by a single factor or individual, then you have to step-in and pull them back. How can an Agile coach help to boost self-efficacy? How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Psychological Safety In The Agile Community Summary of Key Results

• We define the Agile community as a global knowledge-sharing community with many smaller subcommunities. Research has shown that psychological safety is an essential predictor of members’ intent to continue contributing to virtual communities.
• For in-person interactions, most participants (N=160) experience a moderate to high level of psychological safety (3.9 on a scale from 1 to 5). For online interactions, most participants experience a low to moderate level of psychological safety (2.9).
• The behaviors that participants typically experience are the rejection of (new) ideas (37.1%), tribalism (24.5%), and not feeling heard (19.6%). 4.2% reported no experience with behavior that lowered their psychological safety. The most common strategy for dealing with this is for participants to stop contributing or withdraw from the community (55.2%). A tenth of participants reported lowered emotional well-being (9.8%). 11.2% of participants report no effect on them.
• We found no significant difference in reported psychological safety by gender. However, women report substantially more dismissal of their views and tend to withdraw more from further interactions. A significant difference was found when comparing between age groups. The youngest cohort (26–36) reported a high level of psychological safety, which then dips to the lowest level (36–45) and trends up from there to the highest level for the oldest cohort (66+). We also found significant differences between roles, with facilitators and trainers reporting the lowest level of psychological safety.
• Participants identified three primary factors contributing to lower psychological safety: poor debating skills (36.4%), dogmatism (30.8%), and self-promotion (16.1%).
• According to participants, the three primary strategies to improve psychological safety are more community engagement and leadership (21%), improving the quality of dialogue (19.6%), and personal coping strategies (10.5%).
• Future studies can replicate this study to analyze trends and compare psychological safety between different communities.
• We identified several limitations to our research, which primarily impact the degree to which the findings can be generalized to the global Agile community.
• Whether the level of psychological safety is too low or good enough is a normative one that is up to the community. However, research shows that the intention to share knowledge is lower when psychological safety is low. If we combine this with observed differences in gender, role, and age, knowledge sharing may be harmed, lowering the diversity of those contributing.

How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Why Is Customer Loyalty So Important? For those who don’t know, UX principles are guidelines used to create products that provide the right kinds of experiences to users. They focus on usability, functionality, and how users feel and respond. Here’s a quick rundown of those principles:

1. Discoverability: Users should easily find the features they need.
2. Feedback: Users should get immediate and understandable responses to their actions.
3. Consistency: Design elements and behaviors should be uniform throughout the interface.
4. Simplicity: Keep things simple and free from unnecessary elements.
5. Affordance: Design elements should indicate how an object can be used (like buttons that look clickable).
6. Accessibility: Ensure that all users, including those with disabilities, can use the product.
7. Efficiency: Users should be able to complete tasks quickly and easily.
8. Error Prevention: Minimize errors and make it easy to recover when mistakes happen.
9. Flexibility and Customization: Allow users to customize their experience or choose how tasks are performed.
10. Visual Hierarchy: Guide users to the most important information with clear visual cues.
11. User Control and Freedom: Users should feel in control of the system and not get trapped in unwanted states.
12. Emotional Design: Evoke positive emotional responses for a memorable and satisfying experience.

How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Five Factors to Consider when Prioritizing - Mike Cohn Not only do you need to build the right features, you have to build them in the right order. I want to share five key factors you should consider when prioritizing a product backlog.
 Value
Naturally, you need to consider how valuable a feature will be, value is a nebulous term. Most work a team will pursue will be valuable to users. But other work may be valuable just to the team. Still other work may be valuable to both users and team members.
For example, consider refactoring: improving the structure but not the behavior of code. Because this makes code more maintainable or easier to change, developers value refactoring and often request time for it.
Still, the cost of refactoring is usually justified by the way it benefits users, too. If code is more maintainable, users should experience fewer bugs. Similarly, improved code means that users should receive new features in that area of the product a bit more quickly.
 Learning
When prioritizing a product backlog, consider how much the team will learn by developing each backlog item.
For example, when a team develops a preliminary version of a feature, team members get feedback on whether users like it and how they’re using it. If users love a feature, enhance the feature or consider other things like it.
Other learning is about how to build the product. This might occur when a team uses a new technology for the first time. They might learn if the tech works as promised, or they can develop as quickly with it as they thought, or whether it might be useful elsewhere in the product.
Learning about what to build and how to build it are both valuable.
 Cost
The third thing to consider when prioritizing is the cost. The largest cost is usually the team’s effort to develop a feature. Most teams estimate the effort product backlog items in story points but some estimate in person-days, ideal time, or other similar units.
In some cases there may be additional costs that should be considered. A current common consideration is the ongoing cost of delivering features that rely on various AI products. These products often include small per-use fees but those can certainly add up at scale.
Regardless of the unit in which a team estimates their product backlog items, and that cost to develop and support a feature should factor into an item’s priority. For example, an item a team estimates as 5 should be prioritized higher than a feature estimated at 20 if all else is equal. This is true whether these are story points, person days, person hours, ideal time, or any other unit.
 Risk
The fourth factor to consider when prioritizing is the risk inherent in developing the product backlog item. If something is risky and you need to do it, do it early. You want to know whether that risk is going to materialize.
On the other hand, if a feature is risky and you may not need to develop it, delay working on it until it becomes clear you need to do it.
 Dependencies
The final factor you should consider when prioritizing is dependencies between product backlog items. Some items may not be high priority on their own, but they’re necessary for delivering other items. When that’s the case, the enabling but lower-priority item needs to be moved higher on the backlog in order to be done before the item dependent on it.
 How to Combine These Factors
While all five factors are important, I don’t recommend combining them through some fancy formula.
The value of a feature and its cost–our first and second factors–are the most important.
I recommend continuing to prioritize based on these but then using the other three factors to adjust priorities and resolve conflicts.
For example, suppose a product owner or product manager has prioritized an item such that it won’t be done for another three or four iterations based on its value and risk.

Driving a 16 Foot FULLY LOADED Box Truck 2349 Miles in 2.5 Days Across The USA... Just listen to this special episode where I detail the top 3 things I learned making this drive for the third time.
How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

What is Product Strategy Discovery? What is product strategy discovery? In a nutshell, it’s about finding a problem worth solving. More precisely, it is the process of developing a product strategy whose implementation will likely create the desired value and impact. It applies to a brand-new product as well as an existing one whose current strategy is no longer valid, for example, as market conditions change. This means that strategy discovery is crucial not only to developing an initial offering (MVP) but also to achieving product-market fit and sustaining growth. Unlike product discovery, it is not primarily concerned with determining the right solution, finding the right features, and creating the right user experience. Instead, strategy discovery focuses on the problem space. It explores if a large enough group of people has a big enough problem that can and should be addressed. Strategy discovery therefore sets the scene for product discovery

Product Discovery is an exciting part of any Design Project, and it may be a Designer’s first exposure to working with executives. During a Project Kickoff, CEOs and other executives may come to discuss their grand vision of the project or help establish its overall goals. Unfortunately, as a result, many Designers stay silent and wait for other voices to speak up and finish talking. However, that approach may cost you a lot of time and effort. Decisions you make during the Discovery process can often significantly impact the final product, and asking three specific questions during this process can help you do that.
How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Connect Teams to Customers and Avoid the Mistake of Backlog Fixation

1. Product team members couldn’t care less about the customer.
2. Product teams need to stay focused on the work.
3. Only the product manager should perform discovery with the customer.
4. The product team can’t connect from a different time zone.
5. Product team members are incapable.
6. There are too many customers for the team to cover.
7. This will bother customers.
8. The backlog is much easier to follow than a customer’s whims.

How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Does Every User Story Have To Be Small? Small user stories are essential to success with agile. When it’s time to bring stories into an iteration, I always want them to be small.
But larger stories have their place as well–especially for something you're not going to work on imminently.
Suppose you have just begun work on a new product that will include a set of reports. Because this is a new product, there is nothing to be gained by writing a bunch of small user stories around each one of those reports at this point, especially since you don't yet even know all of the reports that will be needed.
At this stage of the project, having one big reporting story rather than a bunch of little ones keeps the size of the backlog more manageable. You'll have one entry in your tool instead of 15 or 20. That's much easier to manage.
Further, if you do write all the small user stories, one per report, it gives the impression that you've thought of everything. Early in a project, that's probably not true. New reports will be identified and some that are asked for initially may not be necessary.
Don’t fall into the trap of thinking every story needs to be small from the beginning. They don’t. Instead, plan for stories to shrink in size and grow in detail as they move closer to being brought into a sprint. For most teams, this will happen during the product backlog refinement meeting one or two sprints before the iteration planning where they’ll be considered.
Letting timing dictate story size will help you succeed with user stories and with agile,
How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

The Power of Baby Steps - Atomic Habits Have you ever watched a baby learn to walk? For the past month and a half, she’s been carefully moving with her little walker, taking wobbly steps, testing her balance, and building her confidence. Now, she’s starting to take her first steps without it—unsteady, unsure, but determined.
What amazes me most is her persistence. Every time she falls, she doesn’t get upset. She just gets up, laughs, and tries again. She’s not in a rush; she’s focused on those tiny steps forward, enjoying the process along the way.
It’s a powerful reminder of the importance of baby steps.
In business, it’s easy to feel like we need to make giant leaps or do everything at once. But those giant leaps can leave us overwhelmed, off balance, and scrambling to keep up. The truth is, lasting success is built on steady progress—small steps that move you closer to your goals, one day at a time.
So, if you’re feeling overwhelmed or stuck, remember this: baby steps matter. They add up. And they’re often the surest path to success. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/