Forums Thread

Dang it we forgot to go over the add hours for members and agendas.

From what i can see is if a member wants more work then the stand 5 hours we can assign a non sprint item to them. What idea did you have for this can you explain it a bit more?

Thanks,
James Fleming

I'd like to move away for having to assign them extra tasks for two reason:

1) I'm not sure their always going to be able to do more than 5 hours. Sometimes task run long or the amount of time a person can give to the project may change week-to-week.

2) There's a lot of overhead and delay with people needing to ask/wait to have an non-sprint task assigned to them. It would be better just to have to ability to make some addition non-sprint task available for anyone on the team to grab, if they want to. 

Nick sorry for the delay running around like crazy try to make sure things are going smooth.

The problem with that is the pending task we put in queue normally go to a sprint.  We could put more in the queue for people to request but then the team is not at a ready when we are ready to kick off another objective as a unit.  Yes this slow some of us down but it also keeps all of us in sync and nobody is running around crazy like doing things that maybe outdated by the time we get to them because of the time we spend researching and moving forward.

Thanks,
James Fleming

The problem with that is the pending task we put in queue normally go to a sprint.  We could put more in the queue for people to request but then the team is not at a ready when we are ready to kick off another objective as a unit. 

I am essentially suggesting there be two tracks: a sprint track and then a wish task. The sprint track would have a deadline and the wish track would not. We would also wanted to make it clear that the thing from the sprint track are the priority. If they didn't get something from the wish track done by the end of the sprint or they dropped from the project before submitting the wish. It would have a low impact on the rest of the project, because things on the wish track should all ways be low priority. If something on the wish track becomes a priority it they should be move in to a sprint. 

As a general note, we don't seem to handle things that may span multiple sprints well, which may be a sign that long-term objects aren't well defined. 

Yes this slow some of us down but it also keeps all of us in sync and nobody is running around crazy like doing things that maybe outdated by the time we get to them because of the time we spend researching and moving forward.

I think assigning people any more then the 5 hours in a sprint (given our project structure), would be set people up to fail. I ran into a little bit myself with the last sprint. I completed completed two task then got stuck on third one, even though in no way was the third task system critical nor did it really need to be 100% done by then end of the last sprint. 

To be honest, I am also a little concerned about by the statement "things that maybe outdated by the time we get to them." Nothing we produce during this project or any project will be 100% by the time they are ready ship. There we be mistake made but can't be going back and constantly fixing them or will never get anywhere. That's not to say there can't be improvements, but improvements should be done with consideration for overall project impact. Overall the focus at this phrase of the project should be just to produce something. 

The ability to run an agenda not attached to a sprint has always been there so in sence this is already done. I think it comes down to more or less just chosing what agenda you want as low priority. A member would still have to request them from the lead or producer to assign them however.

-As a general note, we don't seem to handle things that may span multiple sprints well, which may be a sign that long-term objects aren't well defined.

I would agree long term agenda that go for more then one sprint are not handled well. This is why we try to break them down more and more in to 5 hours segments. But sometimes I or other leads are wrong in the amount of time it takes. When this happens we have been approving that agenda and then creating another one after that sprint whatever is left to do.

-Nothing we produce during this project or any project will be 100% by the time they are ready ship.

You are correct which is why the conversation with 2d and the gui switching to wireframe has taken place to speed up development it is taking way to long to produce the GUI at this point. So we have adjusted with this sprints agenda if you read them they should not taek that long.

Thanks,
James Fleming

Are main obejctive which is what we have been shooing for as an overal goal is to get a basic GUI up and a mech on the screen that can have some basic hit detection.  We are cutting out pretty much everything else until this goal is done.  Iam also trying to keep the "keep it simple stupid (KISS)" going as well.  But a lot of our members are talenant in their fields which is great i love the energy but as you can see we have been dumming it back slowly to get this produced.

I put you and i on the next sprint agenda together to work out the upgrade and moving the dll into the library folder then merging the progject in as we discussed in our meeting.

Thanks,
James Fleming

The ability to run sprint not attached to a sprint has always been there so in sence this is already done. I think it comes down to more or less just chosing what agenda you want as low prioty. A member would still have to request them from the lead or producer to assign them however.

Ok. Then may be the simple solution is add a priority field to sprint task. Then by default have low priority task in the pending queue viewable in the Volunteers Needed (which I think they already would). And may be add a Volunteer needed section to the console or scrum view. Where it is now is a little hard to find. We would then again re-enforce that task assigned at the beginning of a sprint are high priority, while allowing the low priority task to float. 

So we have adjusted with this sprints agenda if you read them they should not taek that long.

This actually bring up other concept I think we are missing, which are production notes. So in movie production when a scene is film affect project areas review the scene for potential issue. If there is an issue that affect there area they will create a production note. How we may implement this is have view that list assets by sprint for review. So when we do are weekly lead meeting, we could ask the leads to review the previous sprints assets for possible production notes. 

