u/yukittyred

Things I wanted to see become successful:

I wanted to build many things, but currently I do not have the time or the money to do so.

Most of what I build uses the free version of AI Studio.

However, from what I have seen, it does not provide all the features needed for production-level applications, and projects still require people to review and validate them properly.

Also, from what I understand, the free version has limitations, especially regarding Firebase.

There are currently three ideas I want to build:

1. The Methodology Recommender. I consider this project mostly complete, although I do not expect it to be widely used because many people in companies are managers who do not listen rather than leaders who do. Nevertheless, I intend to keep it available.

2. A full-screen, first-person experience game that allows people without depression to understand what living with depression feels like, how people can develop depression, and why depression exists. The goal is to let players experience situations, thoughts, and emotions from the perspective of someone suffering from depression, creating greater understanding, empathy, and awareness.

3. A job hunting and company review platform that removes age discrimination and discrimination against OKU candidates. Many people over the age of 40, including those in their 50s, 60s, and even older, still want to work but struggle to find employment because companies often prefer younger or cheaper workers.

   The platform would focus on fair hiring based on skills, experience, and ability rather than age or disability status.

   In addition, the company review system would help job seekers understand whether a company is suitable for them. Reviews would include criteria such as:

   • The difficulty of the work.
   • Whether the workload is considered easy, moderate, or demanding.
   • Working hours and schedule flexibility.
   • Overtime expectations.
   • Work-life balance.
   • Management quality and leadership style.
   • Support for older workers and OKU employees.
   • Career growth opportunities.
   • Salary competitiveness and benefits.
   • Overall suitability for different types of employees.

   The goal is not only to help people find jobs, but also to help them find workplaces that match their abilities, needs, and preferred way of working.

https://project-methodology-advisor-397643982268.us-west1.run.app/

This is a decision engine designed to help to see what is the most suitable method to use in project development simulate, and calibrate the optimal project management.

I created this because I was soo stressed. Too much politics in office.

Can someone review and tell me is it suitable or not.

Or anything that I need to improve on it?

If I'm not suppose to post this here, tell me and I'll remove later.

https://project-methodology-advisor-397643982268.us-west1.run.app/

This is a decision engine designed to help to see what is the most suitable method to use in project development simulate, and calibrate the optimal project management.

I created this because I was soo stressed.

Can someone review and tell me is it suitable or not.

Or anything that I need to improve on it?

If I'm not suppose to post this here, please tell me. I'll remove this later.

I still don't understand why my company is so obsessed with making us record every single minute we work in the timesheet system.

If the timesheet doesn't add up to a full 8 hours, someone will call and ask why there are missing hours, what we were doing during that time, and why it wasn't recorded.

But then when you actually have a lot of projects going on and you record that you've been working on the same thing for a long time, they call again and ask why it took so long. They'll ask if it's possible to finish it in less time or whether it really should have taken that many hours.

Sometimes they even question why we spent time on certain work orders, meetings, or other tasks, even though they were the ones who asked us to do those things in the first place.

What makes it even more confusing is that everyone in the company is doing similar work. We're all working in the same IT company, dealing with the same kinds of projects and issues.

It feels like if you don't record enough hours, you get questioned. If you record too many hours on something, you also get questioned. And if you record exactly what you did, you still get questioned about why you were doing it at all.

Ahh...

Let's imagine a scenario. So my manager likes to micromanage. He don't know a single thing about software development using Agile. His job is making sure every single minute must be recorded and justified on our work. And every sprint have to show that more and more task is completed if possible and cannot be less. Everytime we needed any resources, no matter it is a laptop or using the meeting room, or the printer. He will ask use and want us to justify why we need it.

He tell me, we need to start a new project, and will mostly consist only on interns. He showed me an FRD file that consist of FRD and non-frd inside. Inside the file, most of it only consist of admin and management side only, and non of it involve anything on the end user side. The end user is the employees. And until now, he never want to make a meeting to get any requirements or make any adjustment on the frd file.

Most of their philosophy/idea from my previous manager is Agile means Agility. basically anything we do using agile must be fast and usable and good quality. They have SOP for software development, and criteria and rules.

