The Agile Daily Standup - AgileDad

Moovin On Up - Farmer Finds Cow On The Roof Of His Barn! Today, we're talking about a story that made headlines for its unusual circumstances. So sit back, relax, and get ready to laugh! This story really MOOved me! I know I know... It is time I sent these cow jokes out to pasture. Our story takes us to the small town of Flushing, Michigan where a local farmer made a hilarious mistake. The farmer, who wishes to remain anonymous, was out working in his fields when he noticed something strange. He looked up and saw a cow perched on the roof of his barn! Yes, you heard that right. Somehow, this cow had managed to climb up onto the roof of the barn and was just standing there, looking down at the farmer. The farmer was completely stunned and had no idea what to do. He called the fire department and they quickly arrived on the scene.Now, you might be thinking, "How on earth did a cow get onto the roof of a barn?" Well, it turns out that the cow had been grazing in the nearby field when it saw a pile of hay on the roof of the barn. The hay had been stored there by the farmer and the cow must have thought it was a great place to snack. So, it climbed up onto the roof to get to the hay. After some quick thinking, the fire department was able to safely rescue the cow from the roof of the barn. The cow was unharmed and was returned to the field, where it will hopefully stick to grazing on the ground from now on. And that's our funny news story for today. Who knew cows were such talented climbers? We hope this story brought a smile to your face and brightened up your day.

60 Second Sprints on The 5 Scrum Events... Ready? GO! The first event is the Sprint. The Sprint is a time-boxed period where the team works to deliver a potentially releasable product increment. A Sprint usually lasts between one and four weeks. During the Sprint, the team plans, designs, develops, and tests the product increment. The Sprint is a crucial event because it provides a fixed time frame for the team to work within and allows them to focus on delivering a specific set of features. The second event is Sprint Planning. Sprint Planning is a time-boxed meeting where the team plans the work they will do during the upcoming Sprint. During this meeting, the team decides what items from the Product Backlog they will work on and how they will achieve their Sprint Goal. The Sprint Goal is a statement that describes what the team will accomplish during the Sprint. Sprint Planning helps the team understand what they need to do and how they will do it. The third event is the Daily Scrum. The Daily Scrum is a daily meeting where the team comes together to plan their work for the day. During this meeting, each team member answers three questions: What did I do yesterday? What will I do today? Are there any impediments in my way? The Daily Scrum is a quick meeting that helps the team stay focused and aligned on their work. The fourth event is the Sprint Review. The Sprint Review is a time-boxed meeting where the team demonstrates the product increment they have built during the Sprint. The team presents the product increment to stakeholders and receives feedback. The feedback is used to help the team improve the product increment and plan for the next Sprint. The Sprint Review is a crucial event because it provides an opportunity for the team to receive feedback and make changes to the product. The fifth and final event is the Sprint Retrospective. The Sprint Retrospective is a time-boxed meeting where the team reflects on the Sprint and identifies what went well and what could be improved. During this meeting, the team discusses their processes and identifies areas where they can make changes to improve their performance. The Sprint Retrospective is an important event because it helps the team continuously improve their processes and work together more effectively.

