Intro to scrum webinar

Editor's Notes

• #2: Test
• #6: The 17 signatories of the Agile Manifesto have this to say: That is, while there is value in the items on the right, we value the items on the LEFT, more. 1: Foundation of Agile is to acknowledge that we will learn as we go, and we ’ll know more after a few iterations than we know now (we being the team and the customer)—so things will change. To deliver the greatest value to the customer, we need a framework that will give us the flexibility to change in order to deliver the greatest value to our customer.
• #7: 5: Agile is about people—it ’s about finding people who are passionate about what they do, who have the ability to collaborate, and to adapt based on the shared vision of delivering a quality product that the customer values. An Agile framework emphasizes the importance of a diverse, talented, team who is measured not by status and reports, but by the working product they deliver according to their commitment.
• #8: Agile teams excel at product development and innovation because they adopt the best practices of their professional disciplines, and they focus on producing high-quality work. I bet you ’re wondering what the architects of the Agile manifesto mean by “maximizing the amount of work not done”. To me, this statement has to do with the ability of the team to work on the features of highest value and avoid doing work that customers will eventually toss out or not use. Through collaboration, communication, and transparency, “the art of maximizing the amount of work not done” is well honed by engaged stakeholders and customers, and a team that proactively seeks customer input and feedback to ensure that work is not wasted.
• #9: Quick glossary check: Incremental deliveries- refers to iterative development cycles, synonyms=iteration, sprint, timebox==a set amount of time that you determine to do work, whether its 2 weeks or 4 weeks, the team agrees to do a set amount of work during that time, and that commitment is held in place by the team, Scrum Master, Product Owner, and organization without violation. By observing the sprint boundary, everyone can remain accountable, committed, and dedicated to shared vision of the organization, product, and team.
• #10: Empiricism: learn by doing. You will not know everything (you will not know much) in the beginning. Start working, inspect the outcome (product) and your process, and commit to making real improvements to both at the end of each iteration. Prioritization: In my Introduction to Scrum classes, by far the strongest desire across teams and individuals, is that leadership clearly define the organizational and product priorities in the form of an ordered list, and stick to that priority for an amount of time that will allow the team to deliver a quality product.
• #11: Scrum provides for Transparency through the daily standup meeting for team members (and guests), the Taskboard, and the Retrospective meeting, in addition to advocating for open floor plans, and close physical proximity to enable face to face conversation. With these practices, artefacts, and ceremonies, team members have the forum in which to have candid dialogues about challenges, failures, frustrations, as well as successes, all to be built on and continuously improved and grown. In addition, the existence of such a forum as a foundation to practicing Scrum in itself implies an equality and respect for everyone, regardless of heirarchy, to appeal, to contribute, and to commit to doing their best work.
• #12: There are three roles in Scrum, the Product Owner, the ScrumMaster, and the team. Let ’s begin the discussion with a look at the Product Vision and the Product Owner.
• #13: The Product Owner is a domain expert who has deep knowledge of the product and customer needs, and is the person responsible for articulating the product vision to the team, and breaking the high level components of the Vision into implementable chunks of detail.
• #14: The attributes of a Product Owner include deep knowledge of the product, decision-making authority to prioritize the Product Backlog, seniority enough to engage, negotiate, and hold stakeholders and customers accountable for providing input and feedback. The product owner is known to be the “one throat to choke” if the product does not perform well in the market. While the team is responsible for delivering the features and functionality specified by the Product Owner, the product owner is responsible for ensuring those features and functionality are valuable to the customer and will ensure the needed/promised revenue stream.
• #15: Let ’s take a look at the role of the Scrum Master next…
• #16: The ScrumMaster role is deceivingly challenging . After all, what is the team leader supposed to do if he has no authority besides the authority granted by the team, has no direct reports, and may not even be a developer or expert in the discipline of the team members? The ScrumMaster must be passionate about the goal and commitment of the team. The mission of the ScrumMaster is to facilitate the success of the team, not by directing, telling, or checking status, but by asking powerful questions, challenging decision analysis, and ensure the team adheres to Scrum practices. The ScrumMaster must be an expert communicator, facilitator, and have the ability to convince those in leadership positions not to interfere with the work of the team, in order to free the team from distractions that would hinder the completion of the commitment of the Sprint. The ScrumMaster runs interference between the organization and the team to ensure the team has the resources, tools, and buy-in from stakeholders to accomplish the goals they have set out to accomplish.
• #17: Cross-Functional = Dev, QA, Bus Analyst, UI Designer, Architect. When a team is first formed and first practicing Scrum, they will have been very specialized and focused on their own area of expertise. As the team progresses through subsequent sprint cycles, they will develop the ability to assist one another in completing tasks, and will over time, achieve whole team accountability. A self-organizing team determines the tasks needed to bring a product feature into fruition, assigns the tasks to themselves, and commits to the tasks appropriately. No one knows better than the experts the simplicity or difficulty of completing specified tasks. Once the Product Owner has provided the feature attributes and conditions of acceptance, the team collectively assesses the complexity of implementing the feature, and determines the number of features that can be completed within an upcoming sprint cycle.
• #18: The Scrum roles are delicately balanced to ensure a minimum of structure and maximum of flexibility. The ScrumMaster and Product Owner work in tandem to provide the guidance and process to facilitate completion of the correct features, within the boundaries of the iteration. The Scrum masters acts as a shield to the team against interruptions from the wider organization, and removes impediments caused by lack of clarity regarding a user story, needed access to end users for additional background on a feature, or resources issues. The Product Owner supports the team by being accessible daily and having the needed information from stakeholders in order to make daily tactical decisions, as well as longer term strategic ones.
• #19: There are two ecosystems working within Scrum during a sprint: a flow a value that occurs between the team and the Product Owner, and the Process Flow that occurs between the team and the ScrumMaster. The Flow of Value begins with the Product Backlog, is translated into implementable tasks in the Sprint Backlog, and is output as a Potentially shippable product during the Product Demonstration (also referred to as the Sprint review). The second ecosystem occurs between the team and the ScrumMaster through Sprint planning meeting, the Retrospective, and the daily standup.
• #20: The Sprint planning meeting is attended by all members of the team who will be performing any amount of work during the sprint. Attendance by everyone at the sprint planning meeting ensures that everyone who will be responsible for innovating and creating a product on behalf of the customer, understands the underlying customer needs, business drivers, and constraints as outlined by the Product Owner. In addition, only through the collective discussion and analysis of all members of the team can the most accurate estimate and plan be created for development of the product. done in two meetings. Requirements Workshop and Design Workshop Can also have Pre-Planning (Estimation) and Product Backlog Grooming meeting If commitment is inaccurate (either under-commit or over-commit), then stories are to be added or removed. Team would then reflect in the Retrospective and accordingly adjust their upcoming commitments
• #21: Anyone may attend the daily standup meeting, but only the team members may speak. The ScrumMaster facilitates the meeting and ensures that the 15 minute time limit is strictly observed. A skilled scrummaster and experienced team will learn to keep the mood light in the standups, and over time will establish group norms and traditions to make the standups their own. Standups are not intended to solve problems or go into any detail on a topic, rather, they are a mechanism for surfacing topics that may need attention of a few team members, and can be discussed and resolved after the meeting has adjourned. In addition, impediments surfaced in the daily standup should be addressed by the ScrumMaster within no more than 24 hours.
• #22: Story Tasks (Things to Do) Work in Progress (WIP) Blocked/Impeded Done Whole team accountability
• #23: During the Sprint Review, the Product Owner, stakeholders, customers, and anyone interested in attending, is invited to see the product demo. The product owner and stakeholders are invited to comment and give feedback during the review session, and at a later date, that feedback will be reviewed, analyzed, and prioritized in the Product Backlog for consideration in subsequent sprints.
• #24: The Retrospective meeting is held at the end of every sprint and is the team ’s opportunity to reflect on what worked well and what didn’t and commit to specific actions for the next sprint to address those items that did not go well.