I’ve been practicing Scrum recently and have learned a few things. Scrum is not a technical term, but a Development process, specifically a category of Agile Development.
Generally speaking, in a complete Scrum process, there are three roles: Product Owner, Scrum Master, and Scrum Team. Everyone does their job, starting from a Product Backlog, breaking it down into sprints, and then updating everyone’s progress with daily stand-up meetings and kanban (often with burnout charts).
There are books on Scrum practice that (even) mention Planning Poker as a way to accurately predict development cycles.
Sounds nice, right?
Far from it.
Scrum is like a Teenage Sex for a lot of startup teams, and if you can’t do it, it’s bullshit.
In fact, agile must practice, practice is the most reliable experience. The reason we complain that agile doesn’t solve the problem is because we have a wrong understanding of it.
Many people think of agile as:
-
Adopt a “just do it” attitude and avoid any form of management, procedures and rules.
-
During the daily stand-up meeting, chant into the air and casually move tasks on the board
-
It’s a boss stunt. It’s a process
It seems that every day there is output, in fact, the devil does not know these products have no use, the code pile over where the meaning. The team stared at the sky without knowing what to do next.
Why is that?
The problem is not the agile process, but the team itself.
Startup teams are always developing new products or services under extreme uncertainty.
This itself has no way to follow, no trace to explore, not around the core of the problem to do the product, there is no way to get the gist.
So to do agile development well, you must:
Clarify product demands and conscientiously complete the commercial closed loop
-
To what extent does your product solve users’ problems and is it 10 times better than existing solutions
-
How much money can you make from the product, and where is the ceiling
-
Will users actively recommend your product? Where is the natural growth engine
-
Can you figure out with your eyes closed how big your product needs to be to cover your team’s expenses
Face reality and solve the core problem
-
What you are doing now is addressing the real product needs of your users, or the product needs of your own imagination
-
Is there a way to quickly fix the problem by putting the fire online, rather than waiting a week after the new version
-
Output requirements for user scenarios, don’t worry too much about format, Done is better than Perfect
Implement the people, not the process
-
Tasks should ultimately be broken down to people, and progress should be tracked around a person’s daily workload/difficulty, rather than being transparent about progress
-
Be empathetic and ethical. If your interface or documentation is poorly written, it’s unprofessional. Do unto others as you would have them do unto you
-
Simply break up tasks and complete them. Your teammates won’t describe a simple task as difficult, and neither will you.
Self-deception is a no-no in Agile development. No matter what tool you use (like Geekbot instead of a morning stand-up meeting), it won’t stop you from fooling yourself.
Pretend the kanban has tasks (even if is a simple issue and should be split into several), pretended to design products is user want, but there is no research a bad product, meaningful pretended to collect data, the result can’t get any help decision-making information, pretended to brush weibo every day is looking at the industry dynamics, actually really is in the brush.
In these cases, the team leader must immediately One One, the biggest problem with water skiing alone is that it makes the rest of the team feel deeply unfair.
Agile allows you to create life-saving growth opportunities before your product dies, and the sooner you launch and get honest feedback from your Alpha users (who are usually open to flaws at this stage, but unequivocal in their questions), the more chance you have to correct the trajectory.
If a software development goes live, and the end customer doesn’t experience it at all, is it successful?
Scrum has to go back to its business roots to be useful, otherwise it’s fake.