Understanding Agile Product Strategy Agile Product Strategy is an iterative approach to product development that focuses on creating and delivering products that meet customer needs while also achieving business goals. Let's dive in! First, let's define what Agile Product Strategy is. Agile Product Strategy is a process that involves understanding customer needs, defining business goals, and creating a plan to deliver a product that meets those needs and achieves those goals. It is an iterative process that involves testing and iterating on the product to ensure that it meets customer needs and achieves business goals. So, how does Agile Product Strategy work? The first step in Agile Product Strategy is to understand customer needs. This involves conducting user research to understand customer needs, preferences, and behaviors. Once customer needs are understood, the next step is to define business goals. This involves identifying what the company hopes to achieve by developing the product. The next step in Agile Product Strategy is to create a plan to deliver the product. This involves breaking down the development process into small, manageable pieces called user stories. Each user story represents a small piece of functionality that is required to deliver the product. The user stories are prioritized based on their importance to customers and their impact on business goals. Once the user stories are prioritized, the team begins to develop the product. The development process is broken down into short periods of time called sprints. Each sprint lasts between one to four weeks, and at the end of each sprint, the team delivers a working product increment. After each sprint, the team conducts a review to assess the product increment's performance against customer needs and business goals. Based on the review, the team may make changes to the product and plan for the next sprint. So, what are the benefits of using Agile Product Strategy? The first benefit of Agile Product Strategy is that it allows companies to quickly respond to customer needs. By breaking the development process down into small, manageable pieces, companies can quickly test and iterate on the product to ensure that it meets customer needs. The second benefit of Agile Product Strategy is that it helps companies achieve their business goals. By prioritizing user stories based on their impact on business goals, companies can ensure that they are focusing on the most important features of the product. The third benefit of Agile Product Strategy is that it promotes collaboration and teamwork. By breaking the development process down into sprints, the team works together to deliver a working product increment at the end of each sprint. In summary, Agile Product Strategy is an iterative approach to product development that focuses on creating and delivering products that meet customer needs while also achieving business goals. By breaking the development process down into small, manageable pieces and working in sprints, companies can quickly respond to customer needs, achieve their business goals, and promote collaboration and teamwork.

Are Your User Stories Opened or Closed? A useful concept to keep in mind when writing or splitting user stories is to always try to write closed user stories. A closed user story is one that finishes with the user having achieved a meaningful goal. I like to think of the user being ready for a coffee break after finishing a closed user story.As an example of a story that is not closed, consider this one from a job search website: “As a recruiter, I can manage the job ads I’ve placed.”This story is too big to be useful. Managing is not something a user is ever done with. Think of a manager in your office. Does that manager ever get to say, “OK. It’s 10 A. M. I’m done managing. It’s time to get some real work done.”Of course not.The word “manage” is the big clue that we’re not working with a closed user story. Similar words might be administer, administrate, maintain, and others like that.Let’s see how you could take this user story and make it closed.First, consider what manage really means in this context and write stories that better reflect those meanings. On a job search site, managing the job ads means reviewing incoming applications, checking the expiration dates of ads, deleting any applications that are not a good fit, and modifying ad text to better find candidates.So, you would write stories about specifically those ideas. The initial story is then replaced by:  As a recruiter, I can review resumes from applicants to one of my ads so that I can pass good candidates to the hiring manager. As a recruiter, I can change the expiration date of an ad so that we continue to get more applications for open positions or stop receiving applications for positions that have been filled. As a recruiter, I can delete an application that is not a good match for a job so that no one else wastes time reviewing inappropriate candidates. As a recruiter, I can modify the description of any job in an ad so that we are attracting the best possible candidates for the position. Each of these stories is closed. The recruiter-user achieves a meaningful goal by completing any of these stories. Or, as I’ve said, the user could feel it’s time for a coffee break. “Ah,” the recruiter thinks, “I’ve finished reviewing applicants. Time for a coffee break.” Or, “Ah, I’m updating expiration dates. Time for a coffee break.”.Writing closed stories is good not just for benefits to the users, but because they aren’t so open-ended. A story that says only that a recruiter can manage job ads could mean something very different to team members than it does to the product owner. The product owner might have thought that included running reports on the effectiveness of certain keywords in the job titles. After all, the product owner might think, having those reports is vital to managing the ads effectively.The process of writing closed stories can drive out some of that vagueness that leads to the team misinterpreting a product owner’s intent.Are there times when an open story is a good idea? Yes—they’re fine as big, big, placeholder epics on a product backlog. So, early on in a project it would be fine to have a story about managing the job ads. But, as the time approaches to work on that story, you’ll want to split it into closed stories, each of which allows the user to accomplish a meaningful goal.