Now, my current manager (same place different people only). He still uses waterfall method, and SDLC. The manager that knows about Agile and work under my current manager, had tried to teach about Agile. But he don't even want to learn about how agile works up until now, even when there is alot of oppotunity that tells him to go learn. He also will try his best to prevent anyone to take courses or studying anything. and always says studying should do outside office hours only.

My problem is, how do I even start correctly, just to make it can actually work using Agile?

This sprint was around late March to early April.

The Scrum Master also changed again this sprint.

This will be my last update for my retrospective, since I'm gone already.

---

What Went Well

1. The team improved the pipeline every sprint, reaching 100% coverage in one stream.

2. The team experimented with end-to-end (E2E) testing for one module.

3. Merge request sizes became smaller and more manageable in one stream.

4. The mobile stream gained access to TestFlight.

5. The mobile stream improved the pipeline and showed unit test coverage.

---

What Should We Stop Doing

1. Creating large merge requests (MRs). If a merge request takes more than 30 minutes to review, it should be rejected and broken down into smaller parts. Large MRs are still occurring.

2. Compiling or packaging code on the production server. Built images must be published through a private registry.

3. Using Docker Compose without defining memory allocation and network configuration.

4. Omitting specific library versions in requirements.txt.

---

What Should We Start Doing to Improve

1. Continue improving the CI/CD pipeline every sprint as a repeated proof of progress.

2. Clean up devcontainers at the end of every sprint as routine environment maintenance.

3. Ensure developers ask requesters to check with the Product Owner before doing ad-hoc tasks.

4. Provide early heads-up for demos and presentations.

5. Start implementing CI/CD pipelines for frontend projects.

6. Inform the Product Owner when a user story is too large.

7. Code reviewers should check Docker Compose files for memory allocation and network settings.

8. Include exact library versions in requirements.txt using ==.

9. Developers may create a new user story when there is a bug.

---

Previous posts: https://www.reddit.com/r/agile/comments/1uhsskw/my_2026_sprint_6_retrospective/

What Went Well

1. Developers discussed with the team, especially the Product Owner, when the time spent on a task exceeded the original estimate.

2. The team completed its first spike.

3. The team managed to deploy in every sprint.

4. The team was praised by the customer.

---

What Should We Stop Doing

1. Creating large merge requests (MRs). If a merge request takes more than 30 minutes to review, it should be rejected and broken down into smaller parts. Large MRs are still occurring.

2. Compiling or packaging code on the production server. Built images must be published through a private registry. Coordination with the relevant DevOps/support person is required.

3. Treating repeated retrospective items as only developer-level issues. Some items have appeared across multiple sprints, so they may need clearer management support or stronger working agreements.

4. Changing Scrum Master too often without giving enough time for process ownership to stabilize. The Scrum Master role changed again this sprint, and this may affect consistency in how the team follows up on retrospective actions.

---

What Should We Start Doing to Improve

1. Continue improving the CI/CD pipeline in every sprint with a specific target instead of keeping it as a repeated general action.

2. Clean up development containers (devcontainers) at the end of every sprint as part of the team’s normal working agreement.

3. Ensure developers inform requesters to verify with the Product Owner before proceeding with ad-hoc tasks, so sprint scope is not bypassed through informal requests.

4. Provide early heads-up notifications for demos and presentations as part of normal sprint review preparation.

5. Start implementing CI/CD pipelines for frontend projects to reduce hidden manual delivery risk.

6. Inform the Product Owner when a user story is too large, so oversized work does not enter the sprint without discussion.

7. Make repeated retrospective items more visible to management and review why previous actions did not change the behaviour.

8. Give the new Scrum Master enough context from previous sprints so old issues do not restart from zero every time the role changes.

---

Previous posts: https://www.reddit.com/r/agile/comments/1uhsl5r/my_2026_sprint_5_retrospective/

Next Sprint: https://www.reddit.com/r/agile/comments/1uhtev3/my_2026_sprint_7_retrospective/

This is my Sprint 5 retrospective.

---

What Went Well

1. The team managed to complete all Definitions of Done (DoDs), with the remaining pending items depending on other external teams or parties.

2. Every user story was demonstrated during the sprint review, with some demos combined where appropriate.

3. Early heads-up notifications were provided for demos and presentations.

