Home
Creators
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register Favorites Keys Review DMs Logout
Community
Telegram ThePornDude
Home Creators Posts Import Register Favorites Logout

Welcome to 2020 🤖 (Patreon)

Published:
2020-01-01 18:24:37
Imported:
2026-06

Content

Anatomy of a failed sprint

On Nov 26, a top Agile consultant advised me to start working in two week sprints. We tried the first one in December.

The aim was to release a Beta version of the prototype sex scene to Operators+. Things started well, but near the end of the sprint it became apparent that I wasn't going to hit the target.

What I tried

A massive dose of personal effort, in order to get the target delivered as fast as possible. Professionally, I cut everything that wasn't related to working on the prototype with my own two hands: I stopped coördinating the team, communicating with the community, and thinking strategically about the project. Everything was ignored until I could get the Beta out.

In my personal life I stopped exercising, eating clean, and working to regular hours. That was stressful, so I started drinking more to control the stress.

Results

I got the Beta out to Operators on Dec 20th (9 days late). As soon as it was done I went down with a bad cold, which I think was caused by the stress and unhealthy lifestyle. On Dec 24th I released the Beta (with a few tweaks and fixes based on the Operator feedback).

I was disappointed with it. The vision in my mind was that it was going to be awesome, but in reality it still needs work.

What I think I should have done

Stuck to the two-week sprint discipline. I should have declared the sprint a failure, reflected on the new situation, and set up another sprint to advance from there.

Changes I'm planning to make

Stick to the sprint discipline, even when things go wrong; rescue failed sprints using follow-up sprints, not private surges of personal effort.

Coördinate the team better.

Release Beta versions more often – the community insights from the most recent one were great and helped me quickly understand how to improve the design.

Some Agile experts in our community (including Ammut, William Urqhart and xGrotesc) advised me to change the way I set sprint goals. Their advice was to tie them to features, not releases, which is wise.

Plan in time for personal R&R.  If I don't, I'll be forced to make time for sickness, low productivity and burnout.

I think 2020 can be better if it's a series of small advances every two weeks, instead of one massive advance every few months.  That will (a) keep the momentum up, (b) allow the community to make more frequent course corrections via feedback and hopefully (c) make me better at time estimates.

That's basically my big plan.  What do you think?

Next stepsI'm planning to kick off a new dev sprint on Monday 6th Jan.  I'll aim to post a sprint plan here tomorrow, and will invite feedback on it over the rest of the week.

Okay, that's it for today!  In the spirit of getting in more R&R I am now gonna go for a run, cook something healthy (eggs & chickpeas) when I get back, and get an early night.  See you back here tomorrow with an update.

Files

Comments

Penelope

Also you can adjust, if two weeks is too fast, you could make it three or even monthly. I think what matters most is that progress is actually progressing. None of us expect you to always make a goal. We all struggle with that whenever creating something that also involves learning and adjustments to implement the way you want to see them. And sometimes it may not look like what you want, and you just have to let it go for the release to get the feed back to grow closer. What matters is just staying in communication, recommitting and making updated time frames that make sense and actually work for you, your schedule, your team, the community, and are realistic.

FRsinewave

Why does it have to be a sprint? It is stressful and I don’t think that’s constructive imo.

Fritz T Coyote

Never did get comfortable with agile development buzzwords. Set realistic goals. Don't make yourself sick over arbitrary deadlines. Get out in the fresh air, have fun, eat and sleep healthy. Your customers would prefer honest delays due to unexpected complications in the work instead of failures in the project methodology. Use the old NASA trick of Plan For Success by setting realistic goals and allowing for Murphy. Did I mention setting realistic goals? Take care of yourself, this should be fun!

Sheol

Normally SCRUMs daily standups with the team, should be enough for you to recognize that some planned feature won't be finished at the end of a sprint. The core idea is it to cut the features in tiny tasks of work, which may take 1-2 days at most. That way you see after a few days already if there will be a delay, since after each day some tiny part of the feature should be done. Noticing right at the end of the sprint that the goal won't be meet is a clear sign that your tasks were too big and you couldn't reflect on it on a daily basis. Of course separating a feature into really small tasks, is quite some overhead, since it requires you to be able to judge each tasks really quickly and put them in a sprint and then cut them down into tiny tasks before the sprint starts. Maybe "hardcore" SCRUM also isn't the best way to organize your work, since the big selling point of SCRUM is, that you can plan your work and features rather consistently over the whole time and react to tiny changes your client wants rather quickly... while at the same time telling your client directly how much you can do and when something will be done. If that isn't an important thing for you, maybe something like Kanban or other variants of agile might be better.

Siao

As mentioned by someone previously, sprints revolves around tasks delivery if you focus on features or releases tied to a sprint you are setting yourself up for delays. This is because for agile methodology you are supposed to release even if you failed to finish all planned tasks for the sprint and during reflection understand why did you fail to achieve the tasks. A task can be "updating 5 stories" or "fixing this bug"

Ano123

I think what you are missing is a scrum master or project manager that absorbs all the organisational work. You are managing people, projects, and still contributing to sprint work. Even when I shave worked in small teams the team lead only did maybe 30% of the amount of sprint work compared to others. You should expend more time upfront to plan even if that means no obvious output for a few sprints.

bsnick

Frankly I think you need to start small. Make an estimate of what you think you can accomplish in 2 weeks, then cut it in half and add some smaller tasks as 'extras' that you'll work on if you finish the others. One constant 'extra' would be reviewing what is already done to see if it still jibes with the current direction/state of the project and looking for bugs. Basically your eyes are bigger than your stomach. I think you're always going to dream too big for these things and need to reduce the tasks in either number or size or both. Not give up on the grandiosity, just look for ways to break the bigger (and not so bigger) tasks into smaller steps

Toadsith

Good luck! Small, fast sprints make great sense to me. Trust your team to handle their work, make sure everyone has free time to refuel, especially you, and test out new features and ideas with the community frequently instead of doing big, dramatic reveals. I think the development will progress better with lots of quick steps instead of a few giant leaps.