Comments on: Ignore what you know – Demand Results http://reliable.esymmetrix.com/development/ignore-what-you-know-demand-results People, Processes, Hardware and Software that deliver results every time, every where. Sat, 21 Nov 2009 22:23:31 -0600 http://wordpress.org/?v=2.8.6 hourly 1 By: Terrance Cohen http://reliable.esymmetrix.com/development/ignore-what-you-know-demand-results/comment-page-1#comment-611 Terrance Cohen Mon, 22 Dec 2008 22:32:22 +0000 http://reliable.esymmetrix.com/?p=60#comment-611 Another thing to consider is that something has to give. If schedule can't give, then some set of features, quality, reuse, maintenance cost, etc. must. And without adequate release valves, the pressure cooker develops cracks... and those are hard to repair. Another thing to consider is that something has to give. If schedule can’t give, then some set of features, quality, reuse, maintenance cost, etc. must. And without adequate release valves, the pressure cooker develops cracks… and those are hard to repair.

]]> By: Terrance Cohen http://reliable.esymmetrix.com/development/ignore-what-you-know-demand-results/comment-page-1#comment-610 Terrance Cohen Mon, 22 Dec 2008 22:13:22 +0000 http://reliable.esymmetrix.com/?p=60#comment-610 That's fine as long as you don't care about retaining anyone with a shred of talent. Thus this approach strikes me as highly pessimistic. (Yes, we went to college together 8-) That’s fine as long as you don’t care about retaining anyone with a shred of talent. Thus this approach strikes me as highly pessimistic.

(Yes, we went to college together 8-)

]]> By: Kendall Miller http://reliable.esymmetrix.com/development/ignore-what-you-know-demand-results/comment-page-1#comment-597 Kendall Miller Thu, 11 Dec 2008 19:44:43 +0000 http://reliable.esymmetrix.com/?p=60#comment-597 Big picture, Agile processes will tend towards this however they can still fall prey to the same problem where features or functionality are pulled from one sprint into another because they don’t look achievable. The key point I’m interested in is how knowing a lot about an area makes it easier to buy into group-think about whether a problem is solvable or not, and in what timeframe. Whatever particular development discipline you follow, in the end people are still people – so at a human level it’s about being careful when you let your past experience overrule your current role and accountability. For example, I tend to be extremely cautious around certain problems and if a team member brings me something in that area, I’m bound to believe just about any amount of time estimate because in my experience it might take that long to get the problem solved. (Take an example of a memory leak in an application or it deadlocking under stress). The problem is that my role on the team isn’t to buy into how long it could take but instead focus on how we deliver the results the business needs despite how long it could take. I’ve been shocked how many times the team achieved a positive outcome when I ignored my instincts on how long something could take and instead stuck with just delivering the results we were asked to, on the timeline we were asked to. I wish it wasn’t the case – I prefer the image of a craftsman taking the time it takes to “do it right”, and I recognize that there really is no way to know how long some things are going to take… Big picture, Agile processes will tend towards this however they can still fall prey to the same problem where features or functionality are pulled from one sprint into another because they don’t look achievable. The key point I’m interested in is how knowing a lot about an area makes it easier to buy into group-think about whether a problem is solvable or not, and in what timeframe.

Whatever particular development discipline you follow, in the end people are still people – so at a human level it’s about being careful when you let your past experience overrule your current role and accountability. For example, I tend to be extremely cautious around certain problems and if a team member brings me something in that area, I’m bound to believe just about any amount of time estimate because in my experience it might take that long to get the problem solved. (Take an example of a memory leak in an application or it deadlocking under stress). The problem is that my role on the team isn’t to buy into how long it could take but instead focus on how we deliver the results the business needs despite how long it could take.

I’ve been shocked how many times the team achieved a positive outcome when I ignored my instincts on how long something could take and instead stuck with just delivering the results we were asked to, on the timeline we were asked to. I wish it wasn’t the case – I prefer the image of a craftsman taking the time it takes to “do it right”, and I recognize that there really is no way to know how long some things are going to take…

]]> By: Steve Hand http://reliable.esymmetrix.com/development/ignore-what-you-know-demand-results/comment-page-1#comment-596 Steve Hand Thu, 11 Dec 2008 19:27:31 +0000 http://reliable.esymmetrix.com/?p=60#comment-596 Kendall, It appears that you are espousing Agile development practices. Having developer minimize the development to get to a working version and to deliver periodically afterwards can lead the goals you are outlining. Kendall,

It appears that you are espousing Agile development practices. Having developer minimize the development to get to a working version and to deliver periodically afterwards can lead the goals you are outlining.

]]>