When I was introduced to Scrum, I thought it was Agile. Later I would find out that most people get confused between Agile and Scrum. That is, most people think Agile and Scrum are the same, but to be fair some know it is different. If you are like me, I am adding a video to kick us off.
You now understand the difference between Scrum and Agile methodology. Scrum is one of the many frameworks under the Agile umbrella. Since Scrum is part of Agile, it is important to understand a bit about Agile, a mindset, before we discuss Scrum. The Agile Mindset focuses us on why Agile and how we interact with each other. It is not about the process and practices. It is about four value and twelve principles that guides us to perform and adopt the practices and behavior we practice daily.
The four Agile values should be viewed as a point of emphasis and never as one and not the other.
- As valuable as process guidance is or tool efficiency brings, those need people interaction. How do we get better in using tools or following the process, interact with the people? These are effective based on the people who perform them and those that use it.
- Except for the document required outcome, we want to emphasize working software for IT projects, or non-IT outcome for non-IT areas, as a slice of the final outcome. Delivering the increment, outcome, is how to measure progress to the final over outcome. In IT area, the potential shippable product increment is a term commonly used.
- Previously we touched on the importance of people interaction. When working to satisfy the customer, we need collaborate frequently with the customer. If we expect to achieve a release target, agreement, or contract, it is really important to partner with the client or stakeholders to understand their want, needs, and pain points to deliver. Are there milestones, also known as MVPs, required along the way?
- Last one is on journey. Unless we are repeating the same thing over and over, nothing is a predictable. If we cannot predict, we need to welcome change. Working to incorporate changes along the way will yield the success, profitable outcome we are working to deliver and satisfy clients.
Along with values, the Agile Mindset contains twelve principles to help guide us. The principles talk to delivering customer satisfaction, working to deliver increments on a continuous pace, welcome changing requirements at any time, motivating and supporting the team, trying to have face to face conversation whenever possible, having a self-organizing team, continuous improvement to mention on a few of the principles. As you read them, you begin to notice a change to what was common at the time they were first discussed and paradigm shift in how we collaborate, organize, and delivery, and improve. Establishing process and practices that are based on the values and these foundation principles is how we live Agile Mindset and behaviors it requires.
Now let’s get back to the Scrum framework, not a development methodology, which can address complex adaptive problems while productively and creatively delivering products of the highest possible value. Scrum seeks to minimize risk by delivering the risky items early rather than the end and using the time boxes to learn (trial and error) while delivering each slice of the solution. Maximize value by delivering potential shippable slices (increments) on consistently and frequent time line. Why frequently? Using fast decision cycles, maybe 2, 3, 4 weeks, but not longer, to succeed under conditions of uncertainty to create value. Working with new team members, on a new product, and following an unfamiliar process? Need to learn much? Using 2, 3, 4-week time boxes, can be helpful to learn, inspect, adapt (improve) quickly which allows me to travel the cone of uncertainty safely and quickly.
Scrum is an iterative, incremental and disciplined approach to product development based on the theory of Empirical Control and five Scrum values.
Use of Empirical Process Control facilitates inspection and adaption based on the team’s experience and experiments in its delivery of the current product backlog, manage risk, address dependencies, and establish team predictability. Empirical Process Control relies on three behavioral practices, commonly shown as the pillars that support, transparency, inspection, and adaptation. Transparency provides everyone a clear view into the state of the project using the common language used by the team and stakeholders. Prevention of process or product outcome requires everyone to inspect(ion) of how and what is being created as Agile Principle 12, reflection. Once a sprint we share the next slice of the outcome via the Sprint Review to allow everyone to inspect and the team interaction and process during the Scrum Retrospection. Each time box should always yield some new learning. From these inspections, all deviations to our plans, process, and product are adjusted quickly. This is why the time box is 2, 3, or 4 weeks long. Inspect and adapt at a regular internal.
All team have values to govern their behavior and begin to create a culture. The Scrum Guide help the team by guiding the team with these five values. Focus on the sprint. Commitment to the work required to deliver the product increment. Respect each team member and their individual and collective contributions. Openness, along with transparency and honesty to build trust. Courage to do what is right and necessary.
Before we discuss the Scrum process, let me introduce the three roles and a short list of responsibilities.
o Product Owner (one person, ideally from the business)
- Manages the product return on investment.
- Knows the product market and market trends.
- Manages the stakeholders and their request.
- Works with the stakeholders and team to decompose big request to request small enough to complete in days during the time box (Sprint). You do not want one large request for the Sprint. It should be small request commonly called User Stories.
- Orders product backlog items to best achieve goals and missions.
- Ensures the product backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
- Ensures the development team understands items in the Product Backlog to the level needed.
o Development (to mean the people to develop the solution) Team or Team
- Self-organizing group which tells the development team how to turn Product Backlog into Increments of potentially releasable functionality.
- Cross-functional group of people with all the skills as a team necessary to create a product Increment. Scrum recognizes no titles for development team members, regardless of the work being performed by the person. Scrum recognizes no sub-teams in the development team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual development team members may have specialized skills and areas of focus, but accountability belongs to the development team as a whole.
o Scrum Master (which is not automatically a Project Manager)
- Coach, Mentor, Facilitator, and Teacher for the Scrum Team and the organization.
- Facilitates meetings, conversations, and improvements.
- Removes impediments, even runs interference, so the team can remain focused.
- Servant Leader. Leads without authority and puts the team first.
If you attended the beginner session in June 2020, you may recall mention of a Product Owner video. Agile Product Ownership busy at work in a Nutshell.
Let begin a brief discussion on the Scrum Framework life cycle.
We start at the left with Product Backlog artifact. In the beginning, the team works with the PO to define the Product Backlog items which commonly contains large (blue) request which support the vision. These are refined, with the help of the stakeholder, to make the smaller items. Refinement continues until they are small enough to be completed in a few days within the time box, Sprint. These are the pink boxes in the backlog pyramid. Polices also exists in Scrum. One common policy for the team doing the refinement is the Definition of Ready (DOR). The DOR is the entrance criteria for pulling work into Sprint Planning. It is not a Scrum defined artifact, but it is an artifact.
Speaking of the Sprint Planning, the PO ranks the small request that pass the DOR policy in preparation of the Team discussion on what we wish to pull for the Sprint Backlog artifact. Thereafter, the team determines their capacity and use it to determine what work tasks are need to deliver the user story (request). Ideally one person will not work on a user story, there is a team to members of the team deliver the user story in a few days. They need to understand and commit to how they plan to deliver the stories they pull.
Once the team commits, they get together daily to discuss their progress, get in sync with a next 24-hour plan. It is a common to answer three question, completed work since last Daily Scrum, plan to complete for the next Daily Scrum, and what is impeding my work? The Scrum Master and Product Owner attend to support the team. It is a team meeting.
During the Sprint the Scrum Team (everyone) will refine the items in the Product Backlog. The stakeholder may join them to assist them refine the requests.
On the last day the Scrum team prepares to do some show and tell based on what passed another policy, Definition of Done (DOD). DOD is another artifact, but not a Scrum defined artifact. The PO facilitates the Scrum Review meeting that the Dev Team will show what was completed. The stakeholders will share their thoughts. Wonderful team!! I like it, but there are adjustments needed! Sorry, this needs work. The key is for the Scrum Team to be transparent about their increment and experience. The stakeholder to help the Scrum Team better understand their needs and changes, if any, to create a potential shippable product increment. This is the 3rd Scrum defined artifact. All the artifacts represent work conducted by the team and are designed to provide transparency and opportunities for inspection and adaptation.
When does a user story (smallest request) become a potential shippable? Right after the stakeholders approve the work during Sprint Review.
The last meeting (called events in Scrum) is the Sprint Retrospective. It is for the Scrum Team only and the value /outcome is the 12th Agile Principal. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Or, how can we get better at what we do?
The card at the lower left of the picture are used to determine the relative size of the smallest request items (user stories) using a concept of relative size versus estimating time estimates. If my ripe strawberry is a relative size one. My apple is twice as big (2). However, my very large Myer lemon is one and one-half larger than my apple. My sister found a Myer lemon tree that grows lemon almost as large as softball. These are the first three cards in the 1, 2, 3, 5, 8, 13, 20 sizing card deck. Question? If I can eat five strawberries or two apples in three-minute time box, how many strawberries can I eat in three-minute time box after I finish one apple?
One finally thought on the Scrum Framework. It is not designed to be all inclusive. It is more about the Sprint LifeCycle. Though quality of the product, team, and process are its focus, it does not mean more client, quality or engineering concepts and practices should be excluded. For example, XP engineering practices use to focus the Scrum Team on quality software practices, such as Test-Driven Development, Coding Standards, Continuous Integration, Continuous Deploy, Automated Testing and Feedback loops early and often. Usage of user stories in the planning game. Lean task board and waste. DevOps connects development to production.
Note: This is a summary of the May 23 and 30 Taste of Agile.
Reference the Scrum Guide to read the Scrum Guide, November 2017 version.