Search Unity

Agile development -- can some professionals gimme a rundown in plain english?

Discussion in 'General Discussion' started by BIGTIMEMASTER, Aug 29, 2019.

  1. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    Hey guys, I'm asking for a lot here.

    You people who have worked in game or software dev professionally, can you give a rundown of Agile development (or whatever your methodology is) in absolute moron plain english? Just the big principles -- no details -- and how it applies to game development in general?

    Anybody using trello to take care of this? What's your boards look like? What's your standing orders for different departments?

    I really appreciate any help at all. I ask that if you guys have disagreements about how to do this or that, solve it in another thread. I just want the raw info in this one. Viewers can decide what is best advice on their own.

    Also, any links and resource is much appreciated.

    Thanks thanks thanks!
     
    BrandyStarbrite likes this.
  2. newjerseyrunner

    newjerseyrunner

    Joined:
    Jul 20, 2017
    Posts:
    648
    I liken Agile to evolution. The first pass is extremely minimal and gets done only what you need it to in order to move on to the next thing. This is important in a team environment because you often have team members waiting on each other, often in loops: Dev A is waiting on Dev B, who's waiting on Dev C, who's waiting on Dev A. This is why you do the minimum and commit it so that everyone else can start their work. From there, then you generalize and error-check your code and possibly rewrite it in a more robust way.

    A good example that I did recently was to determine viewing angle of a rotating object that's on another rotating object which is on another rotating object. I originally just took a transform and followed the chain up using RotateAround and things like that, just so that the next person had something functioning. This took me only an hour or so, but then I spent a few hours working out the exact trig so that I didn't have to rely on injecting transforms and things like that.

    No component is ever finished, but they all have to maintain their current functionality while being expanded. This is why Agile and Test Driven Development often go together.

    Our Jira boards are usually week-long tickets with a specific goal on it, which each dev then breaks down into smaller tasks which are blockers to the main one.
     
    BIGTIMEMASTER likes this.
  3. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    So it's kind of like, what is the minimum thing Joe needs to accomplish so Sarah can keep moving forward, and you prioritize that? Major focus being on efficiency (all pieces are always moving)
     
  4. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    1,906
    In short:
    1. Keep your sprints short and manageable (1-2 weeks)
    2. Make your tasks doable in that time period.
    3. Use something like https://hacknplan.com/

    Jira sucks *****
     
    RavenOfCode, Rond, Ony and 1 other person like this.
  5. newjerseyrunner

    newjerseyrunner

    Joined:
    Jul 20, 2017
    Posts:
    648
    Yes. This actually affects how you tend to do code design because you want your code to be expandable because you're not always sure in what way it's going to be used a month from now.
     
    BIGTIMEMASTER likes this.
  6. Ony

    Ony

    Joined:
    Apr 26, 2009
    Posts:
    1,836
    Spiral-bound notebooks. Spiral-bound notebooks as far as the eye can see. Also legal pads. Not so much legal pads anymore, actually. Those were more in the early aughts. Pens. Lots of pens to write things down and cross them out. Who took my damned pen? Oh, it rolled under that notebook.

    Also sometimes Hack-n-Plan, but only for the tiny things I'm likely to forget or that will get lost in pages of notes. I hit Hack-n-Plan and go through the list as things are finishing up.

    My wife and I have daily morning meetings over breakfast to see what needs to be done for the day, and we work in bursts of an hour-and-a-half or so, separated by twenty minute (or lunch) breaks where we either talk about work or talk about all the cool things we're going to do once we finish whatever new game we're working on at the time.

    This is not, of course, AGILE development, as the actual concept is known. It is, however, agile enough for us, and we get by. :)

    Anyway, its worked so far, but we're not out yet.
     
    Martin_H, BIGTIMEMASTER and Tzan like this.
  7. Tzan

    Tzan

    Joined:
    Apr 5, 2009
    Posts:
    707
    First it was programming notes in sketch books with Razor Point felt pens.
    Then notebooks, but I realized I didnt like the lines telling me what to do, I draw along with my notes.
    Then Hammermill copier paper in a clipboard and labeled folders, with Uniball micro .5 mm black pens in boxes of 12.

    I have almost been tempted to try Hack, but I dont need much help coordinating with myself.
    Just a ToDo list that gets items crossed out with a red pen.
     
    Ony likes this.
  8. Ony

    Ony

    Joined:
    Apr 26, 2009
    Posts:
    1,836
    Crossing things out is the most amazing feeling. Sometimes I do something in the game and realize I hadn't written it down so there's nothing to cross out, so I write it down in my notes and cross it out immediately. There's something supremely satisfying about crossing things out, and I won't be denied, damnit!!
     
    chingwa, Kiwasi, Deckard_89 and 3 others like this.
  9. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    I find myself unable to keep organized with pen+paper. My notes always become a hot mess. And my handwriting? Forget it.

    I am getting familiar with hacknplan atm. Seems pretty smart.
     
    Ony likes this.
  10. Not_Sure

    Not_Sure

    Joined:
    Dec 13, 2011
    Posts:
    2,610
    I’m no pro, but I’m a big fan of color coded sticky notes. I like to write out a massive check list, then organize them into stickies, then figuring out how to best lump them together and do them one stack at a time.

    I am solely solo though.
     
    Ony likes this.
  11. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    6,340
    There's lots of different flavors of Agile. Scrum for example. They all have their own little tweaks on the rules, the meetings, etc. They pretty much though all come down to having semi-autonomous self contained teams which do work on a relatively fast and fixed iteration cycle measured generally between 2 to 4 weeks each, called a "sprint".

    Depending on what version of Agile you're using the details will be different, but generally at the start of the sprint the team gets together and commits to a certain number of tasks from the backlog (list of planned future work). They make this commitment based on the estimated amount of work for each task, priority of the work, and what they think they can fit into the sprint. Typically the tasks are self contained and can be tested within the sprint, without testing dependency on work coming in later sprints (that's ideal, but not everything works that way in reality, but you do your best).

    On a daily basis you have short "stand ups" which are a quick meeting to discuss progress and any roadblocks to finishing the sprint. By the end of the sprint all new development has been finished, tested, caught bugs fixed, etc. Then you have some form of review meeting, or several, and possibly a meeting with outside stakeholders to demo the new functionality. After that, it is rinse/repeat from the start of the next sprint.

    This differs from traditional "waterfall" development, where you often have months of development happening before much of anything is delivered to QA. QA then slams through large monolithic test plans. Process often repeats with every build, in addition to test plans targeting whatever new functionality is going in.

    The biggest advantages to agile are that once each team gets into their groove, it becomes fairly easy to give forecasts on expected delivery dates. Future work becomes predictable, outside of higher ups throwing a wrench in the plans. Teams are rather small, focusing on their own area, and start generally working well with their other team members. They end up delivering higher quality work on shorter timelines because they end up working not harder but more efficiently as a group.

    The negatives though come from a variety of places.

    The worst I like to call "Agile in name only" or "Waterfall with extra meetings", where higher ups want Agile because they hear it is the latest cool kid in town, but they don't want to do the hard work to truly implement it. For example, work isn't broken up into sprint sized chunks with the proper planning before the actual development is started. Or wanting QA to still provide large monolithic test plan execution reports because a single large report is easier for them to deliver to their stakeholders who don't understand or care about Agile. You then end up using a classic workflow, but now have to stop every day for the stand up meeting, take a few days off for the sprint planning and retrospective meetings. You end up just slowing development down.

    Now I'm not an Agile is the only way to go type of guy. Waterfall can certainly work, and be made to work well. But if you're going to do Agile you have to go all in, not take the approach of picking a few things from Agile and stapling it to Waterfall, because you only get the benefits of Agile because every little part of it works together. You leave one part of it out, because it is too hard to get your organization on board, and it starts to fall apart.

    Another negative is the tendency for talkative people to take over the stand up meetings, turning what should be a 10 minute meeting into a daily 1 hour meeting going over every detail of what they did before. This comes down more to weakness in the person running the meeting not willing to shut it down. A stand up is for hitting the highlights of where you're at, and quickly discussing any blockers, find out who can help with that blocker, and then the meeting ends and you and the guy/gal who can help then address your blocker. It should not be so you can hold the rest of your team hostage while you try to address every detail of your blocker in the meeting. But this seems to happen all the time and it is a real productivity killer.

    Yet another issue is a lack of discipline to put outside requests into the backlog. An outside request comes in, it is higher priority than the work being done now, so stop what you're doing and work on this issue. Basically blowing up the whole sprint. Well that is not how this should be done. It doesn't matter what priority the work being done right now is compared to this emergency. The work being down now was committed to, it should be completed within the sprint. This emergency work should be scheduled for the next sprint. If someone really needs to work on it immediately, and of course this happens, you should have a separate team which is there for addressing emergencies.

    Now when sprints get blown up every once in a while, sure things can be unpredictable and it is not a huge deal. But I see sometimes every other sprint having to hit the brakes and deal with emergencies. Umm, what's the point then? Maybe you should just have half of your sprint dedicated to dealing with emergencies, but this is often pushed back against by people who don't really understand the problem with throwing out sprint commitments and how that impacts what we've said what we will deliver and when.

    So Agile works really well when it is allowed to work well. It is really easy to allow outside forces to disrupt it though, and you need strong people willing to tell people "no" in order to not sacrifice long term commitments and goals for short term ones.
     
    Last edited: Aug 29, 2019
  12. RecursiveFrog

    RecursiveFrog

    Joined:
    Mar 7, 2011
    Posts:
    170
    OP, what is the size of your dev team? What are you trying to deliver? For whom? On what timeframe and budget?

    Who are the stakeholders? Are they internal to your company/team or external?
     
  13. Tzan

    Tzan

    Joined:
    Apr 5, 2009
    Posts:
    707
    Haha! I've done the exact same thing!
    Write it down, cross it out. :)
    Feels good.

    On my pages that have everything crossed out in red, or just note pages I dont need, I do a whole page red diagonal slash.
    I keep these pages forever in folder.
    I also have a good habit of putting the days date in the upper right hand corner of every page when I start it.
    My pages are all loose so it helps to keep an idea of chronological order after the pages get mixed.
     
    Ony and BIGTIMEMASTER like this.
  14. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    7,825
    Playing cards. The Fibonacci sequence. T-shirt sizes. Meettings.
     
  15. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    It's all tentative right now.

    Dev team will be ten or less people, most likely. Title will be multi-platform adventure game. For kids and young adults. Timeframe is unknown, right now. Budget could be up to $1.5 million, but that's tentative.

    My main interest in this is because, if funding goes through, I'll have to manage a few people, which I've not done with software development before. So I'm taking time now to get familiar with how things are typically done in professional setting.

    Stakeholders would be external, but majority of funding comes from government grant, with recoupment being the only stipulation.


    @Joe-Censored , thanks for big response. I been reading about 101 stuff so now its good to hear about some pitfalls in the actual practice.
     
    Last edited: Aug 29, 2019
    Joe-Censored likes this.
  16. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,155
    Oh man, us engineers would always throw up 5s and 8s during estimation, because the more tangible tasks were about a day, or just over, long. Once it got into 13+, our scrum master would be all, woah, woah woah, can we break that down? So generally, any estimates over 8, are way too optimistic
     
  17. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    4,830
    I can not recommend azure dev ops enough. It has a very nice issue tracking system

    upload_2019-8-30_9-16-54.png

    Also its easy to link commits to tasks either through the dev ops UI, or like I do it, prefix the commit message with the task #

    upload_2019-8-30_9-20-17.png
     
    BIGTIMEMASTER likes this.
  18. andyz

    andyz

    Joined:
    Jan 5, 2010
    Posts:
    1,128
    I used to work waterfall (traditional time based tasks) - 'you will get this massive task done by such-a-date'! It was bad because there is a lack of communication and everyone stresses and works overtime to try and hit the boss' deadline.

    Agile (Scrum is very common) means to me breaking down everything into smaller tasks (sticky notes on a board or digital version-of) and prioritising them (often by MVP - minimum viable product) then working through them in short 'sprints' and analyzing what is holding things back.

    So yes agile is the future and to learn Scrum just read Jeff Sutherland's book!
     
    BIGTIMEMASTER likes this.
  19. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    1,889
    There are all sorts of agile, but they all boil down to the basic principles:

    1. Divide up work into units of work. Could be hours, days, bannanas whatever you want. As long as one unit is measureable against another.

    2. Plan out work in sets, often called sprints. Once commited to a sprint, dont change it until you get to the end.

    3. Measure and document everything, how long you thought a unit would cost vs how much it did cost in time, etc etc. Any problems you get , things that went well.

    4. Analyse what happened against what you thought would happen, and use the findings to plan the next set of work adjusted against reality of what happened. Thought that bit would take you 5 hours but it took 7? This time plan a similar task as 7 hours instead of 5. As time goes on you will get very good at estimating the cost of things and be able to look at a giant piece of complex features and whittle it down to the exact days or hours it will take.

    5. At end of project , analyse the whole thing and then decide what worked what didnt and adjust way you work on next project based on that. Anything that doesnt work for YOU should go. If every other team uses sprints but sprints dont work for you, then dont do sprints. Etc.

    Agile comes down to looking at what you did to improve what you will do next. Anything that doesnt work is shaved off. Anything you cant see the point of, gets shaved off.
     
  20. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    I'm working on filling out a hacknplan board with this in mind now. I try to apply the scrum methodology to my concept work over the next couple of weeks and see how it works for me. Much of what I've read and been told is stuff I was already doing to some degree, but having a defined method I think will be essential to getting a team on target.

    I feel this will be best implemented during actual production though. There is no hard deadline right now and I basically want as much time as I need to figure out the art. But, anyway, I think there is still plenty that can be practiced even without hard deadlines.
     
    Ony likes this.
  21. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    1,889
    Even without deadlines itll help you get bettter at estimating times around stuff and knitting together all the smaller details in project management. I still do agile even with little mess-about prototypes I make so that if it turns into something bigger I can quickly scale up and understand how much time down to the hour is left.

    When I started doing agile my estimates for times were so very far off from what they are now. Now I can with a lot of certainty break any feature design or asset design into a number of hours and at most itll be off by 1-2 hours which is amazing considering at the beginning things were off by literally weeks (we talking about 7 years ago though XD )

    Edit: Also @BIGTIMEMASTER agile doesnt have to be digital, for first few years I just had post it notes on my wall and that worked really nice :) but hacknplan is great and the devs are nice so thats good too!
     
    Ryiah, Ony and BIGTIMEMASTER like this.
  22. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    yeah i think that is really important. I hardly pay attention to time -- it's a bad habit I gotta break, so this may be the smart way to do it.
     
    Ryiah and GameDevCouple_I like this.
  23. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    4,597
    I thought agile development was about being ready to bail when things started to go wrong ...

    Sounds like more of a wish than a plan.

    In any case, the way I see it, the main thing is to plan, and to always measure how far off of it you are, without delusions - only reliable way to converge on an optimum trajectory.
     
    Ony likes this.
  24. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    self-organizing, cross functional teams sounds like something that is entirely contingent on a good hiring plan, and then a very well thought out discipline to keep people focused.
     
  25. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    4,273
    That's why you're holding daily stand-ups (short, fast-paced meetings, about what everyone has done yesterday, what are they planning for today and what kind of problems they're facing at the moment and what help they need to solve it if any). It keeps people at bay and focused. They won't diverge much from the point because in a workday they will be "forced" to steer back.

    BTW, if you're working with a team in person, then having color-coded sticky notes on a table is more beneficial, because it comes with surprising pride and good feeling when you walk up to the board and move your sticky note with a hard problem from the "in progress" column to the "done during this sprint" column. In the front of everyone else. Small stuff, but good for morale.

    ps: I used the "what was done yesterday" and "what will be worked on today" because we usually used morning stand-ups (it's slightly better), but some teams use end-of-the-day stand-ups (what was done today, what do you plan for tomorrow), it has some disadvantages (less focus, since a lot of things will be going on in the evening, people are resting, things will be emptied out of their brain, naturally).
     
    BIGTIMEMASTER likes this.
  26. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,155
    I was at a AAA studio, and on a project that served as the guinea pig for introducing the Agile process into the studio. I'm just going to add some of the "soft" aspects of agile that were sort of instilled in our minds when we were transitioning, that may not have already been mentioned.

    One of the first ideas was that at any stage of the development process, you shouldn't be afraid to completely tear it down and start back up and/or fix it. It sounds crazy, but if something isn't working to requirements, there shouldn't be a need to keep it. Change the software, and make it work for you instead of working against it.

    From an engineer perspective, it can seem that Agile is very much against your happy, comfort zone mentality. The planning sessions can be lengthy, and the customers will ask details that they expect you to technically know about. If you don't, throw up tasks for researching things, because that's actually doing work towards more tangible goals. And the customer expects you to know, when all the engineers provide their estimates as to how a certain thing will take. I liked this phase, because whether you are a senior or junior engineer, you can weed out complexities to finishing the tasks just by talking it over. It acts as a transference of domain knowledge. That's another aspect of Agile that I learned about. That, the engineers shouldn't be absolutely "silo'd" into specific systems. Rather, the knowledge sharing should help all engineers, in the case that they will be the ones to pick up the task.

    And about tasks, they are usually re-worded to the point that ALL stakeholders in the room understand what the task is for. This can be infuriating to the engineer, because it may downplay the amount of work described, and that's why you use the estimation phase to tell them how it really is.

    Tasks and user stories are also more skewed to the owners rather than the artists/engineers. It's for their understanding, and engineers have to do the extra mental work to manage technical work towards a task. I remember that being such a huge topic to adjust to, because usually the technical director would be okay with more engineering-related tasks, but nobody else would understand them.

    As far as daily standup meetings go, I actually liked the idea, because sometimes engineers can be heads down all day. We had our standups first thing in the day, and it was essentially each engineer getting a chance to say what he/she did yesterday, and goals for the day. The point here is, that what he/she did yesterday could have even been "I was running into problems all day, I had to reboot my machine several times, and I was having network connection issues, so I didn't get a chance to work on what I needed to". The team would appreciate that candor, but you have to say how you're going to make that up. The thing is, the Product Owner and the Scrum Master were NOT allowed to talk, only attend. This was a developer-centric meeting, and each engineer "had the floor", meaning nobody would interrupt that person.

    Ugh, I can keep going, and I don't even know if this helps. The agile process has been such a big part of my professional gamedev life in the last decade, I'm sorry if I am just rambling.

    EDIT:
    Another important thing I forgot to mention was developer "Velocity". This was an interesting statistic, because Velocity is determined by estimates vs actual work done. It's not hard to believe that most of the time, the team had a low velocity, because developers tend to underestimate the time tasks take. A good Scrum Master would adjust this expected velocity, by using a multiplier for "background" tasks like meetings, integration, testing, etc. usually like 50%-70%, to account for lost time. What this does is it allows the Scrum Master to finally get an idea of the actual velocity that the team is capable of accomplishing, making deliverable times a lot more predictable.
     
    Last edited: Aug 30, 2019
    BIGTIMEMASTER and Ony like this.
  27. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    Good luck on your grant man. Hope that all goes well for you.
     
    BIGTIMEMASTER and iamthwee like this.
  28. RecursiveFrog

    RecursiveFrog

    Joined:
    Mar 7, 2011
    Posts:
    170
    Every time I hear this line of reasoning it reminds me of the time I read “Agile is a methodology best suited to a project where time and resources are infinite and quality isn’t a consideration.”

    But that aside, there’s a a very valuable result from engaging in the methodology if done as intended: transparency of progress and an accurate measure of project health, gathered regularly. It’s really worthwhile to have.
     
    BIGTIMEMASTER and aer0ace like this.
  29. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    975
    Agile does not exist. It's an approach, not a methodology.

    For more read this.
     
  30. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    2,372
    Agile is something every decent developer knows in theory. But it sounds like your main challenge is no technical co founder.

    I would focus more on what do successful early stage startups look like. It's a very specific context with it's own set of rules and dynamics.

    Like it's not uncommon for early stage teams of 2-3 developers tend to outperform larger teams of 5-10. That's why smart startups focus so much on the initial core team. It's the most productive time you will ever see, and it's good to stay there for a while and then grow out gradually.

    Both of the successful ventures I was in (2 out of 8, which is fairly lucky), we made our first million before we had our first scrum. Effective startup teams need very little process and structure, especially early on.

    Agile isn't a concern at your stage per say. Or rather it's solved for correctly by simply getting the right people who will already know what they should know in that area. That is their job. Yours is to figure out how to be an effective leader, which has little to nothing to do with assigning tasks.
     
    frosted, BIGTIMEMASTER and aer0ace like this.
  31. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,155
    I would have to agree with @snacktime. I found the book The Lean Startup very inspirational. It's all about the MVP and what that actually means. Translating the products in that book weren't exactly 1 to 1 though, since game development is a lot more art than other startup ideas.
     
    BIGTIMEMASTER likes this.
  32. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,155
    I admit that when I heard it, the back of my mind was calling bullshit so hard. However, it really is meant for metrics. It gives the managers in your group an idea of how many resources something takes, so that they can play "Tetris" with their human resources, and feel creative by swapping things here and there, prioritizing things, to hit a hard deadline.
     
  33. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    1,648
    Last edited: Aug 30, 2019
  34. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    Any resource about successful early stage startups? Especially in this field?

    No process and structure? Can you elaborate a bit on that? I find it hard on an individual level to really output quality without process and structure. Do you mean to say simply that if you find the right professionals and leave them alone, that will be more effective than trying to shoehorn them into some structure? I can see that.... but I mean, how likely is it to find people like that? And the right mix of people to form the perfect team?

    Any elaboration or resource on what effective leadership in software/game development looks like?
     
  35. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,465
    Another aspect of Agile that hasn't been mentioned yet is the idea of always being production ready. Every sprint should be self contained. Which means that at the end of every sprint, you should have a build that theoretically could be deployed.

    In traditional software development, this build gets looked over by your clients and stakeholders. And that means that if there is a problem you can change direction quickly. The general idea is that you don't actually know what your final software will look like when you start building. Its only through users interacting with the software that you can figure out all the requirements. (Contrast this to waterfall where the software requirements have to be determined up front before the project is started. And late changes to the requirements become very expensive to implement.)

    It also means that if your team gets cut, whatever you have built can be deployed. Because your product is always functional, very little work is wasted if the project ends early. (Again contrast this to waterfall, where stopping a two year project after one year leaves you with exactly nothing.)

    These advantages apply to games too. You can be frequently testing and tweaking your design through early builds. If you run out of funding, you can always launch what you have on early access or kick starter to try and extend funding.
     
  36. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,465
    This is a red flag. A 1.5 million budget is a lot to manage on your first time through. And its easy to go dramatically wrong. Strongly suggest getting someone on with experience managing this type of project if you do get the funding. Its very easy to burn through hundreds of thousands of dollars with nothing to show for it (speaking from experience as a project manager).

    The hiring plan isn't as critical as you would expect. Most teams can be pounded into a self managing group with sufficient effort.

    The thing to remember though is self management isn't always the best option for a team. It means that you are taking some time for each person away from the technical aspects of their job, which they are typically very good at, and asking them to work on management, which is a different skill set. This can detract from time actually doing the job. I've had several self managing teams that have elected to go back to having a manager, so someone else can be an expert on the management side of things.
     
  37. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    4,830
    We were so agile that by mistake the dev branch was merged into a feature branch, that then was merged into a hotfix release branch (personally I never merge into hotfix branches but cherry pick instead) and then released into production without proper acceptance or regression testing. A very serious incident offcourse. And we have taking measures to prevent it again (basicly adopt how I work :p) but there were no major problems because thanks to proper agile methods dev was more or lesa ready for release.

    The first small steps towards continues delivery, something I have been wanting since I started working for this company :)
     
  38. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    Thanks @Kiwasi .

    Yeah my inexperience here is why I want to stay as small as possible. $1.5 million is the maximum amount one of the grants would... grant. But I don't intend to require nearly that much. I want to still plan the game like a hobbyest project. As in, how can I build this with zero money? And only apply funding in those area's that I cannot achieve professional quality myself, or within a reasonable timeframe.

    But definitely if I have to manage more than like, three fulltime people, I'm going to have to hire somebody for help with management. I'll probably need to hire a consultant anyway, at some point if there is basically any money on the line.

    The main benefit I have is time. Essentially, I have infinite time for myself to work. So as long as I can keep tough deadlines out of the project, that should help to eliminate any thoughtless burning of money. I know that kind of sounds backwards, but what I mean is, I can just take the time to learn to do things myself before throwing money at any problems.

    And one other safety net is that the grant is not paid out in lump sum, but in installments.
     
    Last edited: Aug 31, 2019
  39. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,476
    I dunno if all this agile lark is even relevant for Unity land if one is going with either DOTS or even the component model because Unity by default is generally compartmentalised and thus what AGILE solves in C++ land and what it solves for Unity staff isn't really on the same page as the developers actually using Unity.

    Let's consider the case of monobehaviour land? You'll have different people typically working on different components. That's already insulated against crossed wiring.

    Let's consider DOTS? The code is AGILE by default basically, up to a point. You're doing all these systems and they're all functioning extremely independently.

    Is AGILE required for Unity game development at the user level? I'm going to say, strictly, no. But some of the practises are worth keeping such as blocking out the entire codebase with the minimum viable you need to get up and running.

    The meetings over and over? utterly pointless with the structures unity provides. A quick daily meeting (which any studio using any practise) will suffice.

    So my take on it is that AGILE is a nice concept but in it's entirety, is not necessary for Unity game developers / end users since the useful parts are kind of there by default.
     
    Ony, Ryiah and BIGTIMEMASTER like this.
  40. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,060
    @BIGTIMEMASTER what is this project you're starting? I'm pseudo jelly :p but more than curious. :D If you're permitted to share any details...
     
  41. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    No reason for any jelly. Unless i get any funding it's just hobby project. But even if that's all it ever is, I still like to learn more about this stuff. Very useful to understand all the differnet ways people approach projects and business.

    I won't say too much right now because I will make a progress thread once I get concepting done. Basically its gonna be a casual doggy adventure/survival game with light educational elements, for consoles. Think Wolf Quest but with more traditional video game gameplay and a cutesy theme. First thing I'm working on is figuring an art style and getting enough basic art done to make a little kickstarter page with, then I'll get more serious into the different funding avenues I've identified so far.

    Many questions to be answered first before any begging for money :)
     
    Last edited: Aug 31, 2019
    Ony and TenKHoursDev like this.
  42. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,060
    I'm not jelly of the $$ I'm jelly of the chance to work on something of magnitude... :)

    Its not that I don't care about dollars, its that I care more about doing something I love. Money is just a means to an end. Even if I do have some debt.
     
  43. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    well, just do it. lol.

    I got turned onto these grants just by talking with a friend. That's usually how you discover opportunities. Just meet new people, make friends. Everybody knows a little something. Doesn't mean this will work out how I hope but at least I know it's a thing I can pursue.

    Like before I got to talking with this guy, I always just assumed I'd do everything totally on my own with my own money. That's just how I always done everything. I didn't know there's this whole world out there and all these programs to help people starting businesses/careers.

    The main thing is to just take the time to prepare yourself for success. Gotta have time to learn and figure out what you don't know. Fill in the gaps and whatnot. Like I got a lot of work to do before applying to any grants, otherwise it will just a waste of time. Nobody gonna give you money if you don't make it seem like it's impossible that you won't be worth it.
     
    Last edited: Aug 31, 2019
  44. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    Does agile have an actual agreed upon definition, outside of "have a running system asap", "daily meetings" and "iterate"? Always seemed to me that the main point of Agile was really reducing schedule deadlines from multiple months to multiple weeks. "Sprint" instead of waiting months to have the final product running.

    Mostly it seems like a response to waterfall, but waterfall fell out of favor by the late 90s.
     
  45. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
  46. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    To me, that description comes down to a bunch of buzzwords and makes me think there is no actual "agile" process.

    Before agile got popular, eXtreme programming was the more popular version of this. A lot of "XP" practices were rolled into agile. https://en.wikipedia.org/wiki/Extreme_programming. XP was at least really clearly defined in the original book.

    I think people call having a morning meeting, and making sure the software runs before you spend multiple months on a spec "agile" because waterfall was so bad.

    Key points:
    • Schedule stuff in weeks not months.
    • Have runnable software asap.
    • Have morning meetings.
    • Break up a single giant specification document into tasks.
    Am I missing anything? Was the problem that "eXtreme programming" sounded lame and they changed it to Agile?
     
    Ony likes this.
  47. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,060
    @BIGTIMEMASTER I feel the same. The thing about luck is that it is composed of two components: preparation, and opportunity which then coincide. Its something I've found myself working very hard at lately, the preparation part. I'm taking 15 credits of classes, not including the lab section that I am assisting a grad student with for credit toward graduation, and my year long capstone course. There's a lot of work to be done this fall, and more so this spring (16 credits!). I've never successfully taken on this level of credits, but proved myself on achieving good grades last spring. I've got my health in order too and that is a big factor. I've essentially quit gaming for the past three weeks, between the cheaters and toxic social environment -- I've given it up. Also need to start finding a job for after I graduate. Never thought I'd get this far... or finally have this materialize. Been in school since 2012 save for an 8 mo. break when I transferred schools. I love my major and minor, find them both fascinating and these days I'd rather apply myself to those than waste my time gaming when it seems I've nothing else to do.

    Decided to apply my 1337 math skills to a new problem. Its been done a few times by others and learning from them I am. Found a new-ish solution... going to start implementing once the problem is fully solved and the plans are laid out, something I rarely did years ago.

    Edit: just rambling.
     
  48. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    yeah i hardly touched games since i started making them. once you sitting in front of the screen all day last thing i wanna do is sit in front of it some more. But making games is more fun than playing them anyway, at least IMO.

    Most important thing is just make a habit of continually challenging yourself. Whereever you find resistance to something new, dive in head first. Most people dont do this. They get settled into routine, get comfy, and then get lazy. If you do the opposite, you move ahead right past them. And all just from a simple habit.
     
    TenKHoursDev and aer0ace like this.
  49. TenKHoursDev

    TenKHoursDev

    Joined:
    Nov 9, 2014
    Posts:
    1,060
    I agree @BIGTIMEMASTER though I think finding out WHY you have certain habits is important before going on to go a step beyond and above, as its recently become clear to me. For years I had aversions to certain activities and a multitude of anxieties... it isn't clear why but I've gotten to the bottom of these things recently and the answers were very simple. Reason I mention this is otherwise you're just fighting yourself the whole way.

    Realizing the "why" for certain things has not only given me the ability to address and alter them, its also made me a calmer and happier person.

    Also in my class for interdisciplinary engineering we've already begun learning about project management. For one Gantt charts and project management software are crucial to keep track of things. Scrum is definitely a good strategy as Agile is a lot like Binary Trees in CS. Hardly anyone uses them for anything practical because they are a teaching tool, because more advanced methods exist.
     
    frosted likes this.
  50. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    Yeah, understanding why can help, for sure. But sometimes you just identify a thing that is a problem and you find a way to solve it, and you never even know where it came from in the first place. Doesn't really matter as long as you are moving towards your goals. Sometimes understanding why comes much later.



    Most of these things (agile, scrum, or whatever acronym) exist for good reason. Even if they become mere buzzwords, they got to that point because they mean something.

    Here's an army story: When I first arrived at my unit after job training, we went on this big training excursion. The final big test was a live fire exercise. A bunch of metal targets pop up in a field at the end and you shoot them all after maneuvering into position.
    Just by chance, the battallion commander (big boss) was with my platoon because some news team was following us around too. When it was time to start shooting, the guy next to me with a grenade launcher was missing all his targets. Somebody said something, then the grenade launcher was in my hands. I'd never even fired it before. So I flipped up the sights, estimated the range, and fired. Nailed the target. Again and again. Some of the targets I couldn't see. I just asked others what the range was and something it aligned with. And that's all you need to know. The sights got ticks with numbers that show you how to tilt the thing to hit a target at that range.

    I got an award for grenade shooting after that.

    Why was I so much better than the other guy (who'd been to war once already)? Because somebody had told him that you don't need to use the sights, you just use "kentucky windage" (i.e., guess). And so that's what he did, as little beliefs like that And most everybody did that, and just assumed actually hitting S*** was some mystery like how Michael Jordan jumps so high.

    But I just used the effin' sights. They're there for a reason. They work so well somebody with literally no experience can destroy a target 300meters away....as I proved.

    Anyway, point is, investigate things for yourself. People are generally fools.
     
    angrypenguin and Ony like this.