{"id":12267,"date":"2007-03-09T15:21:41","date_gmt":"2007-03-09T15:21:41","guid":{"rendered":"http:\/\/blogs.adobe.com\/jnackdev\/2007\/03\/agile-development-comes-to-photoshop.html"},"modified":"2007-03-09T15:21:41","modified_gmt":"2007-03-09T15:21:41","slug":"agile_development_comes_to_photoshop","status":"publish","type":"post","link":"http:\/\/jnack.com\/blog\/2007\/03\/09\/agile_development_comes_to_photoshop\/","title":{"rendered":"Agile development comes to Photoshop"},"content":{"rendered":"<p>The Register <a href=\"http:\/\/www.regdeveloper.co.uk\/2007\/03\/08\/adobe_cs3_development\/\">hosts a Q&amp;A<\/a> with Photoshop co-architect Russell Williams about how the team changed its ways in the CS3 development cycle, making product quality paramount, improving the team&#8217;s work\/life balance (i.e. fewer &quot;Photoshop widows\/-ers&quot; who never see their loved one), and yet still delivering a rich set of features.&nbsp; In brief: rather than building all the features up front, then spending the rest of the cycle fixing them, the team moved to a more incremental development model, insisting that bugs be fixed as we went along (not allowing them to build into a late-stage &quot;bugalanche&quot;).&nbsp; The article is a good read if you work in product development, or if you just want some inside geekery on how this stuff gets done.<\/p>\n<p>Russell addressed the engineering side, so I thought I&#8217;d add some product management perspective.&nbsp; Overall I&#8217;m pleased with how things have gone, but no approach is perfect, and it&#8217;s worth noting some of the challenges we faced. [Continued in this post&#8217;s <a href=\"http:\/\/blogs.adobe.com\/jnack\/2007\/03\/agile_development.html#more\">extended entry<\/a>]<\/p>\n<p><!--more--><br \/>\n<\/p>\n<ul>\n<li>The team&#8217;s ability to deliver a public beta&#8211;a first for a major Adobe application*&#8211;is probably the single greatest tribute to the new method.&nbsp; In the old days, we could have delivered a feature-rich beta, but the quality would have been shaky at best.&nbsp; This time, as Russell says, &quot;The public beta was basically just &#8216;whatever build is ready on date X,&#8217;&quot; because we knew it would be stable. <\/li>\n<li><u>Flexibility means uncertainty<\/u> about what features you&#8217;ll be able to deliver.&nbsp; As you&#8217;d imagine, that can be pretty stressful for a product manager whose responsibility is the overall feature set. <\/li>\n<li>It&#8217;s hard to do agile development when you have to interact with organizations that aren&#8217;t necessarily set up for it.&nbsp; Corporate marketing, for example, want to know early on what features you&#8217;re planning to ship. &nbsp;With our approach we deliberately kept ourselves from committing to certain things until late in the cycle. &nbsp;Short story: <u>you have to keep the paint wet<\/u> on documentation, marketing, demo scripts, and so forth much later than you otherwise would. <\/li>\n<li>This is particularly challenging when outside groups are having to handle a large number of projects at once&#8212;a situation  that makes them want details &amp; confirmation sooner, not later. &nbsp;And it&#8217;s one thing when you&#8217;re talking about marketing or docs, quite another when you&#8217;re talking about an external technology team (&#8220;Will you commit to doing the integration work we need?&#8221;).<\/li>\n<li>This was a learning experience for everyone, including beta testers. &nbsp;I think that a number of folks who were used to seeing everything up front spent more than a few months saying, &#8220;Er&#8230; so this is all there is?&#8221; &nbsp;And we could only say, &#8220;We don&#8217;t know yet, and we won&#8217;t know for a while. &#8221; <\/li>\n<li>The upside of this was that <u>we could make course corrections more easily<\/u> than in the past. &nbsp;With the old method, an engineer would sign up for features A, B, and C, then get them all to a marginal level of quality as quickly as possible, then spend the rest of the cycle fixing bugs. &nbsp;With the new method, she would work on feature A until it was pretty well polished, asking for feedback the whole while. &nbsp;If we decided that further work on feature A was more important than feature B and\/or C, we had a much better time making that trade-off. <\/li>\n<li>By the end of the cycle, then, <u>we started hearing much happier noises from the testers<\/u> than I remember in the previous two cycles.<\/li>\n<li>A minor point, but a real one: those of us who give demos throughout the cycle often had to juggle a great number of builds&#8212;the 3D build, the correct correction build, the performance build, etc. &nbsp;I&#8217;d often find myself running three or four separate copies of CS3 simultaneously on my Mac (possible via a little hacking of the resources).&nbsp; Tabbing through several identical feather icons while people look on is&#8230; interesting.&nbsp; So, if you&#8217;re going to go down this route and plan to demo, you should make sure you&#8217;re stocked with RAM. \ud83d\ude42 <\/li>\n<\/ul>\n<p>*<em>Lightroom, the  Flash AS3 preview, and other efforts were different beasts in a variety of ways.&nbsp; Photoshop CS3 is the first time Adobe took one of its flagship, shipping applications and released it this widely with a full set of new features. <\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Register hosts a Q&amp;A with Photoshop co-architect Russell Williams about how the team changed its ways in the CS3 development cycle, making product quality paramount, improving the team&#8217;s work\/life balance (i.e. fewer &quot;Photoshop widows\/-ers&quot; who never see their loved one), and yet still delivering a rich set of features.&nbsp; In brief: rather than building [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/posts\/12267"}],"collection":[{"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/comments?post=12267"}],"version-history":[{"count":0,"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/posts\/12267\/revisions"}],"wp:attachment":[{"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/media?parent=12267"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/categories?post=12267"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/jnack.com\/blog\/wp-json\/wp\/v2\/tags?post=12267"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}