<story><title>Scrum is fragile, not Agile</title><url>http://www.dennisweyland.net/blog/?p=43</url></story><parent_chain><item><author>yibg</author><text>The best place I&amp;#x27;ve worked at as a developer essentially had no process. It&amp;#x27;s also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role).&lt;p&gt;Essentially the &amp;quot;process&amp;quot; was:&lt;p&gt;- Someone gets an idea to do something, e.g. PMs wants to add a feature.&lt;p&gt;- The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies).&lt;p&gt;- Get a very rough estimate from developer. Are we talking a few days, a few weeks or a few months?&lt;p&gt;- Manager, PM and other teams get together to figure out priorities, schedules and who&amp;#x27;s likely to be working on it.&lt;p&gt;- Based on some discussions, areas of expertise etc, some number of devs gets assigned to work on this feature.&lt;p&gt;From here the devs know what they&amp;#x27;re trying to accomplish, what the constraints are and who to go to for questions (PM, design etc). They also know who else from other teams they&amp;#x27;re collaborating with and they just figure out amongst themselves how to get things done. They&amp;#x27;ll keep their managers and the PM updated on progress and any blockers.&lt;p&gt;Every once in a while manager etc have to step in. For example if some big that was previous unknown came up, there is a big risk, priorities need to be adjusted etc. But for the most part things just worked really smoothly.&lt;p&gt;Sometimes we need to give estimates and really hit it (legal or security issues, big marketing launch etc), but for the most part we were trusted to be doing things as quickly and efficiently as possible. So none of the commits, sprints and burn down charts BS. It&amp;#x27;s not hard to gauge develop&amp;#x27;s productivity based on output anyways. If there was something slowing the team down, we communicated the need to the manager and PM, and we worked on fixing it.&lt;p&gt;So for me, if you have good competent people that communicate well, you don&amp;#x27;t really need much process.</text></item></parent_chain><comment><author>world32</author><text>100% this. For a team of good developers this is by far the best model to get things done. SCRUM only serves to prevent a very bad team from doing even worse then they would do otherwise. However for a team of competent developers SCRUM is painfully stifling.</text></comment>
<story><title>Scrum is fragile, not Agile</title><url>http://www.dennisweyland.net/blog/?p=43</url></story><parent_chain><item><author>yibg</author><text>The best place I&amp;#x27;ve worked at as a developer essentially had no process. It&amp;#x27;s also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role).&lt;p&gt;Essentially the &amp;quot;process&amp;quot; was:&lt;p&gt;- Someone gets an idea to do something, e.g. PMs wants to add a feature.&lt;p&gt;- The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies).&lt;p&gt;- Get a very rough estimate from developer. Are we talking a few days, a few weeks or a few months?&lt;p&gt;- Manager, PM and other teams get together to figure out priorities, schedules and who&amp;#x27;s likely to be working on it.&lt;p&gt;- Based on some discussions, areas of expertise etc, some number of devs gets assigned to work on this feature.&lt;p&gt;From here the devs know what they&amp;#x27;re trying to accomplish, what the constraints are and who to go to for questions (PM, design etc). They also know who else from other teams they&amp;#x27;re collaborating with and they just figure out amongst themselves how to get things done. They&amp;#x27;ll keep their managers and the PM updated on progress and any blockers.&lt;p&gt;Every once in a while manager etc have to step in. For example if some big that was previous unknown came up, there is a big risk, priorities need to be adjusted etc. But for the most part things just worked really smoothly.&lt;p&gt;Sometimes we need to give estimates and really hit it (legal or security issues, big marketing launch etc), but for the most part we were trusted to be doing things as quickly and efficiently as possible. So none of the commits, sprints and burn down charts BS. It&amp;#x27;s not hard to gauge develop&amp;#x27;s productivity based on output anyways. If there was something slowing the team down, we communicated the need to the manager and PM, and we worked on fixing it.&lt;p&gt;So for me, if you have good competent people that communicate well, you don&amp;#x27;t really need much process.</text></item></parent_chain><comment><author>jsiepkes</author><text>I think the above can simply be summarised as &amp;quot;real managing and communication&amp;quot;.&lt;p&gt;As opposed to trying to create a couple of metrics because you don&amp;#x27;t really understand what people around you are doing.</text></comment>