Cases where I would have had a production note from the programming area:

• The 2D background art of the login screen places the title of the game at the center of the screen. Login screen control a typically also placed at the center of the screen. The result is the title of the game will be cover up. As centering the login controls is the norm. I would suggest moving the title. 
• For the 2D background art on the console screen. Programming would actual need two assets to be create. One of the over all look and the a second one without the buttons. We would also want to know what font was used, so we can achieve the same look.

-Add simple priority field to sprint task

This is done but not with number as number symbolize priority which IMO did not work out when we had this method of doing thing before. Right now any agenda that is ready to be worked on can be placed in the pending status this shows up on all programmers screens in the top right under objective. When an agenda is assigned that is all that shows up their. However when the member does not have an agenda this area shows all pending agendas for that role. If no pending agenda exist then shows all pending agenda for all roles, and finaly if no pending exist it show a message about no task available. So a member does their sprint task if they want more they can look to this area for agenda if another agenda is mid tier needs done it should be placed on teh sprint as pending which then shows up on the kanban under pending but attached to the sprint, as well as the top right objective box.

-Production Notes

Melisa and I just had a meeting on this fact Saturday and a system change to the automation system was done to adjust for this.  The agenda below was a change to the automation system to produce a PM for the leads with a list of agenda from the current sprint to be reviewed so that the leads can help with the direction of the team.  This sprint at the end will be the start of the first PM lead reporting that goes out to each lead independly.  If their is not any bugs in the system this will be the first test so might not work 100% we will not know until the end of this sprint.

http://www.thoucurator.com/agenda/editagenda?agendaid=1018

Thanks,
James Fleming

This is done but not with number as number symbolize priority which IMO did not work out when we had this method of doing thing before.

I can’t speak to the system you had because I wasn’t around. I would need to know more about how you were using it. I would also point out that a priority system probably does not make sense for a major of the project areas, but I do think it make sense this case to note a floating task. Alternatively we could just add a flag that says this task is floating.

Right now any agenda that is ready to be worked on can be placed in the pending status this shows up on all programmers screens in the top right under objective. When an agenda is assigned that is all that shows up their. However when the member does not have an agenda this area shows all pending agendas for that role.

It would be hard for someone to ask me to assign them an additional task if they can’t see which tasks are available.

If no pending agenda exist then shows all pending agenda for all roles, and finaly if no pending exist it show a message about no task available. So a member does their sprint task if they want more they can look to this area for agenda if another agenda is mid tier needs done it should be placed on teh sprint as pending which then shows up on the kanban under pending but attached to the sprint, as well as the top right objective box.

This wouldn’t solve our issue. Part of reason people want additional tasks is so that if they get stuck on a task, they can work on something else for a while then come back to it. Some people find this to be a helpful method for problem solving.

• Floating Flag Task

I don't want our members doing more then one agenda at a time.  This drags them into different direction and can be confusing.  Remember this is not just for programmers this is for the whole team.  I would also take attention off the main task that needs to be done.

They can see all pending task at all times on the kanban if their are small things that need to be done.  We just need to set them on the sprint as pending, and when they are done with the sprint task at that point I would be ok for them to move onto one of the small ones that really easy to do.  I don't think we should just open it up, we need to give direction and be committed to the task at hand so it is completed if they have problem they need to put it in the kanban discussion so we can work it out as a team, or figure a better solution out for us.

As a side note they can see sprint pending task on the kanban, and on the report screen the top right objective box is for their current agenda.

When the sprint kicks off today i will set the IT test agenda to pending so you can see where it shows.

Thanks,
James Fleming

Ok now that the sprint is started I have the two agenda in pending now for the paradox and review for the designer.

The test information technology agenda is in a pending queue and not attached to the sprint.

Thanks,
James Fleming

Ok so now if we mark an agenda as a less important then it really in my opition does not do any extra stuff for the members of our team.  Because the agenda is in the pending queue this basiclly is a secondary task that needs done that is not as important as what was assign to start with.

Thanks,
James Fleming

If we are not going to allow people to work on more than one task at time and/or have away where they can just grab a extra task (that is designated as such.) The impact to the project would be so negative, that the ability to detach a task from a sprint would not be worthwhile. 

Oh OK so maybe just make it so that the pending items they can grab themselves and work on without permission once their main task is done would that solve this issue?

However as Anthony did on the Kanban discussion he finished his task rather fast which is due to him being really motivated which is awesome to see this energy.  Then he just requested another agenda from us, we could just start putting more of the current defining queue in the pending so they know a brief summary of whats next if they want to tackle that.  This in my option would solve the issue of each members time restrains and weather or not they have time this sprint or not.

