To Sprint or Not To Sprint?

To Sprint or Not To Sprint?

rbwhitaker 17 May 2016 01:22

I would like to propose the idea that we run sprints during the competition. If the competition is 100 days, that's a lot of time, and I think it will be easy to get lost, discouraged, sidetracked, or bored. I think doing sprints will set up a cadence that will help people keep making progress and give people an easy opportunity to get back in the game if they do run into problems.

The basic idea with sprints is that at regular intervals, you release what you've got, and get it in the hands of people who can give you feedback. Sprints also help you focus on working on only the most important stuff at any given moment in time, because you have to show what you've accomplished.

"Release" could be defined as an actual download (possibly a paid download, if you want to go that route). It could also be a demo video instead. Depending on your goals, it may or may not include the source code. It's a public display of what you've accomplished to date.

Sprints can be varying lengths, but shorter is usually considered better. We don't all necessarily need to be on the same cadence, but I think it would help us all if we were.

I think our best options would be either one week sprints or two week sprints. (I like one week sprints, personally, but if I get outvoted on that, I have no problems with two weeks either.) Three or four week sprints starts to seem a bit too long for this kind of competition.

Perhaps we can even take an hour or so at the end of the sprints, do a little Twitch demo of the progress, and/or swap our games around and play each others' games for a few minutes each and share feedback with each other.

I don't want to turn sprints and sprint demos into a huge arduous task. That would take the fun out of it. The intent would be you just package your stuff up in a ZIP file and post it and link to it in the forum, or that you just put together a 3 or 5 minute demo video of what you've done, with no more than maybe 15 or 20 minutes preparation. No need for a ton of video editing or anything like that.

I think sprints would help us to break a gigantic 100 day competition into more bite-sized milestones, where we can see progress at each step of the way and set new goals. It also gives us an easy way to rejoin if one week doesn't go so well. If you're taking a vacation, just skip a sprint. Busy with work? Skip a sprint. Get bored with the game you're working on? Call it "done for now" at the end of a sprint and pick a new game that excites you a little more in the next sprint.

Thoughts?

Re: To Sprint or Not To Sprint?

Swatacular 17 May 2016 16:52

I don't know, I have a feeling sprints aren't in our best interest, I feel like they would be to easy to "get used to" and basically only work during the sprints.

Maybe if once every 20 days we had a 1-2 day sprint.. that might "get the ball rolling" if it stopped for you.. but I don't want to rely on being carried through with sprints..

I am probably not wording this correctly, But this time I am opposed to sprints, or atleast opposed to longer sprints.

If you split the 100 day competitions into 10 10-day sections.. I feel like that would be different.

Basically the time inbetween the sprints is what worries me (unless the sprints are really short like 1 day)

Re: To Sprint or Not To Sprint?

rbwhitaker 18 May 2016 02:44

I probably didn't explain myself very well. My intent was that there would be no time in between sprints. They'd all fall back-to-back. For example, maybe all sprints would start Monday morning and end Sunday night, through the whole duration of the competition. My intent was more along the lines of your 10 10-day sections, just with boundaries that line up with weeks in some form or fashion (either 1-week blocks or 2-week blocks).

Re: To Sprint or Not To Sprint?

Marcus42 18 May 2016 05:11

Personally, I think splitting the competition up into sprints is a really exciting idea, largely for the reasons you've already mentioned, RB. Also, I'd prefer one week sprints as well, but two weeks wouldn't be an issue. I just think that we'd (or at least, I would) be more likely to pick too much to do with two weeks to work with and would be less likely to pick one specific thing to focus on and then move on to something else once the sprint is over.

And yes, regular "mandatory"-ish updates/releases would be nice on both sides of it, I think. As the developer, it's a good chance to see what you've done, what went well, what went badly, and also potentially free you up from trying to post an update every day by instead just doing it once a week (although more frequent updates would by no means be a problem), and as the one following along, fairly consistent updates is of course nice.

Re: To Sprint or Not To Sprint?

Brett208 19 May 2016 15:27

I really like the idea of incorporating sprints. One week seems like a good time frame as it is long enough to make legitimate project towards goals but short enough that it will not encourage too broad of goals.

I also like picking a particular admin/end of sprint day every week. Monday seems logical since most people will probably do the bulk of their work on the weekend if they have 9-5 Mon-Fri jobs. Taking one day a week to review progress and post about it will help us track our progress and review goals. Also, I think posting a video or a couple of screenshots on Monday if you feel like that is a better medium than a demo would be cool as well. I think forcing people to review their sprint goals once a week will help them keep focused on cutting unnecessary priorities moving forward with the project.

Since 90 days is a long time for the competition, I also like the idea of being able to designate breaks. So If I have a major life event like school graduation or am just going to be extra busy at work, or just need a planned break, I can post that I'm taking the next sprint off and then jump back in after a week off.

