What is Scrum and its Applicable Scenarios? Source

Translated

Image Source: Unsplash

I. What is Agile Development ？

It is difficult to say clearly what Agile is in a sentence or two, perhaps because it is just a loose framework with principles but no specific methods. One thousand projects may have 1000 ways of working with agile. Agile only makes sense in practice, and learning Agile without practice is almost impossible.

There are 3 sets of agile frameworks that are most often discussed: Scrum, Agile, and Kanban. Scrum and Agile are more common regarding software development, especially for the C-end. Kanban is good at making complicated and trivial work simple and orderly, such as customer support and other transactional tasks.

When talking about Scrum, we have to mention the PDCA cycle (as shown in the figure below), which is a way of working that is good at exploring and creating. Scrum is a series of ideas, principles, and practices derived from the PDCA cycle approach. (such as backlog, sprint, and user story). It is not a methodology or a formula. Although it has some methodological systems, we cannot copy it but only refer to it. Different projects may require very different workflows, which can be called Scrum.

PDCA Cycle

Image source: Product Plan

Suppose I only use one sentence to describe Scrum. In that case, it is: Scrum fully accepts the uncertainty of the prospect, adopts an exploratory approach, and takes a development method with the ultimate goal of helping customers realize value. Emphasizing exploration and neglecting prediction is the essential difference from linear development methods.

Scrum steps consist of one Sprint (iteration) after another, so if a novice wants to get started with Scrum quickly, perhaps the most important thing to learn is where a Sprint (iteration) starts and ends, as follows:

1. Draw Up and Evaluate Backlog Lists

My team calls the backlog a requirement list/requirement pool, which refers to a function list that may be developed. Backlog sometimes comes from the demander, but it should come from the foresight and insight of the product manager. All proposed items (whether they seem valuable or not) can be put on the list first and then maintained. Maintenance includes:

• Evaluate the value, construction period, and urgency of the requirement. Remove the false and preserve the true requirement;
• Prioritize the real requirements that are worth doing;
• Track the processing progress.

Although my team is used to calling the backlog "requirements," I prefer the term "value" or "feature" in " Essential Scrum." "Requirements" in team communication mostly refer to the operator's needs rather than the user's. It implies that the product is responsible for the operation, and it implies that the team can predict the success of the product, which is more in line with the waterfall rather than the agile approach; the term "value" highlights the value-oriented nature of agile, where each role has a unshirkable responsibility to achieve user value. The term "feature" highlights the spirit of Agile exploration, which acknowledges that what we are doing now may not be what users need and can only be judged after testing. Both "value" and "feature" reflect agile principles better.

2. Sprint Kick-off Meeting

After clarifying the priority of requirements in the previous step, all team members (at least all roles) sit down to plan the requirements to be done in the next iteration; that is, we need to plan the highest priority requirements in the requirements table. Some requirements with low priority but easy to do in actual work will also be scheduled for the next iteration to maximize the workload.

After full communication, we should reach a consensus on what should be accomplished in the next sprint. The kickoff meeting marks the start of the sprint, and no one should change the content of the sprint once it has started. Once the requirements enter the development stage, no one can change them.

Why is consensus a prerequisite for agile?

If everyone has no consensus and does not attach importance to communication and multi-party participation - it is easy to waste time. If we are allowed to modify the plan before the "sprint," - it is easy to forget responsibility or delay the construction period. Each sprint delivers the minimum feasible product - based on their interests, it is impossible to define the minimum feasible product, and it isn't easy to agree on the results and direction during testing and iteration.

For example, suppose a company's development team undertakes the requirements from three different product lines of ABC. In that case, ABC has a different understanding of user value (they all want their product lines to occupy as many resources as possible). It isn't easy to achieve agility at the company level. However, companies can combine the benefits of both types of development through a convergence approach - critical point review + finalization of the final solution as late as possible.

3. Daily Scrum

The company calls all roles for a short meeting at a fixed time each day, trying not to exceed 15 minutes, to announce the progress of the work.

4. Achievement Display and Evaluation

After the development is completed and tested, all the roles will be convened again to show the development results and then put them into use.

5. Sprint Retrospect and New Sprint Planning

For what has been accomplished, everyone sits down and retrospects to see what went well and what could have been done better. Everyone immediately starts planning for the next sprint after the retrospect is completed.

II. The Essential Difference Between Agile and Linear

As mentioned above, the emphasis on exploration and the neglect of prediction is the essential difference between agile and linear development methods. As follows:

• Agile development: focus on uncertainty → focus on the exploratory and good ability to meet an emergency → value-centric
• Linear development: focus on certainty → follow protocols and focus on good design → process-centric

Agile development acknowledges the uncertainty of the environment, team, users, and itself and believes that market demand is unpredictable, so it accommodates trial and error, moves forward with exploration, and calibrates its direction in real time while seeking progress in stability. The reference point for calibration is user value, and the key indicator for evaluating work is whether it creates value for users.

Linear development focuses on the content of certainty. It emphasizes the accurate prediction of the market, and the design should be as perfect as possible according to the prediction. The blueprint must be strictly presented. Therefore, the evaluation standard is also the degree of realization of the blueprint, even if the market feedback may not be positive.

III. Agile Applicable Scenarios

Linear development focuses on prediction to facilitate process control, but the difficulty is that it must determine the correct design scope at the beginning; Agile development is an exploration-oriented process that can constantly dig into the essence of problems and refine real problems. However, the disadvantage is that large projects have high time costs when crossing departments.

Since the agile method aims to achieve user value, and the waterfall method aims to present the blueprint perfectly, it is easy to agree on the value in the project team. Still, in cross-team, cross-department, or even cross-company projects, the value understood by all parties may not be the same. Agile development can only be applied if they can reach a consensus on user value (the product to be delivered). If they cannot reach a consensus, they can only reduce communication and time costs through process control. At this time, the waterfall development method should be adopted.

According to the advantages and disadvantages, both agile and linear development have their application scenarios -- the Cynefin framework commonly used for strategic decisions is very suitable for explaining the application scenarios of agile development, as shown below:

1. Simple Domain - The Known of Known

When causality is obvious, the treatment is "Sense-Category-Respond," such as exporting sales data/making chocolate cakes. Scrum is not a good choice, and we should choose the method that has been proven correct.

2. Complicated Domain - The Known of Unknown

We need experts to diagnose and find the right answer. The processing method is "Sense-Analyze-Respond," such as building the underlying database/building a spaceship. Scrum is not the best solution, and experts should handle the solution.

3. Complex Domain - The Unknown of Unknown

Causality can only be reflected in the review. It is difficult to predict and can only be known afterward. The handling method is "Probe —Sense — Response," such as launching new products/raising young people; this is where Scrum is best.

4. Chaotic Domain- The Unknowable of Unknown

In a chaotic situation without any causality, we need to react quickly and not have time to think. The way to deal with it is "Act-Sense-Respond," like the 9/11/system outage. Scrum is not the best solution, what we need is immediate action.

5. Disorder

If you don't know which of the above situations belongs, this situation is a disorder, waiting for the participants to stabilize the situation to one of the above four situations.

The software development process may involve the above domains, but most e-commerce products (especially the C terminal) are in a complex domain. We need to be flexible in practical work.