"Agile" is a thing, right?



  • I'm currently sitting in a 4 hour meeting for "Agile Training", with a consultant that used to work for Red Hat on their Java stuff, including JBoss, because big enterprise-y projects like that are what you think of when you think of Agile. He seems to be discussing some form of Scrum (or SRUM, according to his introductory document). This document also mentions Pair Programming, which I didn't really think was a thing anymore. Some bullet points from this document:

    • Gain efficiencies – do more with less time while maintaining quality
    • Bring a little freshness to our skills and processes (and also employee retention) – Agile is a trend in the industry and we haven’t had change in methodology in a long time – Agile will improve us and keep our skills fresh as key resources for our flagship product
    • Improve our ability to attract good talent (we will continue to grow and Agile is becoming a bigger and bigger requirement for people searching for jobs)

    Someone really needs to tell them Agile pretty much means "Not Waterfall"

    For an added bonus, the guy giving this presentation is a few states away at corporate headquarters, and we're watching this meeting over Google+. With a webcam. With a horrible directional mic. I can barely understand what he's saying. A picture of this setup:

    It doesn't look any better in real life than it does in that picture. This is going to be a long 4 hours. I think he's talking about user stories now. Maybe I should play Eve Online and be more productive...



  • UDP flood the machine hooked to the projector, then complain about the poor connection and postpone the training. Odds are that the next session won't happen anyways and you'll have the opportunity to bitch about not getting a complete SRUM training.


  • Trolleybus Mechanic

    @bardofspoons42 said:

    He seems to be discussing some form of Scrum (or SRUM, according to his introductory document)
     

    Agile: SRUM form of development!

     



  •  @Lorne Kates said:

    SRUM

    This reminds me of chicken nugger and sweer potato.

     

    curious?
    googe it



  • @bardofspoons42 said:

    Scrum
     

    SCRUM does not appear to be a bad way of rolling through your project, from what I'm seeing across the room here.



  • @dhromed said:

     @Lorne Kates said:

    SRUM

    This reminds me of chicken nugger and sweer potato.

    That's what you get when you go out for fine dining on MLK boulevard in any major American city.



  • I will say that when dealing with clients, an agile process has worked best. It's like WeightWatchers for development. Create very granular user stories that that even the client can understand, assign points based on effort (not time) to those stories, and then let the client choose which stories they want done each iteration as long as their combined points don't exceed the velocity of the iteration. You can't over-promise, and they can't over demand. Not to mention the client feels like they're in control of their own project and they're the ones responsible if things go pear shaped.

    Also, pair programming isn't a bad thing. Sure, it doesn't make much sense for code monkeys doing menial tasks, but for anyone having to architect something, it helps when you have someone to bounce off of. Architects and design firms rarely have anyone working solo, so why not developers? Having a second set of eyes often gets you past snags and roadblocks faster because the other person often sees something you didn't. Similarly, they can drive for a while if you're feeling burned out, and vice versa.

    Though, I'm not sure why this guy didn't just do a shared desktop in the Google Hangout you're already in.



  • @dhromed said:

    @bardofspoons42 said:

    Scrum
     

    SCRUM does not appear to be a bad way of rolling through your project, from what I'm seeing across the room here.

    Don't get me wrong, I've been advocating Scrum, but I don't think they know what it really means. And judging by some of the questions asked during this meeting, I don't think our associates at the head office get it either. Really, if we just started with user stories, get basic tasks broken out onto notecards, and get a cork board in our area, we would be better off. I just think that however much they're paying this guy isn't going to really be a good return on investment.



  • @bardofspoons42 said:

    Really, if we just started with user stories, get basic tasks broken out onto notecards, and get a cork board in our area, we would be better off.

    Please don't use a physical board! Use Trello or Pivotal. Both do the same thing but digitally, so nobody gets the bright idea to copy down all the cards into an Excel sheet so they can check stories outside the office.



  • @Soviut said:

    Similarly, they can drive for a while if you're feeling burned out, and vice versa.
     

    Their constant presence would make me burn out.



  • @Soviut said:

    I will say that when dealing with clients, an agile process has worked best.

    Don't get me wrong, I like Scrum, a lot of the points make sense, more than XP or some of the others. However, I see lots of indicators that it's going to be "We're doing Agile!", and then pay lip service to a few of these things, without actually making changes to how we do development.

    @Soviut said:
    Also, pair programming isn't a bad thing

    The main problem is, we have wildly varying skill levels here, and a few people have declared their unwillingness to learn new techniques. However, I would like to push for something like weekly code reviews, which when we adopt a sane issue tracker and SCM will be easy. That way we can catch mistakes the others are doing, and also suggest other ways of doing things.

    So, while I like these ideas, I just have every indicator that we're doing it wrong. And we're just starting. We can't even get accounting to spring for Visual Studio 2012.



  • @Soviut said:

    Please don't use a physical board!

    I'd love for us to start using Atlassian's full stack, including Jira with Greenhopper. I used it in the past and it was awesome, and with our team size, we could get their full stack for $70. But considering we're having a hard time convincing people outside of this department that we need to invest time in something other than using SourceSafe...



  • @bardofspoons42 said:

    @Soviut said:
    Please don't use a physical board!

    I'd love for us to start using Atlassian's full stack, including Jira with Greenhopper. I used it in the past and it was awesome, and with our team size, we could get their full stack for $70. But considering we're having a hard time convincing people outside of this department that we need to invest time in something other than using SourceSafe...

    Check out tfs.visualstudio.com. The board is pretty neat and is linked with everything else in TFS (bug/tasks/work items/source code). It's free and cloud-hosted. Plus the build and test platform is still in preview so that's free too. And if you really hate people in your team you can opt for Git instead of TFS, it's available. If you don't use Visual Studio for development you can get Team Explorer (also free), which is the Visual Studio IDE with only the source control plugins, or you can use an inferior client like Eclipse.



  • @Soviut said:

    stories
     

    Ok what the fuck is a story? I'm half-sure it's not this:

     

    It was a dark and stormy night. Each flash of lightning and every thunder broke Leta's concentration. She squinted. Her sprint was on schedule, but this particular bug just wouldn't go away. She had tried everything... rebooted her computer and recycled the application pool three times each. There was a chance that this was not the code she was looking for. That she was in the wrong file, on the wrong server, rewriting the wrong method. It was certainly the wrong hour to be debugging this sort of thing.
    An IM popped up from merzepern, her regular game buddy.
    21:58 merzepern: what the hell
    21:58 merzepern: why are you still online
    21:58 Letabug3000: I know I know. I just want to make this work, you know?
    21:59 merzepern: fuck thta shit. go home.
    21:59 Letabug3000: Client update tomorrow. but it keeps crashing.
    21:59 Letabug3000: so I can't show this, can I.
    21:59 merzepern: it's fucking late. you're probably missing a hundred clues.
    22:00 merzepern: I just know that when I hit asnag like that, it' best to let it sit util I'm clear-headed again.

    Leta pondered her friend's words. The room was dark. She had been sitting still for a long time and the automatic lights had gone out. The monitor's light reflected in her glasses.
    'Fuck it,' she said.

    22:03 Letabug3000: I'm quitting for the day. We can do a Nef Anyo run in a bit?
    22:03 merzepern: sure. fuck his shit up. I need s new helmet.

     

    any resemblance to existing nicknames is entirely coincidental
    not all of merzepern's tpyos are put in manually



  • @Ronald said:

    Check out tfs.visualstudio.com.

    My big problem with TFS is I've never been able to get builds working correctly, when I have a build file that works. Plus it still seems to have the awful checkin/checkout method of source control, along with using the read-only flag on files for state, at least as far as my research shows. If I'm wrong, I'd be glad to hear that. We've been trying to get VS2012 with an MSDN subscription for us devs, but so far, no luck. Granted, by the time anything happens, VS2013 will be out, but that's what MSDN is for.



  • @dhromed said:

    Ok what the fuck is a story?

    Basically instead of a 100 page dry, technical, verbose requirements document specifying everything, you start with items like: "An administrator should be able to add new users". "As a user, I should be able to search customers". Then you build up tasks from those.

    Quite a nice idea, and even most non-technical people can wrap their head around user stories when you run it past them to say "Is this what you want?"


  • ♿ (Parody)

    @dhromed said:

    Ok what the fuck is a story?

    The new hipster term for a use case, but without the old hipster use case diagrams. Usually something like a requirement but with less formal prose.



  • @bardofspoons42 said:

    @Ronald said:
    Check out tfs.visualstudio.com.

    My big problem with TFS is I've never been able to get builds working correctly, when I have a build file that works. Plus it still seems to have the awful checkin/checkout method of source control, along with using the read-only flag on files for state, at least as far as my research shows. If I'm wrong, I'd be glad to hear that. We've been trying to get VS2012 with an MSDN subscription for us devs, but so far, no luck. Granted, by the time anything happens, VS2013 will be out, but that's what MSDN is for.

    I'm not sure why you would get a MSDN subscription. Unless you do very fancy stuff in your tests, Visual Studio Express works fine. Throw in SSDT and a free TFS cloud account, you have the entire setup for free. I never had a problem with builds in TFS but if you prefer you can use third-party CI tools like CruiseControl and still flag the work items in TFS. Disclaimer: I don't know about VC++ projects, I don't write device drivers for a living.



    As for the checkin/checkout thing, maybe what you mean is that by default TFS prevents multiple checkouts. That's just a setting but unless you have a very big, distributed team in my experience having multiple checkouts is just not worth it because of the time wasted in resolving conflicts.



    Also in my experience people who complain a lot about multiple checkouts usually have a lousy or non-existent branching strategy (like having everyone woking on the trunk).



  • @bardofspoons42 said:

    Plus it still seems to have the awful checkin/checkout method of source control,

    Why is this awful? Visual Studio can be set up to automatically check out a file and mark it as modified as soon as you start editing it. Any other IDE could be set up to do the same, provided its developers took the time to provide proper integration for TFS. Tracking the file's state makes it a lot easier and a lot, lot more cheap to track which files have open modifications that require the developer to commit them back to the repository. Try using Git to track the modified state of files in real-time in even moderately sized C# projects and you'll quickly find out that features like live discovery of changes and matching based on content rather than strong rename operations is a huge resource hog.



  • @bardofspoons42 said:

    along with using the read-only flag on files for state,
    I'm not sure what you mean by this.  I can change files being read-only on my file system without them automatically becoming checked out in TFS.

    @Ronald said:

    maybe what you mean is that by default TFS prevents multiple checkouts.
    It does? I've not seen that be the default.  And googling seems to imply that it's the opposite.


  • Discourse touched me in a no-no place

    @Ragnax said:

    Try using Git to track the modified state of files in real-time
    You're doing it wrong.

    The whole concept of a DVCS is that you should not care about who else might have modified something. Instead, branch and merge. And don't try to change everything all at once; that's always disruptive.

    (I remember working with RCS on NFS with colleagues who liked to lock everything — dunno why; just because, for all I know — and then go off on vacation for several weeks. CVS was such a big step forward over that particular variation on development hell.)



  • @bardofspoons42 said:

    I would like to push for something like weekly code reviews, which when we adopt a sane issue tracker and SCM will be easy. That way we can catch mistakes the others are doing, and also suggest other ways of doing things.

    Uh, yeah. If you don't source control or a bug tracker, you've got more fundamental issues.



  • @dhromed said:

    Their constant presence would make me burn out.

    I could see how someone who's really guarded about their work might feel that way, but I've generally found it productive to hand off the keyboard to someone else so that I can think while they type. It lets you direct traffic for a while instead of having to focus on driving, to give an impromptu metaphor. That, or they have a better idea for a solution and can type it out more quickly than they can explain it. Even though you're using up two brains, there's less downtime and more focus.



  • @bardofspoons42 said:

    We can't even get accounting to spring for Visual Studio 2012.

    Is that company a big Microsoft account? How many seats? If it's a decent-sized client and you have a good TAM, you can probably get him to throw in VS licenses under a competitive advantage initiative, especially if you tell him you're thinking about moving stuff to Azure or online TFS. Can't be done every year but it could be a nice boost. However I still don't get why you need the full VS edition, there is not a lot that can't be done in VS Express.



  • @bardofspoons42 said:

    I'd love for us to start using Atlassian's full stack, including Jira with Greenhopper.

    I'm using it at the current agency I'm working at and, while it isn't slowing me down, it certainly isn't doing me any favours. Trello is great if you need a digital board to move cards along. Pivotal Tracker is great if you need stricter agile workflow, velocity calculation, automatic iteration building, etc. Both have really nice intuitive UIs and APIs to hook into and both can be used in real time across multiple screens.

    The issues I've had with Greenhopper is the UI, while better than it was, is still really clunky. Lots of unnecessary fields. A convoluted "workflow" scheme that needs to be configured otherwise you'll accidentally resolve issues when you just meant to update them. No drag and drop for files. Ticket history is hard to find. It still thinks we should be specifying time spent, etc. etc. etc.



  • @dhromed said:

    Ok what the fuck is a story?

    Generally it's a simple phrase that explains a feature in an "ACTOR should be able to ACTION" format. "User should be able to log in", "User should not have to log in when returning", etc. The idea is they stories are supposed to be understood by a client with no technical experience so they're not supposed to mention implementation. That's up to the developers to figure out. Stories are supposed to be very granular too, no "Auth system" or "Admin panel" monster tasks. If you want to group a lot of stories under a heading like that, they're usually called "epics". But epics are usually just something you use when a particularly large set of features is going to take multiple iterations to implement.

    In a few cases, some places will consider stories as behaviours. "user signs in, leaves, returns, is still logged in". These are usually used in places that do a lot of behaviour driven development with their integration testing.

    Either way, I like when a client sees a separate story for, say, each CRUD operation as well as one for confirming deletes, they realize just how much work is actually involved in each of their requests. It demystifies the whole process and they stop saying "this should be simple" and instead say "this should require these stories".



  • @Soviut said:

    I could see how someone who's really guarded about their work might feel that way, but I've generally found it productive to hand off the keyboard to someone else so that I can think while they type. It lets you direct traffic for a while instead of having to focus on driving, to give an impromptu metaphor. That, or they have a better idea for a solution and can type it out more quickly than they can explain it. Even though you're using up two brains, there's less downtime and more focus.

    Makes it hard to keep up your IM conversations with your buddies.



  • @blakeyrat said:

    Makes it hard to keep up your IM conversations with your buddies.

    Yeah, and porn surfing can be quite awkward...unless you're both into the same thing.



  • @Soviut said:

    @blakeyrat said:
    Makes it hard to keep up your IM conversations with your buddies.

    Yeah, and porn surfing can be quite awkward...unless you're both into the same thing.

    I do the OfficeSpace thing, "during a given day of work, I do maybe 15 minutes of actual work", but instead of just staring at the wall I spend my time IMing friends and working on hobby projects and sometimes Netflix.

    ... and yet I'm still productive enough to somehow stay employed.



  • @Soviut said:

    Either way, I like when a client sees a separate story for, say, each CRUD operation as well as one for confirming deletes, they realize just how much work is actually involved in each of their requests. It demystifies the whole process and they stop saying "this should be simple" and instead say "this should require these stories".

    If you map your user stories to manual activities done by the users instead of the broader underlying business process, your backlog must be hugely fragmented to the point of being useless from a reporting point of view. What is your ratio of tasks per story, 1:1? It's like saying: I prefer to have only one file per folder so the users will know by looking at the number of folders that there is a lot of files. Suboptimal at the very least.

    Raising awareness about the amount of work needed on a feature is usually done with two things: 1) a good product owner who can explain things in plain English, and 2) a team that maintains the tasks metrics properly so the velocity in reporting is reliable. If you need to work around issues with those two factors by using bastardized user stories you are probably better off with a different project management approach.



  • @Ronald said:

    If you map your user stories to manual activities done by the users instead of the broader underlying business process, your backlog must be hugely fragmented to the point of being useless from a reporting point of view. What is your ratio of tasks per story, 1:1? It's like saying: I prefer to have only one file per folder so the users will know by looking at the number of folders that there is a lot of files. Suboptimal at the very least.

    Raising awareness about the amount of work needed on a feature is usually done with two things: 1) a good product owner who can explain things in plain English, and 2) a team that maintains the tasks metrics properly so the velocity in reporting is reliable. If you need to work around issues with those two factors by using bastardized user stories you are probably better off with a different project management approach.

    I'm not saying I use agile as a way of showing the client how much work there is to do, I'm saying it tends to open their eyes when they see how many stories are involved in even simple things.

    I keep things manageable by grouping stories into logical collections like epics or by using tags. So far, even my dumbest clients have had little trouble organizing iterations. Tasks are saved for the the developers to list the technical implementation steps they plan to use, not as "sub-stories".



  • At first you said this:

    @Soviut said:

    Either way, I like when a client sees a separate story for, say, each CRUD operation as well as one for confirming deletes, they realize just how much work is actually involved in each of their requests.

    Then you say this:

    @Soviut said:

    Tasks are saved for the the developers to list the technical implementation steps they plan to use, not as "sub-stories".

    If each story is a CRUD operation your approach leaves very little blanks to be filled by the developers in their tasks. If the story is: "delete user account" then I wonder how many "implementation tasks" can be derived... My 1:1 figure for your tasks/story ratio looks pretty accurate.

    I don't know if you are figure skating or trolling but your approach is fishy.



  • @Ronald said:

    If the story is: "delete user account" then I wonder how many "implementation tasks" can be derived... My 1:1 figure for your tasks/story ratio looks pretty accurate.

    It leaves plenty of room for implementation. For example, the user may simply be deactivated instead of the record being deleted, or there might be clean up to do, triggers to fire, etc. The story mentions none of those things, it just says "make it possible to delete". I've had enough ambiguity from my clients that this level of granularity is what's most effective.

    I'm neither figure skating nor trolling. Just explaining an agile workflow that I've been using for a while that works fairly well.


  • Considered Harmful

    Our team says we use Agile (loudly, repeatedly), except we don't have user stories, we don't assign point values, we don't have a proper backlog, we don't have cards or corkboards, and our daily scrum with six people frequently runs over an hour in duration.

    No one seems to understand when I put "Agile" in scare quotes or suggest that our process might not actually be.



  • @joe.edwards said:

    Our team says we use Agile (loudly, repeatedly), except we don't have user stories, we don't assign point values, we don't have a proper backlog, we don't have cards or corkboards, and our daily scrum with six people frequently runs over an hour in duration.

    No one seems to understand when I put "Agile" in scare quotes or suggest that our process might not actually be.

    That's not "Agile", that's "frAgile".



  • @Soviut said:

    @dhromed said:
    Ok what the fuck is a story?

    Generally it's a simple phrase that explains...

     

    1. We know what a "story" is.

    2. A better description would be: a way to make a description that once had the potential of being clear totally ambiguous by insisting on absurd brevity.

    2a. Or: an attempt to be culturally sensitive and at the same time give real stories a bad name. You'll be getting many bonus points and likes once the literary community feels forced to adopt a new word for story.

    3. Joost, you effing hipster, is that you?

     


  • Discourse touched me in a no-no place

    @dhromed said:

    Ok what the fuck is a story?
    It's a way of doing requirements capture that is distinguished by being from the perspective of someone who interacts with the desired system, instead of being from inside the madhouse implementation. You then use that to generate internal requirements and potential acceptance criteria.

    It's a lot easier to communicate with customers via stories than algorithms or mathematical specifications; stories are understandable by arts majors…



  • @Soviut said:

    Also, pair programming isn't a bad thing.

    I can vouch for pair programming. Our office has had some rather atomic tasks lately, and my colleague has helped me to concentrate by navigating. I would only estimate maybe 60-100% progress rate increase for the task, but for critical tasks which we can't really split up for greater efficiency, I'd say this works pretty well.

    I also agree that 4 hours seems like a long time for teaching agile development.



  • @bardofspoons42 said:

    SRUM

    Better than missing out the R of SCRUM. ;-)



  • @dkf said:

    It's a lot easier to communicate with customers via stories than algorithms or mathematical specifications; stories are understandable by arts majors…
     

    Who the fuck does that? That can't be a defining/redeeming aspect of scrum, since it should also be in every other method.

    When you combine all these stories into paragraphs, what do you get? A huge spec of the waterfall variety. If your monolithic waterfall spec talks about implementations and algorithms, you fucked up, and no amount of scrum is going to fix that. Goddamn!

    Real questions!

    Who determines what the microspecs (stories) are, and at which points during a project? Is a project ever finished, or just finished enough? The specs we write in our shop read almost exactly like a big collection of those scrum microspecs.chapter 5. User X should be able to do Y. The main pages show the most recent 5 items of Z, ordered by Fleh. Etc.

    The only real difference is the ability to redirect a project, no? If you have a big spec, it's a big oil tanker, and it's not going to change save for hurricanes, and it'll be done and then you got what the spec says. With scrum, it's more of a fleet of microspecs, right? And you can zerg rush the Main Problem and lose some specks in the process and steer big parts of it in some other direction.

    I'm kind of  consciously using the word microspec since I really don't like the term story, but that's just me. Specks is a nice one, too. I'm really good at this, clearly.



  • @bardofspoons42 said:

    Maybe I should play Eve Online and be more productive...

    Go and can-bait some noobs in a starter system... you know you want to.



  • @Soviut said:

    @bardofspoons42 said:
    I'd love for us to start using Atlassian's full stack, including Jira with Greenhopper.

    I'm using it at the current agency I'm working at and, while it isn't slowing me down, it certainly isn't doing me any favours. Trello is great if you need a digital board to move cards along. Pivotal Tracker is great if you need stricter agile workflow, velocity calculation, automatic iteration building, etc. Both have really nice intuitive UIs and APIs to hook into and both can be used in real time across multiple screens.

    The issues I've had with Greenhopper is the UI, while better than it was, is still really clunky. Lots of unnecessary fields. A convoluted "workflow" scheme that needs to be configured otherwise you'll accidentally resolve issues when you just meant to update them. No drag and drop for files. Ticket history is hard to find. It still thinks we should be specifying time spent, etc. etc. etc.

    Jira is better than no bugtracker in the same way that becoming a quadriplegic is better than dying.


  • ♿ (Parody)

    @The_Assimilator said:

    Jira is better than no bugtracker in the same way that becoming a quadriplegic is better than dying.

    Hang on. Aren't you the guy who said Jira was super slow for him?



  • @boomzilla said:

    Hang on. Aren't you the guy who said Jira was super slow for him?
     

    Well, a quadriplegic is super slow without a wheelchair, so it makes sense!


  • ♿ (Parody)

    @dhromed said:

    @boomzilla said:
    Hang on. Aren't you the guy who said Jira was super slow for him?

    Well, a quadriplegic is super slow without a wheelchair, so it makes sense!

    This makes sense to me. IIRC, part of his problem was using an older IE with shitty javascript performance:


    Should have used a decent browser:



  • @boomzilla said:

    @dhromed said:
    @boomzilla said:
    Hang on. Aren't you the guy who said Jira was super slow for him?
    Well, a quadriplegic is super slow without a wheelchair, so it makes sense!

    This makes sense to me. IIRC, part of his problem was using an older IE with shitty javascript performance:


     

    Should have used a decent browser:

     

    I noticed you're using standard Agile pamphlet stock art.

     


  • ♿ (Parody)

    @dhromed said:

    I noticed you're using standard Agile pamphlet stock art.

    AKA the 5 second google image search.



  • @eViLegion said:

    @bardofspoons42 said:
    Maybe I should play Eve Online and be more productive...

    Go and can-bait some noobs in a starter system... you know you want to.

    I'm one of those noobs! I just started playing a few weeks back. I haven't even gotten close to nullsec


  • Discourse touched me in a no-no place

    @dhromed said:

    @dkf said:
    It's a lot easier to communicate with customers via stories than algorithms or mathematical specifications; stories are understandable by arts majors…
    Who the fuck does that? That can't be a defining/redeeming aspect of scrum, since it should also be in every other method.
    I never said that the whole agile thing was worth the BS that's spouted about it, but some bits are genuinely useful. Mix and match. Borrow and steal. (The value in Agile is that it lets the customer figure out what they really want sooner. Provided the customer has the time and the inclination to do that. Sometimes asking them just makes them cross…)



  • @bardofspoons42 said:

    @eViLegion said:
    @bardofspoons42 said:
    Maybe I should play Eve Online and be more productive...

    Go and can-bait some noobs in a starter system... you know you want to.

    I'm one of those noobs! I just started playing a few weeks back. I haven't even gotten close to nullsec

    Are you called bard of spoons in game?



    This could be my excuse to renew subscriptions, and hunt you down give you loads of expensive free stuff.



    If I recall correctly, I had amassed about forty thousand gallons of sweet sweet tears billion in assets at last count.



    Also, fuck nullsec. The profits were in wormhole systems... its just a bit dangerous in the wormhole areas, because cunts like me some nasty people will take all of your stuff and fuck your skull try to make you cry afterwards.


Log in to reply