The Agile Daily Standup - AgileDad

Key Stakeholder, Stakeholder, Interested Party - What Is The Difference & How Do We Control WIP? In this episode join V. Lee Henson as we explore the differences between these three roles and how they each impact organizational, team, and individual WIP. 

Happy Halloween Everyone! Enjoy this SCARY Agile episode. Try not to SCREAM!!! 

Celebrate with me as my oldest daughter turns 22 and learn what makes her the greatest daughter EVER!! 

When asked what facilitation is, I have heard Scrum masters describe it as Sending meeting invites and booking conference rooms, Starting and ending the events on time, Creating reports or sending out M.o.M and Ordering refreshments and pizzas Is this really facilitation? Facilitation originates from the Latin word facile, which means ‘to make it easy.’ The facilitator is thus the person who makes things easier for others. Facilitation is a stance that is closely associated with the Scrum master role, primarily Facilitate the events as needed or requested. Facilitate stakeholder collaboration as needed or requested. The intent of the Scrum master’s stance as a facilitator should be to enable self-management and increase the team’s effectiveness to achieve better outcomes. The outcome is the team’s responsibility when facilitating events, and the Scrum master is there to help arrive at it. By facilitating events, the Scrum master helps tap into the team’s collective intelligence and ensures the team’s ownership and commitment to it. Though Scrum masters are knowledgeable and have a contingent interest in the outcome, they do not let this influence the team’s work or the decisions. To be an effective facilitator, the Scrum master takes a neutral stance regarding content and the intended outcome. The Scrum master, however, is not neutral to the decision-making process and actively contributes by diagnosing and intervening as needed. The facilitator role of the Scrum master is particularly beneficial given the complexity of the work the teams are dealing with and the cross-functional team’s diverse perspectives and interests. The Scrum master will take on diverse perspectives of creativity, consensus, collaboration, and creative conflict resolution to create and sustain a participatory environment for the teams to engage, design, and own their outcomes. Effective facilitation of the Scrum master tackles the power dynamics in the team and provides an environment where all voices and perspectives are heard and have influence. The Scrum master, as a facilitator, enables self-management by setting up a participatory approach to decision-making and moving away from cascading decisions of the traditional top-down approach. Facilitation enables collective ownership, improves capability building, and dramatically increases the probability of successful team and organizational change. The typical pattern seen in great facilitators is their unwavering belief that People are intelligent, resourceful, and desirous of doing the right thing. The title of an individual has no bearing on their ability to add value. A team’s decisions are far superior to those of a lone individual. The key indicator of effective facilitation is when the team feels they did the work and are accountable for the outcome.

Agile teams are self-organized, which means they operate with the absence of central authority. Dev Managers often ask, "So what's my role?" If your Development Manager is not the Product Owner, or the Scrum Master, or a contributing pig or chicken, they are left asking the obvious question, "What do I do?" The legacy answer was to "stay out of the teams way!"  Agile enthusiasts agree this is the standard answer for a team governing itself.  However clever, this answer left the industry with a puzzle. Now, finallly, the puzzle is solved. The Stable Framework™, an out-of-the-box quality framework that can be dropped into Agile, provides the answer. As the Master Chief, the Development Manager assumes their rightful place as the quality champion.  They are responsible for seeing to it that requirement reviews, architecture reviews, code reviews, estimation procedures, and all necessary testing gets completed using the best structural safeguards known to the team.

1. Business outcomes Those are metrics related to the organization’s goals like: increase revenue lower operating costs grow market share grow profit margin reduce churn rate Business outcomes allow the company’s stakeholders to track the company’s progress (e.g., “profit margin grows by 5%”). Business outcomes are lagging indicators. On top of that, product teams typically cannot influence them directly, so they need to be translated into product outcomes. 2. Product outcomes At the product level, we may decide that a way to decrease the churn rate (impact a business outcome) is to increase customer engagement, measured, for example, as the total number of hours customers watch videos every month. As Joshua Seiden noticed in Outcomes over Output, these outcomes are always associated with a change in human behavior. He defined outcomes as “a change in human behavior that drives business results.” An example of the product outcome may be the following metric change: “every month, customers spend, on average, 30 minutes more watching videos.” Both business and product outcomes outlined above align with Continuous Discovery Habits by Teresa Torres. 3. Customer outcomes Customers do not care about the Output (features). The three types of customer outcomes, as defined in the Product-Led Growth by Wes Bush, are: Functional outcomes. The core tasks the customer wants to get done. For a car, it’s traveling from point A to B. Emotional outcomes. How do customers want to feel or avoid feeling as a result of using your product? Is it safety, freedom, joy, taking care of the environment, or adrenaline? Social outcomes. How do customers want to be perceived by others by using your product? What does Tesla tell others about your status or values?

