Search Unity

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

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

  1. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    There's truth to that. But you also need to keep in mind that in the tech industry buzzwords are so often deeply abused.

    A major problem is that often technical management is not actually deeply technical, and they latch onto things that sound technical. In tech, this is wildly common and often results in disaster.

    I tend to agree more with @TenKHoursDev - instead of looking at the buzzwords, try to understand the underlying process and the goals. Then evaluate what's valuable and what isn't.

    Keep in mind that you don't have a lot of experience in software development, so a lot of your assumptions about how it normally works may be off center.

    For example, most of the time developers rage against changing specification. Waterfall was a method wherein the work essentially followed the spec for months at a time without evaluation. Agile processes were embraced largely because they allowed for smaller re-evaluations (weekly, as opposed to monthly). By organizing it like this, developers are more willing to adjust to changes in the specification and feedback can be integrated during the development process.

    A lot of the agile process should be understood with that goal in mind.

    Chances are, you don't have much experience with these sorts of issues, so the gains you would see here may not be what you would expect.
     
    angrypenguin likes this.
  2. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    Sure, and it makes more sense when compared to it. Waterfall gets a spec and sign-off from the client, then designs the classes and system, then codes it. It solves the problem of clients wanting more features, or changes ... they signed off on version 1, and these are all good ideas for version 2. It solves the problem of hotshot coders being inspired to do a rewrite.

    I recently heard a talk from the people making a new PGA golf game (like Hot Shots Golf). An established studio, but they had multiple managers pulling the project different ways, and what the PGA people wanted just sort of dribbled out (the end result looked fine, it just took longer). That's what people in 1960 knew was a problem, and what waterfall was designed to avoid. In a sense, Agile is a snot-nosed kid who knows better than the adults.

    But freezing specs has an obvious problem -- some things really do need to change: an extra feature is absolutely needed, or the design really was bad. Agile and Waterfall are part of the problem of coding in an orderly process, with some flexibility, without thrashing and blowing up the scope.

    Games like using Agile since there often isn't a design spec. The contract is "game for this movie, show these characters, PG-rated, must be fun". There are plenty of stories where the game was about shooting with a little brawling, but the brawling was really fun, so it changes mid-design into a brawler. But even then, if Alice and Pete are working for free, but only on a shooter, you've got the same problem.
     
  3. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    Also one thing to keep in mind is that in game development we often genuinely don't know what the best solution is at the start of the project. Agile methods have the advantage of allowing explorative development. Get something functioning in a sprint, then test it with users and use that to inform changes and/or future parts of the design.

    Strictly speaking, in a "true" waterfall project the design is all locked down before people start writing code. That's useful from a management perspective (the client has agreed to exactly what we'll do and now we just knuckle down and do it...) but is often quite poor from a user experience perspective (because the developers will learn stuff as the project goes on, but is not allowed to update the spec to take advantage of that).
     
    Voronoi, Kiwasi and BIGTIMEMASTER like this.
  4. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    There's an old article about the phone game All-Star Troopers describing radical changes due to testing: https://gamasutra.com/blogs/KellyHo..._Ragna_Cycle_Turned_Into_AllStar_Troopers.php

    Cool story, but the thing is, I've played it and it's a very simplified Royal Revolt (a clash-like where you control the hero, fighting along a path of their defenses with lesser troops constantly running in for and against you). Plus the AST concept is nuts: your heroes are humans with animal heads, attacking from a spaceship, but your base is on a planet and keeps moving around. I assume this is left-over stuff from all the iteration they did.

    I kind of feel like "easier version of an existing game" is something they could have come up with using less Agile and more normal design process.
     
  5. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    From the knowledge they had at the start of the project, could we reasonably expect them to have jumped to the conclusion of "a very simplified Royal Revolt"? I have no idea, but I wouldn't just assume the answer is "yes".

    It's really easy to look at the end result and see easier ways you could have reached it, but that is almost always coloured by hindsight. I've thrown away more of my current game than I've kept. Probably when its done people will say "dude, you could have done that in half the time!" And they're right... I could have... if I knew what that design was from the start, and didn't explore and research and test and throw away a whole bunch of stuff that influenced the final design but didn't make it in there directly.
     
    BIGTIMEMASTER likes this.
  6. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    You're describing a problem in the way people throw around Agile. It can easily turn into doing whatever you want, not planning very well, and no matter how much time was wasted, say "oh, it's part of the process".
     
  7. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    Why are you assuming that it's wasted time? If all knowledge about a domain could be known up front then we'd all just use waterfall and software wouldn't be difficult.
     
  8. Voronoi

    Voronoi

    Joined:
    Jul 2, 2012
    Posts:
    263
    This is really well put! The advantage of agile applies particularly well to games or any other software that has to compete for an audience. Nobody is 'required' to use or buy a game, they have to want to buy it. So much enterprise software uses the waterfall process because managers really like it conceptually. Managers could pretty much care less about the user's experience because the users are employees. Their version of UX is 'use and experience our software or get a new job'.
     
    Kiwasi, aer0ace and angrypenguin like this.
  9. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    Why are you assuming it's not?

    Suppose Gus designs, codes and playtests a system for using bonus dice. Then someone takes an hour to run the math and sees it doesn't work. Suppose Gus implements a feature over a few days. Then someone mocks it out with paper over an hour and sees it should be cut. Those were both wastes of time.

    Now suppose you know that making a game is a chaotic process, and you know that only 20% of the work makes it into the final game, and also some random idiot thinks you could focus on only that 20%. The stuff Gus did is still a waste of time. All of the normal ways you can stupidly waste time are still there.

    Suppose Gus skipped meetings, plus that other stuff. Would you accept Gus's excuse: "you never know what will be useful. There's no such thing as wasted time in Agile"?
     
  10. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    This is useless hypothetical and missing the point of a production methodology entirely.

    I'm pretty sure I read nowhere that you should design, build, and playtest every thought you have before performing basic pen + paper planning. Or getting any basic feedback at all. Part of being smart means knowing the limits of your intelligence, so obviously you must make an intelligent judgement where to draw the line between jumping into every "what if" you can come up with and properly planning out your ideas to get to something good before you start work.

    The point of agile, it seems to me, is that it's designed to factor in human ignorance and allow for maximum adaptability to change. If you take this to mean, "I do whatever the hell I want!" then of course you are going to fail. Because that's just stupid.

    No matter what your methodology, stupid is stupid.

    Please stick to posting relevant information so the thread doesn't devolve and then disappear. Anybody who can't critically think enough to avoid getting themselves themselves into a pickle because they blindly followed some dogma is beyond help anyway.
     
    Last edited: Sep 4, 2019
    angrypenguin, iamthwee and Ryiah like this.
  11. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    Exactly. That's what I'm saying. Go back and read Penguin's last 2 posts. They're strongly implying the opposite through hyperbole -- no one could have possibly looked at similar games like Royal Revolt first, and projects using Agile automatically have 0 wasted time. That may not have been the intent, but that's what they communicate.

    Post-mortems have been popular for a while. You see over and over again how a more flexible approach spreads out the planning and makes it easier to do something bone-headed. After a few weeks they always describe some snap decision they made, which somehow seemed too obvious to check out, that wastes a ton of time. It's something you could see yourself doing -- multiple things are happening and it's difficult to switch "hats" and the scrum is only an hour and sprint goals are due. Agile naturally tends to have more opportunity for bad planning-type decisions due to confusion.

    The lesson is that with agile-type approaches, you need to be extra careful to force yourself into planning mode. The worst projects I've seen are when the lead is also deeply involved in one aspect -- switching from that to manager-thinking is somehow extra difficult.
     
  12. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    So you are saying that, on a small team, because the lead had their nose to the grindstone in technical stuff they missed their turn when it was time for important leader decision or something?

    But what's that got to do with following agile or whatever else? That's just a normal human mistake that could happen anytime?
     
    angrypenguin likes this.
  13. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    I'm not assuming. I was talking about my own project, for which I was present. With the talk of that other project maybe that wasn't clear, though.

    Even in that case I wouldn't assume it was wasted time. It might be, but I wasn't there to know.

    Here's a concrete example from my own project. Early on we implemented a navigation GUI - a compass like you'd see in Skyrim or Fallout. We used this for many demos and playtest sessions, and it never got comment, and people found their way around so we considered it was "good enough". About 18 months after it was put in place we suddenly started getting data that players were confused about where to go. Investigating a bit we found that new players were being confused by what the compass was showing, even though it hadn't changed. Lots of other stuff had been implemented or changed around it, so it was a context thing. We then implemented three different versions of the navigation GUI, got playtesting data from those, and used the results to implement a new version which didn't confuse people. This was done over multiple sprints, with player feedback deliberately built into the process.

    That's not at all what I was saying or implying. The point was that they may not have known up front that a Royal Revolt clone was the best solution to their problem. Time spent discovering that is not necessarily "wasted".

    Referring to my example above, it's easy in hindsight to pick a game with navigation most similar to what we now have and say "you could have just built that at the start!" The problem with that statement is that it overlooks the fact that our ultimate design is based on player feedback that we didn't have 18 months earlier. We did look at navigation interfaces in other games at the start, but we didn't have data on how players would respond to the different things we looked at in the specific context of our own game.

    Similarly, you're assuming that the developers of All Star Troopers had all of the information at the start to know exactly which game to clone. Maybe they did, but also maybe they didn't. I haven't got a clue.

    There are more options than just "Waterfall" and "Agile", by the way. Any iterative model would have facilitated this kind of development to some degree.

    As for your hypothetical, I'm not convinced that Gus's waste of time had anything to do with the model in use. The problem was that Gus jumped the gun and built something before he knew what to build, without even doing cursory checks in advance. That could have happened regardless of the model in use, particularly when you throw in that Gus also skips meetings.

    Exactly. I've never done a project where I knew everything about the domain at the start. I've rarely had a contract where a client didn't see a build and then say "Oh, it'd be great if..!" I've never had a non-trivial project where my team's and knowledge didn't improve along the way.

    Haha, you've no place accusing others of hyperbole in a sentence that ends like that. :D

    You have a valid and very good point that the term "Agile" is often used to gloss over a lack of planning and management. No argument there, and it's not the only weakness of Agile.
     
    iamthwee and bobisgod234 like this.
  14. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    4,830
    Agile is the opposite of bad planning and management. If you reach to level 100 of agile that means continues delivery and it takes alot of planning and good methodologies to reach, including a good continues integration etc
     
    iamthwee likes this.
  15. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,465
    As opposed to waterfall? Where the bonus dice system gets written into the design document. And then the whole damn game gets built before someone stops and thinks I wonder how this works when actually playing?

    One can straw man both models, with similar ridiculous results.

    Focusing only on the stuff that makes you money is a good idea. Its the very foundation of LEAN.

    However for most games, knowing which of the stuff you are working on is the profitable 20% that's going to make it into the game is difficult to impossible.
     
    GameDevCouple_I and Ryiah like this.
  16. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    Is there though?

    Seems to me that essentially every non waterfall model, and every established iterative model falls under the agile umbrella these days.

    Like, you are either agile, waterfall, or none.
     
  17. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    I don't care about what words people are using, I care about ideas that can benefit my development right now. Otherwise the thread becomes like almost every other. An argument about words, not sharing of useful ideas.
     
    angrypenguin likes this.
  18. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    4,830
    It's not black or white, you can be waterfallish in some areas while agile in others
     
    angrypenguin likes this.
  19. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    The question is - is there any consensus on what agile is - beyond morning meetings, iterative development and two week deliverable? Agile names each of these things very specifically, "scrum" "sprint" etc.

    Does everyone use the word 'agile' to describe a custom flavor of iterative development or is there some actual consensus on methodology?
     
  20. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    Is there consensus on anything? Who cares? That's not the point. I'm only looking for ideas that benefit my own development. I don't care if what Jon calls Agile is different from what Bill calls Agile. That means nothing, because I am not looking to be convinced on some dogma. Just ideas I can extract the good from and use. Jeet Kune Do style.
     
    angrypenguin likes this.
  21. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    I think we're both doing the same from different directions dude. I'm asking more pointed questions to see what falls out, what's actually important and what people really do in practice. Maybe it leads somewhere, maybe it doesn't, but who cares, it's a forum post.

    Also, in general, threads meander. It happens. Most of the time that's good for collecting more info because it keeps bumping a thread up and more random people respond to the op/title.
     
  22. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    Threads do meander, which is why I try to police my own so that people who drop useful info don't get turned off by pages of useless arguing over nothing.

    You are asking people about what peoples idea about what a word means. I see that as entirely beyond the point of the thread and an essentially useless question (unless I was beginning a project with these specific people). What I want here is people who have experience with implementation of the process to share what they know, have learned, etc.

    For instance, somebody above mentioned common pitfalls of agile in that, if everybody on board does not understand and agree to adhering to the discipline necessary to implement it, morning meetings do become a useless drag and confusion does happen. Real world example. Something I can plan for.

    The question is most certainly not "is there any consensus on what agile is". I am not looking for a definition of agile here. I am looking for practical implementation of principles that I can use. Way deeper.
     
    angrypenguin likes this.
  23. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    In Agile the lead and team leads are more likely to have their noses to the grindstone. Stuff you would have thought about early on, with everyone following up on and hashing out, now you're putting off to week 4. That's good in a way, since you know more and can make a better decision. But it's hard to go from "head down" mode, cranking out assets, up to manager mode, re-evaluating every little decision, possibly cutting stuff they worked so hard on just an hour ago. In so many of those gamasutra post-mortems (or ones I've heard live) I can see this. They wrote this, tested this, revamped that, and then made a complete head-slapper of a decision since they were in the thick of things.
     
    Kiwasi and angrypenguin like this.
  24. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    But why does doing agile versus something else mean leader is more involved in technical matters? That's what I'm not understanding.

    It seems like you are suggesting that some people who adopted agile practices took it to mean they don't bother thinking things through up front? More or less, they misunderstood the principles and used it as an excuse to just be lazy?
     
  25. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    4,830
    It's simple, humans can't think of every little possible detail upfront, no matter how experienced they are. Agile aims to break this up in milestones or sprints.

    This is one of the reasons why maintainability is so important, because it's agile to change in requirement
     
  26. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    To follow up my reply to BigTime, lack-of-planning mistakes are easier to make in Agile. In a traditional process you explicitly have all of the planning up front. This is the one time you're going to look at dice odds, figure out every bonus dice and option (roll 2 take the highest? -- that gets worked out now). This is when you obviously do the internet search for other dice games and reviews. You're very aware that in Phase II everyone is head-down, building it, and every decision needs to be made now.

    In Agile you're delaying the decisions until you know more. That can be great. You may have wanted to limit the number of dice, but realize that handfuls are more fun after the first few weeks. "Take the highest" might feel wrong after getting so many pair of 6's which are only worth 6. But since there's no specific time for big picture stuff, it's easier to forget it or kick it to the next week. It's easier to add "doubles add and reroll" without thinking how that could break a challenge mode. But Gus is still a terrible employee, either way.
     
    Kiwasi likes this.
  27. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    I wasn't under the impression you should be delaying decisions, rather trying to figure out what you don't know by designing specifically for iterative experimentation.
     
  28. jamespaterson

    jamespaterson

    Joined:
    Jun 19, 2018
    Posts:
    31
    Here is the original agile manifesto, for reference: https://agilemanifesto.org/

    The underlying principles are useful, however in practise imho it can turn into a bit of a cult and be an excuse for short-termism and lack of meaningful planning. There is no substitute for technical excellence in leadership.

    If you get the grant, hire an experienced technical manager.
     
    BIGTIMEMASTER likes this.
  29. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    It might be the same thing?

    What I've seen: say you're making a platformer with a twist. You work out the sequence of new mechanics to unlock, levels, ideas for extra characters, types of monsters to add... . Regular planning stuff. But since this is all new, none of those should be decided or fleshed out. You get enough so you think you have a game. It's no different than not planning exactly where to eat on day 2 of a car trip. You somewhat arrange it as a tree -- which items depend on previous ones testing out -- and delay finalizing them until the stuff before it proves out. Your sprints work up the tree, favoring things that seem fragile. Ideally, it all works and you make that game.

    But since it's all new, some ideas will suck and force rewrites of future plans. Some steps will give ideas no one would have thought of at first. That can happen in any environment. In Waterfall you write them down for next time. In Agile you do it now. You could call that experimentation and emphasize it. But the process is aimed at making a game. By week 5 you've got 5 weeks of game made and your goal is to finish it. It seems funny to say that your main accomplishment was figuring out what you didn't know.
     
  30. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    Sorry, I meant shouldn't* be delaying decisions
     
  31. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,465
    Agile definitely has an aspect of delaying decisions to it. It’s similar to the concept of delayed differentiation from LEAN.

    One of the professed benefits of agile is you are waiting until you have the maximum amount of information before making a decision.

    This is probably the biggest weakness I’ve seen in self directed teams. It’s really hard for a lot of ripple to switch between short term production thinking and long term strategy thinking. Which is why the old school hierarchical workplace exists in the first place.

    There is a lot to be said for using skilled technical experts for their expertise, and skilled managers for their expertise, and not trying to push tasks one way or another.

    Every minute your artist or programmer spends working on timelines or budget or business cases is a minute they aren’t working on art/programming.
     
    BIGTIMEMASTER likes this.
  32. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    This is what I've seen (and heard). Of course each studio is different:

    o It's also about the rest of the team. During a real planning phase (which even Agile will have, but shorter) _everyone_ is only planning. Much more chance someone will know similar games, check around, download and play something. In general follow up on things. The coder's only technical job is to make quick mock-ups of dice stats, and such. The artists only art is sketching mock-ups of the UI, making storyboards.

    o The various team leads are definitely involved in technical stuff. This is where you may have a modelling lead, the one other main modeler, and an artist/modeller on loan for the week, doing unwraps and running Excel. In theory the team lead gets general goals during the scrum.

    o The active lead (scrum master) is probably a technical person and 1/2-time doing technical tasks. You can't afford to waste a person. If there's a big boss, they're probably not that involved -- they're off doing client work and running the business.
     
    BIGTIMEMASTER likes this.
  33. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    This sounds like a standard process. Navigation GUI implemented based on original design and used successfully for over a year. Then one planning session, and standard user testing to find a winner. Nothing wrong with that. But an Agile success story goes more like "wanted an MMO where navigation was more active. First GUI was awkward and hard to read. Over next 2 weeks team-members trying to use it were inspired and turned it into the fun navigation mini-game in our final version." It's about the team's internal testing quickly seeing problems and adapting.

    The non-Agile version would be brainstorming, designing, mocking .. the same navigation mini-game, and having the implementation be exactly as fun as you thought. Then one could claim that would never happen -- the Agile version is much more likely.
     
  34. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    Of course it's "a standard process". It's all done following a standard process.

    If that's what you want to call "agile", go for it. I see little value in debating what that label should(n't) be applied to.

    One thing I would note, however, is that you won't necessarily see issues straight away. You especially won't always see them from internal testing alone, or from testing things in isolation. Our original nav stuff still works perfectly for the team working on the game, and we in fact prefer it over the new one. But that's turned out not to be the case for players as more of the game got built and tested around it, and that's ok.

    Regardless of what methodology you use or what you decide to call it, the important thing in this context being willing to actively solicit feedback, review your design based on that, and decide if and where things should be changed accordingly.

    The "if" bit is really important, and there are a whole bunch of good reasons to choose not to change things. One of them is simply that if you keep iterating in search of perfection you'll probably never finish your project.
     
  35. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    At risk of offending OP. I would like to discuss that point.

    Although some would consider this a pure argument of semantics, the real underlying question is: if you already use non-waterfall methodology, does Agile offer real additional value, or is the core value really just the advocacy of an iterative process being compared to waterfall?

    What are the actual processes in Agile itself - outside of scrum/sprint?

    I've started to use the word Agile more in some business discussions, and it's actually produced positive results. But am I lying when I say that I use a highly Agile methodology? Am I abusing the concept or is there not really much to the concept to start with (outside of a rejection of waterfall)?

    Is agile a buzzword, or is there actual meat on the bone (assuming you left waterfall behind in the 90s)?
     
  36. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    So before I posted this thread, I spent several hours reading everything I could find about agile. I considered that due diligence before asking others for their time.

    Maybe you are being a bit intentionally dense, but the buzzword "agile" is obviously going to be about as useful as you make it. In other words, take time to do the research about it, extract the useful bits of information and discard the rest.

    You think everybody is a bunch of sheep throwing around buzzwords they don't understand, who cares? Does answering that help anything? Do you think I'm not smart enough to filter the chaff? You can see already plenty of intelligent and accomplished people here had plenty to say about this, so do you suggest they are all just full of it and don't understand what they are talking about? Rhetorical question. Please don't drag the conversation sideways again -- apply persistence to something more productive.
     
    Last edited: Sep 8, 2019
    angrypenguin likes this.
  37. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    3,580
    Sorry, I wasn't posting to make a point about you. And I wasn't trying to make a point about other people.

    I'm trying to find out what people actually mean when they say the word so I can tell if I am using it right or not:

    - "What are the actual processes in Agile itself - outside of scrum/sprint?"

    - "But am I lying when I say that I use a highly Agile methodology? Am I abusing the concept or is there not really much to the concept to start with (outside of a rejection of waterfall)?"

    Is it really so outlandish to ask what specific processes Agile is composed of?
     
  38. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    You do realise that iterative processes had been in use in high profile projects, such as at NASA, for over two decades before "Agile" became a thing, right?

    Yes, formal agile methods have a few things that define them within other iterative methodologies. Moreso when taken together than individually. A few off the top of my head:
    • The software should always be in a working state. This gives us handy stuff like continuous integration and delivery, but really the important part is the ability to have recent updates in users' hands getting real-world feedback, rather than arbitrarily waiting on a milestone.
    • User-focused design. Software is defined as a set of "User Stories" rather than as a functional specification. The intent here is to invest time only where it solves real world problems, rather than just ticking boxes or making partial solutions. Arising from this, something isn't "done" until it is in a build which a user can try.
    • Self-direction within teams. Team members evaluate and select their own tasks within sprints, rather than being told what to do by managers. Team members are also generally free to propose their own solutions within their tasks, though this will often happen collaboratively. In other words, decision making is often spread throughout the team rather than constantly being pushed up to managers or leads.
    • Self-correction mechanisms. The Agile methods I've looked at in a formal sense have had something like Planning Poker. The attention grabbing bit is that people use cards while planning, but the important bit is that this is a simple way to identify lack of clarity in short term goals. If people with relevant skills and experience each rate a story very differently then either at least one of them doesn't understand it, or one of them has thought of issues or solutions the other(s) haven't. Either way, now it's out in the open.
    • Open communications. This is the Scrum / Kanban board or whatever. Everyone can see what everyone else is doing, and/or when other people have run into issues.
    Hopefully it's clear to anyone who's either made software and/or worked in a team before that those things could all be good or bad in different scenarios. For instance, refactoring code that already works does not complete a User Story because it won't change anything for users, but it could still be an important thing to do from time to time.
    Well... the first stated value in the "Agile Manifesto" eschews processes in favor of people, so asking that question of "agile" in general is doomed. You need to pick a specific flavor before that question has an answer. I'd suggest Agile Scrum as a starting point, as it is formally documented quite well.

    Half of me wants to say "yes" because of your apparent lack of knowledge of the specifics. The other half of me glances at the Agile Manifesto, shrugs, and goes back to writing software. ;)
     
    Last edited: Sep 8, 2019
    Kiwasi and frosted like this.
  39. BIGTIMEMASTER

    BIGTIMEMASTER

    Joined:
    Jun 1, 2017
    Posts:
    2,422
    https://www.agilealliance.org/agile101/

    I found this to be pretty lucid ^ and to the point. But still, not having worked in an actual office with ordinary geeks, I wanted to get some further plain-english experience from people here.


    p.s. @frosted , if you throw some word around and it makes people trust you more, keep doing it. Fake it till you make it, ya know. Can't tell you how many times I said I knew something in the army and then literally learned it for the first time while demonstrating that I "knew" it. Nobody ever knew!
     
  40. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    My game dev team operates remotely and online. So an immediate thing for us is that daily "Stand Ups" don't work. We are not in the same place, and are rarely all working at the same time. Instead, we use an online chat tool and everyone gives status updates as they're working. Only team members are allowed in the chat, and all project related chat must happen in there or in another "official" project venue (meetings, talk boards, etc.).

    The purpose of your Scrum / Kanban board is to clearly communicate what people are doing, and also to clearly show people what they need to do next. If it gets too cluttered then clear it out. Have a lead look over any task that hasn't advanced lately and decide whether or not to kick it to the backlog until circumstances have changed. Otherwise it's just a distraction or, at worst, hurting morale.

    On the note of morale... I once came onto a team where the managers had wall-mounted screens with burn down charts in the office. For one particular project the charts were just constantly showing us how behind the project was. It sucked. When you arrived in the morning, when you were leaving after doing some overtime, when you took a break for coffee... a constant giant reminder "yep, we're still behind!" Don't do that.

    In my experience there's often talk of "it's not done if it's not in a build", but that ignores that there's a whole lot of valuable stuff you can do that doesn't go in a build, or deliberately doesn't change a user's experience. Planning, design work, refactoring, documentation, developer-facing tools, workflow optimisation... loads of stuff. So, remember that "users" aren't just end users, and not everything has to go in a build.
     
    Kiwasi, Metron and BIGTIMEMASTER like this.
  41. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    731
    I'm looking at that site and seeing what Penguin describes and ... that's nothing like what I've seen.

    The Scrum/Sprint I've seen is about "let's see how that looks before we decide". Each sprint is stuff you feel like you need to see in order to know what to do next. You have an idea of the next sprint, but you don't know until you see the results of the last one. You do various other stuff, but only to support that plan. For example you tend to get most of it working early, but only the parts you needed to see in action.

    It's a great system -- I've seen it work well. I don't think they called it Agile -- they had scrums, sprints, milestones, tasks on notecards. This was a guy who ran a game studio and also taught. I saw dozens of teams of juniors and seniors (college) using it.

    I suppose I'm happy as Agile being one term, which means something I've never seen in use. While Scrum/Sprint is something completely different, which I have. And Sprint means anything, depending on the context (because the definitions of one online do not look familiar, except for the week-long part).