The Agile Manifesto just passed it's 20th anniversary last month. Some organizations started their agile journey a decade or more ago, many started in the last several years, and others are just starting or contemplating. I do not know of any companies that are not in some way shape or form at a minimum discussing the potential benefits of executing business value delivery through agile. Yes, agile is popular. But what if you are a "newbie" and just want to understand some of the language as a starting point. You have come to the right place.
Today's blog will focus on various agile terms focused on "scrum", their meanings, and some of the benefits in these areas. Let's get started.
Scrum:
What Sport is this?
Rugby. Does Scrum have anything to do with Rugby? Yes and no. Ken Schwaber, one of the founding father's of Scrum, said in a 1997 paper he wrote: “We call the approach the SCRUM methodology (see Takeuchi and Nonaka, 1986), after the SCRUM in rugby — a tight formation of forwards who bind together in specific positions when a scrumdown is called." Source: Schwaber, (1997), “The SCRUM Development Process”. We will save further comparisons and thoughts for a future blog.
Most companies using agile today utilize scrum as their guide for delivering software products. I am seeing more and more different functional business areas implementing scrum or at least pieces of the scrum framework for delivery.
Source: habr.com
Most diagrams visualizing scrum have some significant flavor of the above. Essentially, this diagram is showing an iterative delivery process with specific events, sometimes called "ceremonies" (interactive meetings) to successfully deliver a potential shippable product (business value).
Let's learn about each of these terms. We will perform a "deep dive" on each of these in the future.
Roles
Product Owner: The Product Owner (PO) is an individual person who represents the needs of stakeholders. This person defines the "What" - what needs to be delivered and what features does the product have? The PO owns the product backlog and is responsible for maintaining prioritization in the backlog. I personally think the PO is one of the more challenging roles as this person needs to work closely with business stakeholders and the delivery team and is often the negotiator of prioritization and scope between the two entities. PO's often have previous experience as a business analyst or subject matter expert.
Team (Dev Team / Agile Team): The Dev Team, sometimes referred to as the Agile Team deliver items from the backlog. Since the PO provided the "what", the Dev Team owns the "How" - how to build and deliver the product requested by the PO. Dev teams are empowered to self-organize, meaning they manage their own work vs. a project manager or dev manager telling them what to do and tracking. Empowering the team optimizes delivery and innovation and improves morale.
Scrum Master: The scrum master is a servant-leader, helps coordinate removing impediments, and a coach for the dev team. When I was scrum master, I considered one of my primary objectives was to keep all distractions and noise away from the team. This helped the team focus and often meet their delivery goals. As a coach, the scrum master guides team improvement, helps the team achieve their goals, facilitates, and helps the team become cohesive and high-performing. Scrum masters come from many different roles. They should have traits such as influence, listening, negotiation, organization, empathy, persuasion, and coaching skills.
Tools
Product Backlog: The product backlog contains all work desired for delivery by the dev team. Teams should only work an item if it is in the backlog. No "side gigs" :) Note the key word "desired". This is why it is important for the backlog to be continuously refined and prioritized by the product owner. It is highly unlikely that all work in a product backlog will be delivered - even over time. Markets change, priorities change, causing backlog items to become obsolete. Work in the backlog includes new features, enhancing features, defects, infrastructure, and anything else that needs to be delivered. A backlog contains both functional and technical needs.
Sprint Backlog: The sprint backlog is how the team is going to build the product increment. It is a subset of the product backlog. Teams usually build out a rough plan with tasks to identify and ultimately "commit" to what is achievable in the sprint. This backlog may change throughout the sprint as team members identify different items, more information becomes available, or changes on how to deliver what was requested.
Events / "Ceremonies"
Sprint Planning: Sprint planning is an event where the team determines what work they will plan to deliver during the sprint. Ideally the team will work on the prioritized items first, however there may be cases where a lower priority item is planned vs. a higher one (more on this at another time). The dev team plans the sprint based on their capacity and length of the sprint. At the end of sprint planning, the team has a rough plan and sprint goals to accomplish by end of the sprint.
Sprint: A Sprint is where the team turns the "what" into value - a potential shippable product. They execute the spring plan. It is a cadence of a short period of time (ie. 2 weeks), where the team works their magic and delivers a working product or piece of a working product for feedback by stakeholders. This is where the team sets out to achieve their sprint goals.
Daily Scrum / Stand-Up: The dev team meets daily for for a short period of time (15 minutes or less) every day to discuss progress towards the sprint goals. Typically, they assess progress, any impediments, how to help each other in order to achieve the sprint goals. It is not a status meeting, but a way for the team to inspect and adapt for success. Mandatory attendees are the dev team. Scrum master and product owner are optional attendees, although my experience has been they typically attend as well.
Sprint Review: Typically, stakeholders, the dev team, scrum master, and product owner attend the sprint review. The primary purpose is to review what was completed during the sprint, obtain input and feedback by the stakeholders on potential shippable products, and update / adjust the product backlog.
Sprint Retrospective: During the sprint retrospective, the dev team focuses on the process. Discussion usually takes place around what should the team keep doing, where do they need to improve, and what specifically does the team want to work on in the next sprint or couple sprints for improving. Only the scrum team, scrum master and possibly the product owner attend the retrospective. Do not include management or stakeholders.
Unlike traditional teams and project management you may notice Scrum sets out to empower teams, keep teams small, and deliver product and business value incrementally. Incremental delivery increases quality, speed of delivery, fast feedback, and delivery of the right product or value at the right time.
Next time we will continue our exploration of agile terminology and expand into other areas of agile. Until then, "Sprint Ahead"!
Comments