7 great ScrumMaster Interview questions:  Question 1: How would you organize the Sprint Planning? Question 2: What factors should a Scrum Team consider at the Sprint Planning to determine a feasible Sprint Goal? Question 3: Is it acceptable for the Product Owner to introduce a business objective for the upcoming Sprint that resembles a list of random work items? Question 4: Is it okay to use a ‘Definition of Ready?’ Question 5: Is it a helpful idea for the Developers to plan all work for the whole length of the Sprint during Sprint Planning? Question 6: Your organization highly values when deliveries match forecasts. Is that something worrisome? Question 7: Should a Scrum Master worry about the utilization rate of the Developers?

Can I get a Hell Yeah? I recently had the privilege and honor of meeting and presenting at a conference with none other than Phil Barth. Many of you have said that I may be the most interesting person on the planet. I learned today that this is not true. Phil has appeared on Who wants to be a millionaire, written a best selling book, and has a son in a rock band! His message was inspirational and it is available in Kindle and AudioBook format for FREE on Amazon! You need to check this guy out as he is one of my Heroes! 

A product owner is generally either the visionary behind a product or a representative of the users and customers. This means the product owner is perfectly positioned to write the product backlog. I don’t, however, think a product backlog should be written entirely by the product owner. Others such as team members, users, stakeholders, customers, and so on should be encouraged to contribute their ideas to the product backlog. The good ideas they contribute will be prioritized highly by the product owner and be developed. No matter how talented the product owner, it is unreasonable to expect them to think of everything. Developers, users, and others will bring different perspectives that will lead them to think of backlog items beyond what the product owner would have identified. I think a study cited by Chip and Dan Heath in their book Switch helps illustrate this. In the study, people associated with a university were asked to brainstorm all the ideas they could for solving the university’s chronic parking problem. Researchers eliminated “wacky or impractical options.” (For example, I would have suggested hiring aliens to use their UFOs to move cars to off-campus parking locations.) On average, each study participant identified only 30% of the full set of ideas that were generated. In other words, no one person can be expected to come up with more than about a third of the possible options. Product owners can probably do better than 30%. They are, after all, usually the experts on their product. But I think this study supports having anyone willing contribute to the product backlog. That can be as simple as a stakeholder emailing an idea to the product owner. Or it can happen more formally in a story-writing workshop in which stakeholders, users, team members, and the product owner collaborate to generate product backlog items. In general, the more people who are thinking about a product the better—but the product owner should definitely write some of the product backlog items

Every organization, everywhere is trying to achieve Operational Excellence, whether they have the vocabulary for it or not.  Operational Excellence is delivering exactly what your customers need (effectiveness), with a minimum of byproduct (efficiency). The Agile Mindset helps organizations achieve the first goal. The Stable Mindset helps organizations achieve the second goal. Agile is about close customer feedback, short feedback loops, prioritizing value, and planning at multiple levels to support quick changes where necessary.  Stable is about removing human failure from the execution process. A typical IT organization wastes about 35% of its work efforts redoing work that wasn’t done correctly the first time. Some groups report 50%, or as much as 80% of their efforts are attributed to this “Hidden Factory.” When expressed as a dollar amount, the effects are alarming. The Stable Framework™ was designed to combat this problem. It’s a combination of the latest Agile and Lean techniques and provides a simple, but robust Quality Management System “in a box.” Heavy emphasis is placed on customer and supplier relationships, and Kaizen-based continuous improvement. Altogether, these tools provide organizations with the transparency and conscientiousness needed to execute the right steps, the right way, every time. . Stable can be used to compliment a Scrum development team, or it can be implemented as a complete substitute for Scrum. In addition to Development, Stable is applicable in Operations, Implementation, DevOps, and any other work containing repeatable process steps. The Stable Framework™ is comprised of one Process Asset Library, two roles, three domains, four core meetings within a repeating time-box, and five quality principles. Taken together, they form a tool-set enabling IT groups to perform six process improvement fundamentals.