Developing a New Major

scrum is a type of agile development

agile = develop product using short iterations so you can fix problems while they’re small

everybody involved (on the team) knows what’s done, what needs to be done still

ned early and often communication

a lot of team mentoring and support

have a working game at the end of each iteration – and be sure to keep updating the design doc

agile takes a lot more mnagement  need a scrum master for each tem (someone who’s ful time production person no programming or drawing – they need special scrum master training)

going to agile development takes management buy in, publisher buy in – because you need extra resources, but as payback they get less wasted time, less need for crunch time

key to this kind of development – have to find the fun first in each feature (with waterfall might not have anything playable till all the work done nad hten you find out it’s not fun)

get sense of ownership by the team, especially important wiht big teams

many companies donn’t use pure scrum (maybe too expensive, not good for every develpmetn project, not good for creating lots of art assets for instance)

agile good when there’s lots of risk and uncertainty

team members like seeing hte whole project scope – can suggest changes with full knowledge of hte project, without stepping on toes of other groups

but the scrum philoosophy of communication can go across the whole project

scrum is a process, there are specific rules based on teh agile philosophy, can get certified in scrum ($$$)

waterfall – traditional project management, create lists of tasks, assumes you can break project down into tasks and know what sequence to do them in and how tlong they’ll take – most game development doesn’t fit this model

with straight scrum – each iteration starts with an 8 hour meeting, each day starts with a 15 minute scrum short meeting, management has to let go and let developers and programmers do what seems best day to day

outsiders can’t demand/stop the project during a sprint, only at end of iteration

have prototype to test at every step

average spring lasts 14-30 days

morning meetings point out what’s going wrong, people held personally responsible if htey’re holding up the project

not an excuse not to plan – but rather not to waste time overplanning

agile – gotta let go of the ego – get everybody involved in the development/discussion but also bringing ego in in terms of being responsible and motivated

marketing and busienss decision play a part too – designers can’t dedcide everyting – not a democracy – there’s a leader with authority to make decisions

short sprints – make progress on an idea, set milestones to finishe during that sprint, set length of time – no slippage

waterfall – fixed steps, time flexible – not good because it leads to late projects

at end of every spring – ask is the product fun, does the new feature add to the game, if it’s not fun have to work on fixing it

hard to hide bad engineering or sucky ideas because everyone can see right away

tools – pivotal tracker, accumate, fogbuzz, basecamp (not great, outgrow it quickly), shared whiteboards with sticky noes, google tools, unfuddle, Hansoft, MS Groove

MS Project good for waterfall, good for big overview

can’t plan away uncertainty – in game development there’s a lot of uncertainty – agile is about feeding feedback back into the plan

agile about delivery of features, not finishing tasks

sharp focus on short term goals

future goal/end goal is known but less clear than near term goals

disaggregation occurs each sprint – as you go along sprint works on only highest priority stuff and you break it down into pieces that you can work on in that short sprint period

with agile shippable products are created each iteration – each round you keep building ont he project, make it more fun

front load the high value parts of hte project so you get done in the time given

scrum is one kind of agile developement

it’s results and collaboration focused

sprint planning meeting – 8 hours at start of each sprint – this meeting is for them team, to keep updated on progress, not to update scrum master. scrum master not running the meeting, just htere to solve problems, to keep people on track if they start solving problems. meeting is to update – - problems solved elsewhere

eaily 15 minute stand up scrum team meeting – what did i do yesterday, what am i doing today, what’s holding me up

at end of each spring have a 2 hour or so long retrospective meeting to see what went right and wrong, keep everyone in a state of improvement

agile developed for products with lots of releases, short development, games aren’t like this either – could use internal play test builds or beta test builds as artificial ship dates  – don’t use marketing builds (they usually have a lot of smoke and mirrors)

scrum master cuts thru bureaucracy, has to be invested i how well the process worked, did things product owner want get imploement, did team collaborate, doesn’t care if project sucks

gotta have design doc, user stories – these still needed to build features

user stories – what are we letting user do, what happens on the screen

burn down chart – estimates vs actual work time

war room – wher eyou keep track of backlog, current stuff, finsihed stuff – - could be note cards on a wall

doesn’t wrk out of hte box for artists and designers

large group don’t always have a sense of ownership

scrum is hard to get started – people gonna need coaching/mentoring, regular reviews to let people know how they’re doing

easy to fall back into waterfall methods

bad habits – over design, over planning, delayed integration

get improved morale, productivity, quality, build reliability

easy for anyone to see/find out progress of project at any time – and that makes management happy

might take up to a year to get really up to speed with scrum, easy for management to panic and torpedo the process

to avoid crunch time – estimate good, don’t commit to doing more than you can do, you mess up the teams if you over commit and burn yoruself/them out – so under comit and over deliver

company culture has to commit to no crunch – sometimes have to be willing to say we overcommitted and can’t do this in the alloted time and cancel the project

Trackback URL