User jimmy bosse - AgileShout.commost recent 30 from http://agileshout.com2010-09-06T18:05:45Zhttp://agileshout.com/feeds/user/7http://www.creativecommons.org/licenses/by-nc/2.5/rdfhttp://agileshout.com/questions/51/agile-process-tools/103#103Answer by Jimmy Bosse for Agile Process ToolsJimmy Bosse2009-12-17T12:54:42Z2009-12-17T12:54:42Z<p>You need to adapt to both your team and your business owner. We have tried several different system. I like Target Process, especially the new Kanban board, but for my current business owner, the physical task board works best and we have greatly increased our productivity since switching to it. the key is to sit down every iteration, sprint, or other predefined amount of time and discuss making small changes to enhance your process. Don't make too many at once, and make sure you go back to review if it is working. This is how we found out that the physical board works best with our environment. Adapting to your environment is the essence of Agile.</p>
http://agileshout.com/questions/88/how-should-you-structure-you-code-commits/102#102Answer by Jimmy Bosse for How should you structure you code commits?Jimmy Bosse2009-12-17T12:49:25Z2009-12-17T12:49:25Z<p>I agree with both Kevin and Jonathan. What's important to note it that different source control systems allow for different work flows. Kevin's Red, Green, Refactor, Commit is an excellent life cycle. And I agree with his comment that you should commit when tests are green. However in a central repository system with tens of thousands of tests and millions of lines of code it is impossible to expect your team to commit code that won't fail tests on opposite sides of the system.</p>
<p>I believe John must be working with a system like Git which allows you to perform local commits where you can safely commit after passing the tests you are actually working on, but don't have to worry that the system hasn't been broken somewhere else until you are ready to push all of those local commits to a central repository.</p>