Comments on: Brutal Prioritization in Agile: cut costs by NOT building the fluff http://www.rallydev.com/agileblog/2009/03/brutal-prioritization-in-agile-cut-costs-by-not-building-the-fluff/ Adopt, Scale and Succeed with Agile Development Sat, 13 Mar 2010 22:07:15 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: Six Practices to deal with assumptions, risks and priorities » David Alfaro: Scrum Costa Rica http://www.rallydev.com/agileblog/2009/03/brutal-prioritization-in-agile-cut-costs-by-not-building-the-fluff/#comment-1003 Six Practices to deal with assumptions, risks and priorities » David Alfaro: Scrum Costa Rica Wed, 08 Apr 2009 18:29:47 +0000 http://www.rallydev.com/agileblog/?p=617#comment-1003 [...] Brutal Prioritization in Agile: cut costs by NOT building the fluff This entry was posted on Wednesday, April 8th, 2009 at 12:22 pm and is filed under Meetings, TaskBoard, User Stories, estimation, product. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. [...] [...] Brutal Prioritization in Agile: cut costs by NOT building the fluff This entry was posted on Wednesday, April 8th, 2009 at 12:22 pm and is filed under Meetings, TaskBoard, User Stories, estimation, product. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. [...]

]]> By: Product Management Reader: 12Mar09 | The Productologist: Exploring the Depths of Product Management http://www.rallydev.com/agileblog/2009/03/brutal-prioritization-in-agile-cut-costs-by-not-building-the-fluff/#comment-348 Product Management Reader: 12Mar09 | The Productologist: Exploring the Depths of Product Management Thu, 12 Mar 2009 13:32:58 +0000 http://www.rallydev.com/agileblog/?p=617#comment-348 [...] Brutal Prioritization in Agile: cut costs by NOT building the fluff [Agile Blog] [...] [...] Brutal Prioritization in Agile: cut costs by NOT building the fluff [Agile Blog] [...]

]]> By: Jean Tabaka http://www.rallydev.com/agileblog/2009/03/brutal-prioritization-in-agile-cut-costs-by-not-building-the-fluff/#comment-281 Jean Tabaka Fri, 06 Mar 2009 23:45:51 +0000 http://www.rallydev.com/agileblog/?p=617#comment-281 My friend Alex liked the pig. :- ) My friend Alex liked the pig. :- )

]]> By: Ryan Martens http://www.rallydev.com/agileblog/2009/03/brutal-prioritization-in-agile-cut-costs-by-not-building-the-fluff/#comment-251 Ryan Martens Wed, 04 Mar 2009 20:53:52 +0000 http://www.rallydev.com/agileblog/?p=617#comment-251 Anders, I agree, it takes some form of business case, project charter or product vision to set the value scale or "theory." Without them, more requirements management and development will not help, it will hurt. It is a garbage in and garbage out flow. To me the discipline to "charter" the effort is key. I believe the adoption of agile tends to "pull" this discipline into the team. Jim Collins likes to show agility and discipline as a dance from "Good to Great." We see this in teams adopting agile. The first discipline tends to come in removing overhead. (See Jean's recent posts on <a href="http://www.rallydev.com/agileblog/2009/03/whats-with-all-the-agile-process-overhead-part-2/" rel="nofollow">Overhead</a>. Typically, moving from an agile beginner to an agile intermediate, <a href="http://www.rallydev.com/agileblog/2009/02/agile-cuts-costs-through-productivity-improvements/" rel="nofollow">flow to pull</a> in our words, increases the discipline in "chartering" releases. What is really cool is that teams that get to the agile intermediate level now have more "slack" time to spend talking to users, prototyping, and thus can greatly increase the accuracy of "value" scores and ranking necessary to build the 20%. They can stop guessing at needs! It becomes a snowball affect and your team is now hooked on continuous improvement in agile practices and disciplines. It is a beautiful thing. The trick to not killing the continuous improvement is not to take all the agile savings from improvements in time-to-market, quality and productivity through cuts, but to let the team "invest" some in more improvement efforts. An average software team is only spending 6% of their time working on value added tasks. Most average teams have a long way to go. Anders,
I agree, it takes some form of business case, project charter or product vision to set the value scale or “theory.” Without them, more requirements management and development will not help, it will hurt. It is a garbage in and garbage out flow. To me the discipline to “charter” the effort is key. I believe the adoption of agile tends to “pull” this discipline into the team. Jim Collins likes to show agility and discipline as a dance from “Good to Great.”

We see this in teams adopting agile. The first discipline tends to come in removing overhead. (See Jean’s recent posts on Overhead.
Typically, moving from an agile beginner to an agile intermediate, flow to pull in our words, increases the discipline in “chartering” releases.

What is really cool is that teams that get to the agile intermediate level now have more “slack” time to spend talking to users, prototyping, and thus can greatly increase the accuracy of “value” scores and ranking necessary to build the 20%. They can stop guessing at needs! It becomes a snowball affect and your team is now hooked on continuous improvement in agile practices and disciplines. It is a beautiful thing. The trick to not killing the continuous improvement is not to take all the agile savings from improvements in time-to-market, quality and productivity through cuts, but to let the team “invest” some in more improvement efforts.

An average software team is only spending 6% of their time working on value added tasks. Most average teams have a long way to go.

]]> By: Anders http://www.rallydev.com/agileblog/2009/03/brutal-prioritization-in-agile-cut-costs-by-not-building-the-fluff/#comment-245 Anders Wed, 04 Mar 2009 18:26:10 +0000 http://www.rallydev.com/agileblog/?p=617#comment-245 Sure! I agree! And the solution to the failing 80% is not better requirement specifications, more testing and QA, talented architects, or not even agile methodology. In most cases there are simply no business case. And Nicholas Carr is right: "IT doesn't matter". On the other hand "IT keeps people busy". What "agilistas" might not agree: * Cutting those 80% of functionality will also affect "agilistas" employment * In those cases IT actually matters architecture, city plans, foreseeing maintenance issues is needed as well as agile management Sure! I agree! And the solution to the failing 80% is not better requirement specifications, more testing and QA, talented architects, or not even agile methodology. In most cases there are simply no business case. And Nicholas Carr is right: “IT doesn’t matter”. On the other hand “IT keeps people busy”. What “agilistas” might not agree:
* Cutting those 80% of functionality will also affect “agilistas” employment
* In those cases IT actually matters architecture, city plans, foreseeing maintenance issues is needed as well as agile management

]]> By: Israel Gat http://www.rallydev.com/agileblog/2009/03/brutal-prioritization-in-agile-cut-costs-by-not-building-the-fluff/#comment-240 Israel Gat Wed, 04 Mar 2009 07:27:57 +0000 http://www.rallydev.com/agileblog/?p=617#comment-240 A good companion to Ryan's analysis is The Lean Startup presentation by Blank and Ries. See http://ow.ly/t8T for details. A good companion to Ryan’s analysis is The Lean Startup presentation by Blank and Ries. See http://ow.ly/t8T for details.

]]>