4. Sprint review sessions were conducted with only Product Owners and developers, enabling a more self-sustainable process.

5. Work was carried out with proper records and tracking.

6. Tasks were consistently created with assigned owners.

---

What Should We Stop Doing

1. Creating large merge requests (MRs). If a merge request takes more than 30 minutes to review, it should be rejected and broken down into smaller parts. Large MRs are still occurring.

2. Compiling or packaging code on the production server. Built images must be published through a private registry. Coordination with the relevant DevOps/support person is required.

3. Treating external dependencies as something to handle only after they block the sprint. If work depends on other teams or parties, those dependencies should be made visible earlier during planning.

4. Treating sprint review as only an internal progress check. If only Product Owners and developers are present, the team may become self-sustainable internally, but product feedback from broader stakeholders may be limited.

---

What Should We Start Doing to Improve

1. Continue improving the CI/CD pipeline in every sprint.

2. Clean up development containers (devcontainers) at the end of every sprint.

3. Ensure developers inform requesters to verify with the Product Owner before proceeding with ad-hoc tasks.

4. Provide early heads-up notifications for demos and presentations.

5. Start implementing CI/CD pipelines for frontend projects.

6. Discuss with the team, especially the Product Owner, if the time spent on a task exceeds the estimated time.

7. Identify dependency risks earlier during sprint planning, especially when work depends on other teams or external parties.

8. Make recurring retrospective items more actionable. If the same issue appears again, the team should check whether the previous action really changed anything.

---

Previous posts: https://www.reddit.com/r/agile/comments/1uhscub/my_2026_sprint_4_retrospective/

Next Sprint: https://www.reddit.com/r/agile/comments/1uhsskw/my_2026_sprint_6_retrospective/

This is my Sprint 4 retrospective. Didn't manage to post because have been too busy.

Compared with the previous sprint, this sprint felt like the team continued improving on discipline and process control. Some previous issues were reduced, especially around daily stand-ups, task focus, demo handling, and server/environment terminology.

However, some recurring problems are still not fully solved, especially large merge requests, production build practices, incomplete tracking, and task ownership.

What Went Well

1. The team maintained discipline during daily stand-ups by minimizing unnecessary chit-chat and focusing on task progress and blockers.

2. Developers avoided working on multiple user stories in the same day and prioritized completing the highest-priority story first.

3. The development server was no longer referred to as the Testing and Training server. The proper Testing and Training server process through the correct support channel was followed, and the relevant person was consulted for the correct procedure.

4. Demos were not terminated or interrupted without proper instruction.

5. A new CI/CD pipeline was implemented for the Next.js template.

6. Developers informed requesters to check with the Product Owner before proceeding with ad-hoc tasks.

7. New developers gained experience customizing GitLab CI pipelines for open-source projects.

---

What Should We Stop Doing

1. Creating large merge requests (MRs). Large MRs are still occurring. Any MR that takes more than 30 minutes to review should be rejected and divided into smaller parts.

2. Compiling or packaging code on the production server. Built images must be published to a private registry and follow the proper deployment process.

3. Performing work without proper records or tracking.

4. Creating tasks without assigning an owner.

5. Treating repeated issues as normal sprint noise. Some items, such as large MRs, missing tracking, and unclear task ownership, have appeared more than once. If they keep repeating, they may point to a management or process problem rather than only individual mistakes.

---

What Should We Start Doing to Improve

1. Continue improving the CI/CD pipeline in every sprint.

2. Clean up devcontainers at the end of every sprint.

3. Ensure developers consistently inform requesters to verify with the Product Owner before proceeding with ad-hoc tasks.

4. Provide early heads-up notifications for demos and presentations.

5. Demonstrate every user story during sprint review. Demos may be combined where appropriate.

6. Make recurring retrospective items more actionable. If the same issue appears again, the team should check whether the previous action actually changed the behaviour.

7. Strengthen task ownership before work starts. A task without an owner should not be treated as ready.

8. Protect the sprint from unmanaged ad-hoc work. Asking requesters to go through the Product Owner is useful, but it should become a consistent intake rule, not just a repeated reminder.

---

Previous sprint: https://www.reddit.com/r/agile/comments/1rp303y/my_2026_sprint_3_retrospective/