Re: To Sprint or Not To Sprint?

Brett208 19 May 2016 15:35

I think we are using sprint in chat for 30 minute coding sessions sometimes (which is fine). Here is the definiton of a sprint from the Wikipedia article on SCRUM. I guess there are other programing methods out there that may define it differently, but it is generally what I think of when saying sprint:

A sprint (or iteration) is the basic unit of development in scrum. The sprint is a timeboxed effort; that is, it is restricted to a specific duration.[22] The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common.[13]

Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the work for the sprint, and make an estimated commitment for the sprint goal. Each sprint ends with a sprint review and sprint retrospective,[9] that reviews progress to show to stakeholders and identify lessons and improvements for the next sprints.

Scrum emphasizes working product at the end of the sprint that is really done. In the case of software, this likely includes that the software has been integrated, fully tested, end-user documented, and is potentially shippable.[21]

Since we are one man part time teams, we are not going to be able to have 'potentially shippable' software at the end of each sprint. However, we should be able to attempt defining reasonable goals that can be finished in one week. These goals should be able to be showcased through a screenshot/demo/video or just writing about it.

Re: To Sprint or Not To Sprint?

rbwhitaker 20 May 2016 03:01

Yeah, that's a good point. There's definitely a bit of confusion about the term "sprint", and it's good to clarify.

I used to use the term "code war" for our little 20 or 30 minute sessions in the chat room. Somehow, "sprint" is the term that stuck.

In this context, when I say "sprint", I am referring to the Scrum/agile term, which lasts weeks, not minutes. (Though I think we can definitely do both Scrum sprints and the chat room code wars. No need to pick only one.)

I do actually think that all of us could have "potentially shippable" software every sprint, honestly. I probably don't have time to concisely describe why I think that, or how you'd do it. "Potentially shippable" doesn't mean "complete" nor does it mean "people would actually plop down money for this thing." It means you don't have any notable bugs, and that people can use what you're shipping. For example, you don't have a button that doesn't do anything (or worse, clicking on it crashes the game). Either the button is not there at all, or it does what it says it does. I personally like the idea of aiming for a potentially shippable version at the end of each sprint. It's not the only way to make software, but it's a good way.

I'll also agree that I think posting some screenshots is probably a good alternative to a demo video or a download. I think I'm going to be trying for an actual download every week, but some screenshots and a bit of descriptive text fits the bill just fine, IMHO.

Re: To Sprint or Not To Sprint?

Brett208 20 May 2016 16:50

@RB,

When I was researching Agile/SCRUM a while back, I didn't really understand what was meant by shippable software every two weeks. What you are saying about simply being bug free and not containing incomplete features clicks though and is definitely possible.

The important thing is to set manageable goals and re-asses them regularly. Goals that result in bugfree software at the end of each sprint would definitely count.

I'm intrigued by the twitch idea you brought up in the first post. I think the hard part would be finding a good time to get most of us together though since we have multiple time zones and some people on night shifts at work. My family and I are now UTC-10.

Re: To Sprint or Not To Sprint?

rbwhitaker 21 May 2016 00:54

That's a valid point. I don't know if it will be possible to actually do the Twitch thing back-to-back. As far as I'm aware, your UTC-10 is the most extreme. I'm UTC-6, so I also know that some people are UTC-4 because of that. That's a six hour difference. We might be able to find a time that works, but we also might not. Perhaps our time zones are diverse enough that it's not worth trying.

Perhaps instead, we just say something to the effect of, "Sprint demos should be posted by the end of [Last Day of Sprint]," and then people can check them all out the next morning. "Sprint demo" might be just some images, or it might be a video, or it might be something else. The goal would just be that you post something showing your progress, so we can see how things are going and give feedback.

Re: To Sprint or Not To Sprint?

Swatacular 23 May 2016 14:37

Now that I've thought about it more, back to back sprints aren't that bad of an idea, but I wouldn't call them sprints.. maybe jogs, or milestones.. but not sprints.. I still want to have actual SPRINTS but not on a regular basis.. nobody on earth regularly sprints anywhere, its either a jog, or run, or they make a exception and sprint for a little bit.

That is all just terminology, so as long as we understand each other, we are good.

Re: To Sprint or Not To Sprint?

Brett208 23 May 2016 20:46

@Swatacular,

I get what you are saying about Sprints not really being long term in reality, but for whatever reason it is the industry standard term for 1-2 week production cycles. Maybe it just sounds cooler to say sprint than jog. Plus it makes your boss think you are working hard sprinting for him instead of jogging for him and the company… or maybe not?

Okay,

I motion that sometime this week RB sticky a post on the official rules (recommendations) for the intervals. It sounds like 1 week with reporting on progress and setting new goals on Monday seems to be where we are at. I think we are agreeing that when possible to showcase the last weeks progress with a working demo/video/screenshot.

