I will show you how bad things can happen when the agile process is misled showing the specific sequence.
STEP 1. The feature “A” is declared to be a company’s next BIG feature by the business decisions.
PMs(Product Managers/Project Managers) are assigned to build it even though they have no or little background information, but since it has been declared, they just start to write PRD (or draw wireframes) without knowing any risks or any assumptions of the decision.
STEP 2. PM says “I’ve done writing the PRD. let’s plan this feature.”
Finally, PMs finished writing the PRD or wireframes with so many grey areas like,
1. Who is our main persona?
2. Why do we need it now?(business value)
3. What is the core value for the users?(user value)
4. What are the technical costs and hurdles if we start this?
Of course, it could be better if the PMs do some user researches or any other kinds of researches for the feature, but there was no time to do. So, PMs decided to “benchmark” other services which already running the specific feature briefly.
Moreover, since PMs do not know about how big the technical costs and hurdles are, but only have vague milestone date made of the business decision. They start adjust the planing without the current resource consideration but, available timeline by the business part said. Then, of course, the engineers, and designers, they have started to blame PMs for timelines and the document that they made since there is no next plans and time estimation.
STEP 3. PM says “I’ve made the tickets on Jira, so let’s talk online for the issues that we couldn‘t cover for the prior meeting.”
Even though they have many controversial topics while doing the feature planning meeting, but since it is really hard to make every teammate join the next follow-up meeting, PMs decided to make tickets anyway with tons of unveiled assumptions.
What is worse, tickets usually are too big, such as “My page implementation” or “Login page re-design” or even “Logic refactoring” and those are even not related to the users’ value for the development. Therefore, the engineers led to make the product focusing only to the technical parts not to think about the users.
STEP 4. PM says “It seems design is probably done soon enough, how’s development process?”
Since the tickets are too big, it takes a long time for engineers to develop the whole chunk. And since it takes a long time, PMs have no way to figure out how it goes and how long does development going to take and may lose the faith for the teammates about time management. On the other hand, engineers are doing their own best to deliver the ticket and disappointed for the PMs’ blame and get overwhelmed and stressed.
STEP 5. Engineer says “The design guide is not the same as the PRD (or wireframes) that we had discussed from the beginning. What should I do?”
Since this feature has decided urgently, many business requirement changes constantly and PMs need to follow up all business, product issues about this. While doing that, each teammate does their best to make viable and useful in their assumption without the communication and it may lead to the different ways that the first purpose aimed. PMs readjusts the goal and way, but since there was no proper justification of “Who will get the value for, and what is the main value that we need to focus on the first release” teammates complain about the decision.
STEP 6. One team member says “Are you sure that the button is there? Not quite fit for me tho.” And the other says ”…… What??!”
Since the main thesis and core concept do not adjust and shared to all teammates, assignees perform what they have thought. not what the team should focus on(since it is not there!). So conflicts between teammates are emerging constantly and even uprises as a serious arguing between two or three. If the purpose and main goal.
STEP 7. Engineer says “I knew it, but I did not build it since it was not on the requirements. So, it is the PM’s fault.”
While developing the product, engineers may face the edge cases that PMs could not cover, but since the team morale broke down(or engineers are suppressed by the development time) the engineers decided not to share or develop the issues. when the issue founded, the engineers find excuses for the time and requirements without the user value.
The problem is not able to find the issues(okay, it is the problem too), but not sharing the risks as soon as the teammate discovered is a big problem.
STEP 8. QA says “We couldn’t test yet. we cannot deploy it.”
Since the scope is enormous and too big to cover at once, and the testing only finishes in the end, testing time consumes a lot and since the development chunk is too big, engineers have a hard time finding the issues since it pasts a lot.
STEP 9. We have found a major issue on the production. Need to rollback now.
And the worst case, the feature, that causes the product team’s really having a mental and physical wound, will delay or even cannot release to the public.
STEP 10. PM says “We spend too much time on “A” Feature. We will skip the retrospective and go on for the next feature since we failed.”
Since the deployment to the public is delayed(or even canceled), the team decided to start “fast” to make another feature without any retrospectives or the post mortems, and make the same mistakes on and on and on…
By doing so, teammates fall into the burnout for continuous failure and endless choky interactions/sprints and leave the team.
Have you guys ever experienced such a thing? if so, I will explain why it happens and how can we make the product better on the basis of the user value.