Next Sprint: https://www.reddit.com/r/agile/comments/1uhsl5r/my_2026_sprint_5_retrospective/

I work in a tech-related role in a fairly layered organisation, and something has been bothering me recently. I want to know whether this is common in other companies or whether this is just poor internal process.

Recently, there was a customer/user workshop that involved an AI-related topic. The problem was that the actual AI/domain expert was not assigned to attend. Instead, the people attending were expected to “take note” of what the customer wanted and pass the message later.

To me, this feels risky. A requirement workshop should be the time to clarify the real problem, ask follow-up questions, understand the use case, and manage expectations directly with the user. If the right person is not there, the discussion becomes message passing. The customer explains something to a non-expert, the non-expert writes it down as best as they can, then later someone else interprets it again. By then, the original meaning may already be distorted.

There is also an accountability problem. If the person attending captures the wrong requirement, they may be blamed later even though they were never the correct expert in the first place. The customer may also wonder why they attended a workshop, only to be asked the same things again later because the right people were missing.

Another issue is that some technical people only join for “their part” of a meeting, present briefly, then leave before the full session ends. I understand this if they have another urgent meeting or if it was agreed beforehand. But if the meeting is planned and the customer is still discussing the wider process, leaving early can look unprofessional. Sometimes important questions only come up later after another section explains their workflow.

There is also a bigger communication issue. Training needs, project direction, and team concerns often seem to be filtered through middle layers. Section heads or managers may prepare lists or plans based on what they think the team needs, without properly checking with the people actually doing the work. Then later, the actual team members say they need completely different training or support. So the official plan looks organised, but it does not reflect the real ground-level problem.

The same thing happens with project requirements. People want a solution before the requirement, pain point, and use case are clear. Someone says, “Can we use AI for this?” or “Can we build a chatbot?” before properly understanding what the user is trying to solve. Then when the output is weak, people blame timeline, manpower, or the original scope instead of admitting that the requirement was not properly captured in the first place.

I also noticed that some teams defend unfinished or weak solutions by saying they were only given a short time to build them. I can understand that during the first release. But if months have passed and the same limitation is still there, at some point it stops being only a timeline issue and becomes an ownership issue. A better response would be, “Yes, this is a gap, and we will improve it,” instead of repeatedly blaming the original deadline.

From my point of view, the core problems are:

1. Workshops happen without the right people in the room.
2. Requirement capture becomes message passing.
3. Non-experts may be blamed for unclear or incorrect requirements.
4. Technical people sometimes leave customer meetings too early.
5. Management layers filter information too much.
6. Training or planning is done without enough input from actual team members.
7. People propose solutions before understanding the real use case.
8. Weak delivery is sometimes defended through blame instead of ownership.

I am not trying to attack anyone personally. I am trying to understand whether this is a common organisational problem, especially in larger or more layered companies.

For people who work as business analysts, project managers, developers, AI engineers, solution architects, or technical leads:

How should this be handled properly?

Should the domain expert always attend the requirement workshop when their topic is involved?

How do you avoid turning requirement gathering into broken message passing?

And how do you push for better process when the issue seems to come from management layers rather than individual team members?

For people working in office What do you need to buy and why? How much did you spent just to work?

I saw a video about it and I was shock on how they treated the kids in there.

Just wondering does it still exist these days?

Originally I wanted to get partition for my office table, but I keep getting declined by my supervisor and office admin.

Then they told me, partition is only allowed when table is connected with each other, because to prevent the things from touching to other people table.

We can't even get partition for the side and front, just to actually cover ourself nicely. Everything is open space, had to look at other people.

They say corporate admin have a strict rule on how partition allowed to get, and I think from what I understand, they just don't want to spent alot money for it.

I'm not sure is this the right tags or place but needed advice, because I feel like they just don't want to get it.

I sit beside the window But my supervisor, forced me to sit beside the toilet. Just because he don't like me keep opening the blinders.

I have conditions, and required full bright places to work, but he don't care.

No idea what should I do.

I want to ask a question.

Forget for a moment whether agencies will open their data. Assume they won't, or won't soon. What's the actual path for a private builder, freelancer, or small team in Sarawak who wants to build something real in AI in 2026?