What Is The Difference Between a ScrumMaster and The Agile Coach? First, let's define what Agile methodology is. Agile is an iterative approach to project management and software development. It emphasizes collaboration, flexibility, and continuous improvement. Scrum and Kanban are two of the most popular Agile frameworks. Now, let's talk about the roles of a ScrumMaster and an Agile coach. A ScrumMaster is responsible for facilitating the Scrum process and ensuring that it's being followed correctly. They act as a servant-leader to the team, removing any obstacles that may prevent them from delivering the product increment. The ScrumMaster also helps the team continuously improve by facilitating retrospectives, and they protect the team from external distractions. On the other hand, an Agile coach is a more comprehensive role. They work with multiple teams or the entire organization to implement Agile methodology. Agile coaches are responsible for creating an Agile environment that supports continuous improvement and enables teams to work effectively. They work with teams to identify and resolve problems, and they provide guidance on Agile best practices. An Agile coach also helps to foster a culture of collaboration, learning, and innovation across the organization. So, what are the key differences between a ScrumMaster and an Agile coach? The first difference is their scope of responsibility. While a ScrumMaster focuses on facilitating the Scrum process for one team, an Agile coach takes a more holistic approach, working with multiple teams or the entire organization. The second difference is their focus. A ScrumMaster is primarily focused on ensuring that the Scrum process is followed correctly and helping the team to continuously improve. An Agile coach, on the other hand, is focused on creating an Agile environment that supports collaboration, learning, and innovation. The third difference is their level of involvement. A ScrumMaster is very involved with the team, working closely with them on a daily basis. An Agile coach is less involved with individual teams, but they provide guidance and support to help the teams improve. Now that we've discussed the differences between a ScrumMaster and an Agile coach, let's talk about how they work together. An Agile coach can provide guidance and support to a ScrumMaster to help them better facilitate the Scrum process. They can also work with multiple ScrumMasters to ensure that the Scrum process is being followed consistently across the organization. In addition, an Agile coach can help to identify any systemic issues that may be preventing teams from working effectively. They can work with the ScrumMasters and teams to address these issues and improve the overall Agile environment. In summary, a ScrumMaster and an Agile coach are both important roles in Agile methodology. While a ScrumMaster focuses on facilitating the Scrum process for one team, an Agile coach takes a more holistic approach, working with multiple teams or the entire organization. They have different responsibilities and purposes, but they work together to create an Agile environment that supports collaboration, learning, and innovation.

Evidence of Cheese-Making to Circumvent Lactose Intolerance 6000 Years Ago Found in Poland! Analysis of neolithic pottery shards shows that in Northern Europe, where poor soils and low sunlight made primitive agriculture extremely difficult, people were making cheese in places like Poland potentially as far back as 9,000 years ago. Examinations of perforated vessels not only found the presence of the dairy protein casein which suggests the creation of curd-enriched products from raw milk, but casein from cows, goats, and sheep, suggesting they were making a kind La Tur long before most other forms of modern food production ever reached the continent.

Can Agile and ITIL Play Nice Together? - What is Agile Service Management?  Join V. Lee Henson as we discuss how a very strict ITIL world and Agile play well together. 

How do you know if the ScrumMaster role is right for you? Join one of our FAVORITE Agile Coaches, Keis Kostaqi as we learn a little more about whether or not you fit into this accountability. 

Let’s talk about detail in user stories. Many of us are drawn to detail. It feels good to know exactly what features a product will contain. And it feels good to know precisely how a feature will be implemented. Knowing the details of something feels good. It certainly feels better than being in the middle of the morass of open issues, undecided features, and general uncertainty that make up most projects. To bring order to the chaos, we attempt to remove uncertainty by adding details to our product backlog items.  But is it the right time? 

Join V. Lee Henson, President and Founder of AgileDad as we discuss how to handle On-Call incidents. Do NOT let your duty phone turn into a doo-doo phone.