Thanks,
James Fleming

The "requested another agenda from us" is a huge delay which taking time away from on-board a new member, coding, and thinking out new agenda items in line with the current project objective. All of which will multiply as the team grows. 

I still think there should be away to mark something as grabbable (pre-approved worked), because not all the task in the defining queuing are ready for people to work on or in line with the current project objective. There may also be things I'd want placed in the pending queuing that are depend on other task and we can't allow people to take out of order. 

I think I am going to chart out a process map. All this may be easier to talk about if there is a visual. I'll try to post that here later today.  

I would agree that is a bit of a lag to do that.  But if we allow them to free hand it how do we adjust for them overworking themselves or getting overwhelmed?  This is an issue we have seen many times.

Thanks,
James Fleming

I think we have are 3 controls for that:

1. We are not allowing a member to have more than one task at a time.
2. The member is choosing to take an addition task, if they feel up to it.
3. The addition tasks should always be low-impact, so if a member drops from the project or decides to sit out on a sprint; it should not affect the project as a whole. 

As for an addition task that run over, we either chosen to make that there next sprint task or we could have them submit the incomplete task so that it can be reassigned later. Again has long as the task is low-impact that should be fine. 

Ok so on number 2 "The member is choosing to take an addition task, if they fell up to it" does this mean you want them to be able to grab them without asking right?  Just click accept and go work on it?

Thanks,
James Fleming

Yes. By the time it gets there the task should have already been reviewed and approved both by a Game Producer and a Lead to be grabbed. 

The way I see this working is as followed.  Does it solve the issue in your opinion?

Problem: Motivated members being bored waiting so long between sprints to participate.

Solution: Quick grab items first come first server that don't need approval to assign to yourself.

Code:

• Add IsGrab to agenda model/object adjust Data & Business & Presentation Layer code
• Change kanban to show pending IsGrab object

Flow:

• Member is done with primary agenda
• Lead / Producer will have these items pre selected from defining queue
• Member select and accepts IsGrab Item

Restraints:

• Member may only have one agenda at a time
• At the end of the sprint all agenda are marked as requesting review for the ones that are still in assign status, after that the agenda will be marked as automation set it to "request review" so leads can inquire why it is not done and what is left to do so we can schedule it for the next sprint if need be.
• Member not on the current sprint may not grab one of this IsGrab Items and do it.

Thanks,
James Fleming

Yeah I think that would do it. This is the possible workflow I came up with. 

I do think is IsGrab is a better solution than a grabbable queue. That way when a task is submitted to defining the Game Producer knows the intent. 

after reviewing the flow chart I think we are on the same page now. I will set this as an agenda for IT when I get off work tonight.

Does anyone else have any question or comments about this system change?

Thanks,
James Fleming

Now the agenda have the IsGrabable to select so now for the kanban.

I was thinking i would make all pending agenda show up on the kanban and member of the sprint can accept them.  Once accepted they will become part of the sprint.

Thanks,
James Fleming

Nick please login to this url and look at the viewconsole screen under pending.

http://sandbox.thoucurator.com/report/viewconsole

Thanks,
James Fleming

Ok this has been rolled out to the main site.

if you review the viewconsole you will not see on the kanban pending area this change.

One agenda is on the sprint but is not IsGrabable is set to false.

Second agenda is not on the sprint but IsGrabable is set to true.

Case and point if its set to IsGrabable it will show up on all sprints in the pending queue no matter if it is or is not on the sprint.

Thanks,
James Fleming

I like how all that was implemented,  as well as the work flow.  I think it will allow for a little more productivity from people who can contribute more. Also,  I know it's a bit late but I have a comment for consideration still. I think another safety to ensure that nothing gets too out of hand,  would be to have the ability to disable an individual user from grabbing tasks. That way If someone is consistently making more work for the leads then you could stop them from taking extra tasks alone instead of disabling the feature from everyone

@Anthony As of right now the system figure out if you should or should not have another task by the following.

• You have another task still assigned too you
• You are not a member of the current sprint

Are you talking restricting it more then these to variables.

Thanks,
James Fleming

Yes. Like adding a variable to the user itself that say the lead or yourself can set for can this user accept additional tasks.

That way if you or a lead feels someone can't handle the extra tasks or they are creating extra work for someone else by taking them, then you can just restrict them from accepting extra tasks even if they meet all the other requirements

@Nick what are your thoughts on this?

Thanks,
James Fleming

If we went that way. I'd suggest an exclude approach rather then an include include approach. And I'd put it on the task itself, so it would function more like an access control. 

For now I think we should table this idea and run with what we have done this far.  We will monitor it and see what happens.  After a few sprint we can revisit this and see if any modification need to be made.

For now I will consider this discussion closed unless we have anything else to discuss other then the IsGrab item.

Thanks,
James Fleming