The current map of who builds what (sourced from Borneo Post, Sarawak Tribune, The Edge Malaysia, and public agency announcements):

• SAINS — the state-owned systems integrator, wholly owned by the Sarawak Government. Holds the legacy government IT footprint. Recently launched DeepSAR, a Sarawak-trained translation LLM, and has signed MoUs with Alibaba Cloud and Accenture. Work profile leans toward delivery, integration, and infrastructure.

• SAIC (Sarawak Artificial Intelligence Centre) — established October 2024, allocated RM5 million under State Budget 2026. Has signed MoUs with Sarawak Forestry Corporation (AI for wildlife and Totally Protected Areas, Oct 2025), Sarawak Energy (Sovereign Energy AI), Insights Analytics (digital twins for energy, water, transport, agriculture), the federal Ministry of Health (AI diagnostics for skin and eye disease), and Llamatica of Spain (healthcare AI). The Edge Malaysia (April 2026) describes SAIC as the body steering Sarawak's AI policy and adoption.

• Private and startup channel — thin. Neuon AI is the visible example: RoadPlus (computer-vision road asset management) deployed by JKR Sarawak and Sarawak Forestry Corporation, RM70 million Hartamodal investment in February 2026, MoU with Runjian (China) for agri-AI in pepper and oil palm.

The question:

If you're not SAINS, not SAIC, and not Neuon — what do you build, and who buys it?

Because the conditions for solo and small-team builders have shifted in the past 18 months. The cost of shipping a working product — backend, frontend, infrastructure, even substantial portions of the engineering work itself — has dropped sharply for anyone who knows how to use modern tooling well. A competent solo builder in 2026 can credibly ship what required a small team in 2023.

That means the bottleneck for Sarawak builders is no longer capability. It's access, positioning, and market.

The new generation of tooling means a determined builder with domain knowledge and decent technical skill no longer needs an organisation behind them to ship a product. Sarawak has people who can do this work. The open question is whether the local ecosystem — procurement, data access, capital, market — is set up to let them, or whether the default path forward will keep collapsing into "join SAINS, join SAIC, or leave."

Curious what others here are seeing.

Is it normal to give tipping to the tourist guide and driver at the end of the day for tipping?

The story goes like this. We plan to go China. And I pay for everything. I pay for the travel fee, and I see the receipt included the tipping fee inside. The tipping fee is RM120 per person. So the whole time I traveling, I consider totally no need to give tipping.

Then when we travel, I heard from the other people and the tourist guide themselves they never receive any tipping fee.

So on the last few day, the tour leader tell us about giving tipping to them.

So the last day, everyone give tipping using ang pao. I got told to give also, since I didn't go alone, and I'm just a kid with a job 🙄.

All I want is to enjoy my holiday and this tipping stuff is not needed when it's already given to the travel agency.

I soo confuse, like what happen to that RM120 tipping fee that I give. And why we need to give extra tipping.

I also don't like that 道德绑架的feeling。 I think it's call Moral coercion when I translate it. Basically I don't like doing things just because someone else says their are more worst. They use 同情心 (Compassion) to make people feel bad.

Just sharing my confusion and thoughts.

Is it normal to give tipping to the tourist guide and driver at the end of the day for tipping?

The story goes like this. We plan to go China. And I pay for everything. I pay for the travel fee, and I see the receipt included the tipping fee inside. The tipping fee is RM120 per person. So the whole time I traveling, I consider totally no need to give tipping.

Then when we travel, I heard from the other people and the tourist guide themselves they never receive any tipping fee.

So on the last few day, the tour leader tell us about giving tipping to them.

So the last day, everyone give tipping using ang pao. I got told to give also, since I didn't go alone, and I'm just a kid with a job 🙄.

All I want is to enjoy my holiday and this tipping stuff is not needed when it's already given to the travel agency.

I soo confuse, like what happen to that RM120 tipping fee that I give. And why we need to give extra tipping.

I also don't like that 道德绑架的feeling。 I think it's call Moral coercion when I translate it. Basically I don't like doing things just because someone else says their are more worst.

But of course in the end depends on want to do our not. Make sure to give me the story and reasons