If people want to do Twitch, we could target 6PM Pacific Time (9PM Eastern Time). That would put it at a reasonable time for anyone in North/South America on a normal work schedule. Maybe an hour earlier is 9PM is too late for those on Eastern Time. It would be 3PM for me, but I think I'd be able to be flexible at work on occasion and maybe make some. Personally, I would also be happy just doing a text update for everyone on Monday though. We could also target Twitch on the 1st and 3rd Monday of every Month if people think weekly twitch sessions are too much?

Re: To Sprint or Not To Sprint?

rbwhitaker 23 May 2016 23:54

Yeah, it's true. "Sprint" is the term that has come to be the de facto name for back-to-back, multi-week chunks of work that define the cadence of your work and releases.

Honestly, having done a fair amount of running myself, I would say that "sprint" is very much the wrong word for this kind of thing. In fact, I'd also say that "marathon", or "run" is also the wrong word. It really is more like those obstacle/mud runs that people often do in teams, like Tough Mudder. Sure, you spend a fair amount of time running, but there are always obstacles that get in your way, and you have to come up with creative solutions and work with your team to get to the finish line. They're messy and unpredictable. That's more in line with what I think software "sprints" really are.

But I'd prefer to keep our sprints here called sprints, since that's what most people in the industry are familiar with.

Our little code wars/sprints in the chat room probably should have a different name to avoid confusion. But that's a topic for a different day.

Re: To Sprint or Not To Sprint?

Marcus42 23 May 2016 23:18

Out of curiosity, how many of you are thinking about doing a Twitch stream every Monday (or maybe just some Mondays) as opposed to a video/screenshot/text update?

Re: To Sprint or Not To Sprint?

rbwhitaker 23 May 2016 23:49

I'm seriously tempted to, which is why I brought it up. If nobody else is all that interested, I probably won't do it either. I can always do just a normal video update, or throw in some screenshots and text like I've done in the past.

There are a couple of minor advantages to the Twitch stream. One is that you get immediate feedback from people who are watching. The other is that I think because it is a live demo, you won't spend a ton of time trying to cut/edit a non-live video. I'm a little concerned that if I made a normal video, that I'd sit there trying to tweak everything to death before publishing it. The point of the competition is to make a game, not to make a video about a game. Having said that, feedback has never really been a huge problem in these competitions, and there are other ways to limit the time you spend making a demo video anyway. So I'll admit the gains are probably fairly limited.

Re: To Sprint or Not To Sprint?

Brett208 24 May 2016 05:38

I like the idea of getting immediate and honest feedback. It is also motivation to complete your objectives when you will be talking to someone else about them. I also like that people do not have to prepare a video for posting, which can take a while.

I guess the idea is warming up more on me over time.

Re: To Sprint or Not To Sprint?

mdjdejesus 24 May 2016 15:11

I'm am new to Twitch (created my account last night), so please forgive if I'm asking a dumb question…

How do we coordinate these demo viewing in Twitch? If we are all streaming to different "channels"; does that mean that we will have to set a schedule or something? so, we know who is streaming at what time and switch to their channel.

Or, is there a way that we can all stream to a common channel, and coordinate via chat?

I like the idea of Twitch; just don't know how it would work.

Thanks Guys.

---

—Javier DeJesus

Re: To Sprint or Not To Sprint?

rbwhitaker 25 May 2016 00:22

Twitch has a way to basically rebroadcast another person's stream on your own. I've never played around with it, so I don't know the details. But what I think would happen is one person would be the host, and everybody could just tune in to their stream. The host would then rebroadcast the various people's streams at the right times, giving everybody a turn to show off their game.

That's how I'd approach it.

Like I said though, I'm not sure how practical the Twitch thing is anymore. I'm leaning towards skipping it, at least for a couple of weeks until people get the hang of everything else.

I'm actually going to be doing a game as a part of a team, and I don't know yet how they feel about demos and such, so I probably shouldn't make a firm commitment to anything just yet anyway.

Re: To Sprint or Not To Sprint?

Metaphysico 11 Jun 2016 23:16

If you want to work in sprints, Microsoft Team Services (formerly Visual Studio Online), uses an agile template where you can create sprints, then make stories and tasks and assign them to sprints. Best part is its source control and its FREE up to 5 developers. Stories should be able to be completed in a sprint, and tasks are things to do for that. If you spend the time to make up the "backlog" of stories and tasks it will help you stay focused and on track.

I cannot post links but look on visualstudio.com for more info.

I have been using the system since 2013 and it has proven a great tool. They are updating and fixing they system all the time and finally have the build system fast and easy to use, along with unit test runs, great for CI builds with Unit Test runs.

I am currently setting up the plan for my new game.