Good evening. Tonight I prepared a post to reflect on a new mindset of how staff can handle communication to both themselves and the community in a way that can lead the site in a much better direction. With the Batch Search Engine and Weekly Batch Updates coming into play the previous few weeks, this thread should be a nice way to brainstorm changes in how we as a community can improve the site. The other thread "What's happening in here" felt like a river flowing in too many directions, so this thread will be focused on feedback concerning different approaches in communication.
There will be some terminology that I will explain during this post and I will connect it with how it applies to how the development team here could be improved.
From what I've seen being on staff, the Development Team seems to have been going by Waterfall development methodologies. Even though FFR is not a business anymore, the concept here still applies. Waterfall is the old school way of software development which involves going through a plan for a very long period of time (9 months is a usual time frame). The phases usually go like below:
Define > Design > Develop > QA > Deploy
However, even the development team here doesn't seem to be following the above phases. QA is definitely missing because there isn't any testing environment that I know of (and you guys certainly know about some disasters that happened). So the current development process is a fragmented version of Waterfall which itself is already messy and covers too long of a time period to be effective.
A few weeks ago when I considered the idea of starting Sprints for the Batch, it was to see how goals could evolve over time and how progress could be measured in smaller workable chunks -- AGILE methodologies. With Waterfall, an example of a story would be "Create a New Engine" that would go over a long period of time (like I mentioned, it could be 9 months). Let's take a step back and consider all the things wrong with that:
- The Define stage shouldn't stop when development starts. Feedback is important for determining what other people really want to experience in an application, and not having smaller intervals of time (2 weeks in Sprint-Style Structure for instance) doesn't allow people to give feedback about what can be changed in the application.
- If defects appear in the application or a certain process isn't working out, there's a gigantic application that has to be investigated instead of a smaller application that gets built up incrementally. Incremental changes allow both the development team and the users to discuss what features should be added or improved.
- The time frame is too long and the story description is too broad. There isn't any clear way of breaking up the work here, and then that runs into issues of task assignment, changing requirements, and so forth.
How does this tie into FFR?
- The Weekly Batch Update Thread was meant to be a way to give the community an overview of what's being worked on in a certain week and see how incremental changes can lead to higher goals. Some weeks are slower than others, and the users in the community can see what's been finished and what still remains to be done within a Sprint.
- The Batch Search Engine is only in its initial version right now and still has a long way to go. I didn't wait until later to add some more features to it. Why? I wanted feedback from the community, the actual users, about how it could be improved. Think about the enhancements that could be made to the Batch Search Engine: Including Length and Notes for file submissions, Permissions, Judgment Progress Bars, all in one place. Starting with an initial idea and then expanding on it by receiving community feedback allows for a trust-building relationship to work on improving the site's processes in smaller incremental chunks.
Logging Work
Logging Work also seems to be a big issue. It's one thing to define and assign tasks, and it's another for staff to actually log their work. I have to commend Silvuh and lurker for being diligent about updating their logged hours for their assigned judgment tasks; logging work allows a team to see if a task is taking longer than originally anticipated and gives a better idea of the next steps to take. For instance, when Silvuh had logged 20 hours for Set 3 in the September 2014 Batch, I offered to finish the other half that he had left to judge, but he felt confident enough to go through the rest of it himself. He ended up logging 32 hours (Silvuh was ok with me saying this). This information is not necessary to reveal to the public, although it's an example that illustrates how logging work allows tasks to be done in incremental pieces instead of having staff be overwhelmed by some broad big story.
With all that said, I have a few questions to ask:
- What was done well with the Weekly Batch Update, and what about it could be improved?
- What about the Batch Search Engine could be improved? What else would you as a user want to see?
- Would you like to see something similar to the Weekly Batch Update from the development team?
- How can ideas be split up into smaller incremental pieces that can be expanded?
Some great ideas could come to life from this thread. I'm thinking about potentially making a progress bar visualization to help the FFR Wiki thread display progress on certain tasks for instance. I feel like we as a community need to define work in smaller pieces that can build up over time, and that's also part of the New Jugdment System idea that will be finalized later this week.
There will be some terminology that I will explain during this post and I will connect it with how it applies to how the development team here could be improved.
From what I've seen being on staff, the Development Team seems to have been going by Waterfall development methodologies. Even though FFR is not a business anymore, the concept here still applies. Waterfall is the old school way of software development which involves going through a plan for a very long period of time (9 months is a usual time frame). The phases usually go like below:
Define > Design > Develop > QA > Deploy
However, even the development team here doesn't seem to be following the above phases. QA is definitely missing because there isn't any testing environment that I know of (and you guys certainly know about some disasters that happened). So the current development process is a fragmented version of Waterfall which itself is already messy and covers too long of a time period to be effective.
A few weeks ago when I considered the idea of starting Sprints for the Batch, it was to see how goals could evolve over time and how progress could be measured in smaller workable chunks -- AGILE methodologies. With Waterfall, an example of a story would be "Create a New Engine" that would go over a long period of time (like I mentioned, it could be 9 months). Let's take a step back and consider all the things wrong with that:
- The Define stage shouldn't stop when development starts. Feedback is important for determining what other people really want to experience in an application, and not having smaller intervals of time (2 weeks in Sprint-Style Structure for instance) doesn't allow people to give feedback about what can be changed in the application.
- If defects appear in the application or a certain process isn't working out, there's a gigantic application that has to be investigated instead of a smaller application that gets built up incrementally. Incremental changes allow both the development team and the users to discuss what features should be added or improved.
- The time frame is too long and the story description is too broad. There isn't any clear way of breaking up the work here, and then that runs into issues of task assignment, changing requirements, and so forth.
How does this tie into FFR?
- The Weekly Batch Update Thread was meant to be a way to give the community an overview of what's being worked on in a certain week and see how incremental changes can lead to higher goals. Some weeks are slower than others, and the users in the community can see what's been finished and what still remains to be done within a Sprint.
- The Batch Search Engine is only in its initial version right now and still has a long way to go. I didn't wait until later to add some more features to it. Why? I wanted feedback from the community, the actual users, about how it could be improved. Think about the enhancements that could be made to the Batch Search Engine: Including Length and Notes for file submissions, Permissions, Judgment Progress Bars, all in one place. Starting with an initial idea and then expanding on it by receiving community feedback allows for a trust-building relationship to work on improving the site's processes in smaller incremental chunks.
Logging Work
Logging Work also seems to be a big issue. It's one thing to define and assign tasks, and it's another for staff to actually log their work. I have to commend Silvuh and lurker for being diligent about updating their logged hours for their assigned judgment tasks; logging work allows a team to see if a task is taking longer than originally anticipated and gives a better idea of the next steps to take. For instance, when Silvuh had logged 20 hours for Set 3 in the September 2014 Batch, I offered to finish the other half that he had left to judge, but he felt confident enough to go through the rest of it himself. He ended up logging 32 hours (Silvuh was ok with me saying this). This information is not necessary to reveal to the public, although it's an example that illustrates how logging work allows tasks to be done in incremental pieces instead of having staff be overwhelmed by some broad big story.
With all that said, I have a few questions to ask:
- What was done well with the Weekly Batch Update, and what about it could be improved?
- What about the Batch Search Engine could be improved? What else would you as a user want to see?
- Would you like to see something similar to the Weekly Batch Update from the development team?
- How can ideas be split up into smaller incremental pieces that can be expanded?
Some great ideas could come to life from this thread. I'm thinking about potentially making a progress bar visualization to help the FFR Wiki thread display progress on certain tasks for instance. I feel like we as a community need to define work in smaller pieces that can build up over time, and that's also part of the New Jugdment System idea that will be finalized later this week.
Comment