tag:blogger.com,1999:blog-11719805.post645615876495728682..comments2023-11-03T01:45:11.288-07:00Comments on Lost Garden: Rockets, Cars and Gardens: Visualizing waterfall, agile and stage gateDaniel Cookhttp://www.blogger.com/profile/10437870541630835660noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-11719805.post-86826578790835765362011-01-06T09:12:31.734-08:002011-01-06T09:12:31.734-08:00As a potential plant breeder is resembles what I a...As a potential plant breeder is resembles what I am being trained to do but I am not convinced that it will work in this case.<br />The usefulness of this method rests on several assumptions <br />1 that you have limited resources to devote to your teams (nearly always true)<br />2 that you can successfully tell the difference between a good game and a bad game (not usually a problem)<br />3 that early quality is highly correlated with later quality (this one is the cause of most problems)<br /><br />I don't believe that you can currently judge the finished project reliably by the demo.<br /><br />There is a pretty simple way to test how good you are at predicting. You run the whole project like normal but this time instead of actually culling teams at each stage you just write down on paper which teams you would cull. When the projects are finished you compare the teams that you would have culled with the teams that passed every sage and see how different their success rates are.patchworkZombiehttps://www.blogger.com/profile/18279408952877283952noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-41787620160898397322011-01-03T13:32:31.212-08:002011-01-03T13:32:31.212-08:00Hello Danc,
Your post is great! Many thanks! I...Hello Danc,<br /><br />Your post is great! Many thanks! I've translated it into french :<br />http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/01/03/Fusees-Voitures-et-Jardins-%3A-visualiser-le-modele-en-cascade-le-processus-agile-et-la-methode-du-passage-de-portes<br />Regards,<br />FabriceJapon 2023https://www.blogger.com/profile/01876392284304887848noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-36168697037794132912009-11-08T16:05:41.645-08:002009-11-08T16:05:41.645-08:00Great article, thanks for sharing.
Our team uses ...Great article, thanks for sharing.<br /><br />Our team uses a hybrid prototype+agile method.<br /><br />We fire off multiple rapid prototypes to test opportunity areas then use agile to get there. This is a good approach for small teams.<br /><br />Here's a diagram - http://twitpic.com/otkdc<br /><br />Cheers,<br />twitter.com/aussie_ianIanhttps://www.blogger.com/profile/02440846089174159574noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-12646341224805356622009-02-02T19:47:00.000-08:002009-02-02T19:47:00.000-08:00Has anyone come accross a good article on Agile de...Has anyone come accross a good article on Agile development methods applied to hardware-based products? Is it possible? What are the trade-offs?Noelhttps://www.blogger.com/profile/13253501285604562246noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-5942794426785592002007-03-20T09:23:00.000-07:002007-03-20T09:23:00.000-07:00David: Yep, I've read one of the Lean Software Dev...David: Yep, I've read one of the Lean Software Development books. It is a great read and has some wonderful concepts. Recommended. It is good to see these useful concepts from other industries making their way over to the software world. <BR/><BR/>Adrian: Very cool! Go Relic! Stage gate techniques are a pretty rational way of bringing a touch of sanity to a rather messy and creative process. The real trick is in the design of the gates and how they are applied. It is a great opportunity for the company to ask "What do we really value?" :-) <BR/><BR/>In the best of cases, the process gives a clear and ongoing opportunity for new-to-the-world projects to thrive. That is pretty darn cool (in addition to helping reduce risk)<BR/><BR/>take care<BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-51512614193246256502007-03-12T23:40:00.000-07:002007-03-12T23:40:00.000-07:00Great article, as usual. Thanks for this. We're he...Great article, as usual. Thanks for this. We're heavy into Scrum at Relic and one of the things I'm specifically working on is our new products strategy. I've been reading Cooper's book and I had read your Project Horseshoe stuff, so by now I'm pretty convinced we should be using a Stage Gate system for new product development.<BR/><BR/>Love the diagrams too. :)<BR/><BR/>AdrianAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-23173687525579370222007-03-03T22:47:00.000-08:002007-03-03T22:47:00.000-08:00Have you read Mary and Tom Poppendieck's Lean Soft...Have you read Mary and Tom Poppendieck's Lean Software Development books? I would assume so, since you mention both lean manufacturing and agile here, and those books explain how applying lean ideas (lean product development, actually, rather than manufacturing) to software gives you agile ideas, but some of their recommendations that aren't part of traditional agile seem closely aligned to what you mention.<BR/><BR/>In particular, their discussion of funding models is closely aligned to your multi-project scenario (if I'm remembering them correctly - my copies of their books are at work), and their set-based design looks a lot like your single-project version of this. Concept banks show up in there, too.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-85167825449183388232007-03-03T10:21:00.000-08:002007-03-03T10:21:00.000-08:00Re: Using Movies as a modelThis is in fact what th...<B>Re: Using Movies as a model</B><BR/><BR/>This is in fact what the industry has been doing for the past decade or so. It tends to work poorly. By bringing the language of NPD into the picture, the hope is to give developers and publisher new tools that help improve success rates. <BR/><BR/>A couple of differences between movies and games give me hope that this tactic might work: <BR/>- Games can be tested incrementally. The core 15 minutes of gameplay is generally indicative of the broader experience. You can test games with your audience earlier and need to rely less on expert opinion. <BR/><BR/>- There are still numerous market niches that are not being tapped. Nintendogs, Sims, Bejeweled, Various Serious Games, Brain Training, Sing Star all tapped into huge markets that most game developers didn't even realized existed. Just yesterday I was using a pedometer mixed with a virtual pet mixed with a DS game and it was amazingly useful. That is a new to the world product if I've ever seen one. A process that actively seeks out these niches is something worth striving for. <BR/><BR/>I'm fascinated that games are utilitarian software as much as they are fluffy content. We have the ability to dramatically change their functional capabilities so that games fit into different customer environment. The environment. With game, you can serve entertainment while riding a train vs entertainment while walking vs. entertainment while at home vs entertainment while hanging out with friends. Each of these need different entertainment applications with distinctly different functionality. This is less the case for static content with a fixed viewing platform.<BR/><BR/>People have a wide variety of entertainment needs. Games, as software, have the ability to morph and meet those needs in ways quite unlike any other media. This flexibility presents a vast landscape of new-to-the-world entertainment opportunities ill served by committees of inward looking cultural judges. <BR/><BR/>We need a process that looks outward and can ask the housewife when she has the need and opportunity for entertainment. Is it in the 15 minutes that she picks up the kids before soccer practice? Who are the other people around her? Other moms? What are their shared interests? Do they need something to break the ice? If we come up with a solution, how can we judge the market validity of the idea? These are the sort of questions that good NPD practices excel at asking, answering and converting into blockbuster products.<BR/><BR/>In movies, you have the script writer, the director, the suits making decisions. It is only at very, very end of the process that customers are involved. This is not a process that fills unserved needs. It is a process that serves minor variations of content to a well established audience with a well established need. With games, we are still discovering new needs and new markets. We need a process that helps, not hinders our progress. <BR/><BR/>take care<BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-53192356128498549742007-03-02T04:48:00.000-08:002007-03-02T04:48:00.000-08:00Doesn't Hollywood basically use a stage-gate syste...Doesn't Hollywood basically use a stage-gate system for TV production? <BR/><BR/>The typical model is this:<BR/><BR/>* Pitches for shows are submitted. <BR/>* The survivors are filtered and pilot scripts and production estimates are submitted. <BR/>* The survivors of that stage are then commissioned as pilots.<BR/>* The surviving pilots are then commissioned with episode runs<BR/>* The shows that are performing poorly by mid-season are then canned.<BR/><BR/>So, every year they end up receiving thousands of show ideas which turn into maybe 3 good shows. It's a very expensive process.Tadhghttps://www.blogger.com/profile/14763670950211297013noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-37278353061166717502007-02-27T15:40:00.000-08:002007-02-27T15:40:00.000-08:00Thanks for the fascinating post!As a NPD consultan...Thanks for the fascinating post!<BR/><BR/>As a NPD consultant working in industries outside of game/software development in addition to a geek/programmer when I first read this post I thought it was about general software product development. <BR/><BR/>After a second read and looking at the very interesting project horseshoe discussion I realized that this is mostly focused on games. But I think that it still applies to other software product development practices, maybe more so!<BR/><BR/>I know very little about the game industry. Coming from a NPD perspective I think that it has much more in common with the movie industry than it does with the industries that have implemented Cooper style stage gate processes.<BR/><BR/>One thing that may be confusing to many is that the first few stages of this process don't involve development work. <BR/><BR/>Assume the example stage gate: Idea > Scope > Business Case > Development > Launch. <BR/><BR/>We usually advise our clients that the end of the third stage (business case) they build a prototype. It's hard to say that you've made your business case if you can't overcome the technical hurdles. In consumer products they need this for the first steps of Development - mainly focus groups. In software development its one of the primary things that agile methodologies have taught us.<BR/><BR/>Most of the upfront work (fuzzy-front-end) has to do with identifying and exploring unmet needs. This is also where the majority of our clients need help. However when the primary function of the product is entertainment how do you answer questions like:<BR/><BR/>How is it done now?<BR/>Whats wrong with it?<BR/>Whats the value of the improvement?<BR/><BR/>If I'm talking about P&G's Swiffer these questions are easy.<BR/><BR/>If we are talking about a game engine the functional requirements are much easier to nail down because your primary customers are the people who have to build the game on top of it. I realize that their needs are in turn driven by the end user but I hope I make the point.<BR/><BR/>The need is never for the product - its for what the product can do. <BR/>What does your product do? It engages and entertains me. Isn't this the same function a movie fulfills? Perhaps a better model than stage-gate would be the hollywood model. Although their success rate isn't much better they are able to spread the risk around <BR/><BR/>This applies to the overall success of the game and the decision about whether to make it at all. However, if we are talking about specific features I think an adapted stage gate process might be useful for separating the wheat from the chaff.<BR/><BR/>Anyway, thanks for the interesting topic. I am very curious to see where it leads and how you apply these NPD and Stage Gate concepts.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-58772514720339144612007-02-25T19:49:00.000-08:002007-02-25T19:49:00.000-08:00Applying harvest to GamesJoe, applying something l...<B>Applying harvest to Games</B><BR/>Joe, applying something like the Harvest process to games is an interesting challenge. However, it is the same basic problem that you run into with any multi-team agile effort. I won't say this is solved problem, but there are companies doing it right now with reasonable success. <BR/>- <B>Integrate frequently:</B> Everyone is integrating their code into a shared code base. Some throwaway prototypes might not make it in, but building together and running everyone's regression tests makes it more difficult for things to completely diverge. <BR/>- <B>Individual teams still talk to other teams.</B> Most of their high bandwidth communication will occur between one another, but you still want meetings periodically between different teams and different disciplines. Programmers should meet every couple weeks and chat. They'll enjoy and good things will come out of the conversation. <BR/>- <B>Shared Library team:</B> One Scrum technique is to have another team that comes in after teams have build something and figure out how to refactor that code into libraries that the other teams can use. This still allows innovation on the edges, but also helps a) prevent unnecessary rework and b) create a shared technology platform that accelerates the progress of each team. <BR/><BR/>There is a nice article on applying Scrum to game development in the February 2007 issue of Gamasutra ("Scrum Rising, Clinton Keith, pg 21). He covers the basics like developing in vertical slices and the overall process. He also runs a blog that I enjoy linking to called <A HREF="http://www.agilegamedevelopment.com/blog.html" REL="nofollow">http://www.agilegamedevelopment.com/blog.html</A><BR/><BR/>Your last comment about including the failed-at-the-last-stage features is one of the sad things about modern game development. Many of those features could have been killed earlier and a lot of unnecessary wasted effort could be saved. Strong Kill Gates can be politically hard to implement, but are immensely useful once you follow them. <BR/><BR/><B>It isn't your job to build bullet points</B><BR/>It is better to release less than it is to release more of poor quality. Players are motivated by the quality of the experience, not a check list of features. If you need a checklist for a product, that is marketoid task. Any MBA worth their salt can take the simplest and easiest to use product on the market and generate an impressive feature list. <BR/><BR/>See this video about the iPod: <BR/><A HREF="http://video.google.com/videoplay?docid=36099539665548298" REL="nofollow">http://video.google.com/videoplay?docid=36099539665548298</A><BR/><BR/><B>Cabal</B><BR/>I also recommend that folks check out any articles they can find on the Cabal process used at Valve. The terminology is slightly different, but it shares many of the same attributes. They rely heavily on customer testing to ensure the good stuff gets additional love and the bad stuff gets killed. <BR/><A HREF="http://www.gamasutra.com/features/19991210/birdwell_01.htm" REL="nofollow">http://www.gamasutra.com/features/19991210/birdwell_01.htm</A><BR/><BR/>take care<BR/>Danc.Daniel Cookhttps://www.blogger.com/profile/10437870541630835660noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-9825699085855050802007-02-25T16:46:00.000-08:002007-02-25T16:46:00.000-08:00I think if I worked at Microsoft, I would not let ...I think if I worked at Microsoft, I would not let the phrase "Kill Gates" appear so many times in one blog entry. ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11719805.post-40030206615643025902007-02-25T15:48:00.000-08:002007-02-25T15:48:00.000-08:00Your diagrams are so much nicer than mine. :)The t...Your diagrams are so much nicer than mine. :)<BR/><BR/>The trouble with the Harvest process is this: Game development tasks are almost never orthogonal. Unless your technology is 100% set in stone when you start, you're going to be making changes to things like the file formats and code libraries the whole way through development. You make those changes because of feature A or B, but they often affect sections of the game outside of those specific features. Arranging these features into silos that don't interact with each other is a recipe for disaster.<BR/><BR/>Of course if you smudge the circles together a little and include the failed-at-the-last-stage feature in the finished product you have a pretty accurate picture of the development process of an average game.Joe Ludwighttps://www.blogger.com/profile/05216200749512371935noreply@blogger.comtag:blogger.com,1999:blog-11719805.post-71915574129041590912007-02-25T13:00:00.000-08:002007-02-25T13:00:00.000-08:00Would you like to speak at our Agile user group. B...Would you like to speak at our Agile user group. Been following your blog for some time and think it would be great. We are in Denver, if you are ever in the area. See http://www.agiledenver.org and there is contact info there.Unknownhttps://www.blogger.com/profile/08778309972758034302noreply@blogger.com