<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on Adopting the scrum method for agile software development ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-305991/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-20T13:51:01-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[Expense Capitalization Requirements for Agile Projects]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3303223]]></link>
        <description><![CDATA[My company is transitioning from waterfall (plan driven) methods to agile/scrum methods and the same questions about capitalization are being asked.  In the past, strict rules about design artifacts completeness and approval were in place to satisfy external auditors.  Now, we say the teams determine what level of design/documentation is required so that they can understand the user stories and deliver what the product owner says customers need.I see the original post was over a year ago, but no one replied to the original question...  Is agile compatible with expense capitalization?  If not, what is the expectation for meeting the &quot;materially complete&quot; moment when capitalization can begin?]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3303223]]></guid>
        <dc:creator><![CDATA[SteveWhisenhant]]></dc:creator>
        <pubDate>Thu, 03 Jun 2010 07:50:17 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Communication]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3059169]]></link>
        <description><![CDATA[As usual, communication is (probably) the crux of the issue.Re. communications and the number of people involved. The cost is proportional to the square only if every worker has to separately communicate with every other. And, in some cases that must be done. In others, a broadcast makes it somewhat cheaper. But in general you're right...doubling the number of folks on a project more than doubles the communication costs.And unfortunately you're right about the &quot;but this way we only need one approval&quot; syndrome...ouch!I really like the idea of the strategic direction...the &quot;vision thing&quot; as Bush Sr. put it. I think that's important, regardless of any other techniques we use. That way everyone should be able to (okay, *might* be able to) see why things are aimed the way they are, and possibly make corrections when things aren't aimed where they should be. And we *must* depend on our subordinates, even to looking at them less as subordinates than as team players. I find that's a fine line to draw, but things work out best when that line is drawn/redrawn appropriately. Our developers aren't just coders, or just architects. They're problem solvers, yes?BTW, Tech Republic just notified me of your reply from 8 April (it's now 20 April).]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3059169]]></guid>
        <dc:creator><![CDATA[mjf]]></dc:creator>
        <pubDate>Mon, 20 Apr 2009 16:12:09 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Unfortunately it's both]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3052635]]></link>
        <description><![CDATA[The bad news is that it's both size and duration that make it less amenable to Agile/Scrum.  The cost of communications amongst a team is proportional to the square of the number of people involved, whereas the output of a team is proportional to the number of people.  You can use tools to put a better multiplier in front of each of those, but unfortunately the proportional relationship remains the same. If you'll forgive the folksy truism, &quot;you can't make a baby in one month by impregnating nine women&quot;, all you do is create a big problem in the future.Absolutely breaking a large project into smaller sub-projects is good practice.  Unfortunately it is also one that is often ignored.  There are all sorts of justifications for this, the &quot;but this way we only need one approval&quot; is one of the more common.I'm actually suggesting that you dispose of the main project, essentially turning it into a &quot;strategic direction&quot;, and define the sub-projects so that they have short durations and useful outputs, even if those outputs are only useful to following projects.  Empower and rely on your architect(s) to maintain the direction (and don't let them go &quot;ivory tower&quot; either - include them in small portions of the development work.  It will help them establish their credentials with the developers and provide useful informal feedback mechanisms too).  Also &quot;reuse&quot; developers from the building block sub-projects in following projects.  They get to be the &quot;experts&quot; in that team (it never hurts to stroke a developers ego, if it's justified) and increase output because they really are the experts.  I'd suggest monitoring of the sub-projects is deliverables based with only four states: &quot;none&quot;, &quot;started&quot;, &quot;good enough for other projects to start using&quot; (ie the dependency gate), and &quot;done&quot;.Thoughts?]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3052635]]></guid>
        <dc:creator><![CDATA[kenr@...]]></dc:creator>
        <pubDate>Wed, 08 Apr 2009 20:46:55 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Is it simply the size that's an issue?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3052165]]></link>
        <description><![CDATA[kenr, good insight. A few questions:o Do you think it's the size of the large project or its duration (or both) that makes it less amenable to Agile/scrum? (Size and duration are closely related, but not equivalent.)o Isn't breaking a large project into smaller sub-projects a good practice regardless of approach (agile or otherwise)?o Any thoughts on techniques for managing the &quot;main project&quot; that is composed of many agile/scrum sub-projects? An uber-scrum? ]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3052165]]></guid>
        <dc:creator><![CDATA[mjf]]></dc:creator>
        <pubDate>Wed, 08 Apr 2009 07:51:57 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Don't use Agile for large projects]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3051813]]></link>
        <description><![CDATA[Now before everyone starts flaming me, remember inside every large project that fails are a dozen small projects struggling to get out and succeed.Break up the large project into small projects and use Agile on them.A project of 6 months duration might fail, a project of 12 months duration will probably  fail, a project of 18 months has already failed and is struggling to compensate.  Unfortunately projects are to support or improve the real world, and no matter how much we'd like it to, it won't stay still.Have an architect (or architecture group) take the strategic view of the whole environment, and build the components using Agile.  Just be aware that this will probably mean that some if not all of the early projects will have no visibility to end users (being building blocks for future projects) and be prepared for the struggle to get approval for those.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3051813]]></guid>
        <dc:creator><![CDATA[kenr@...]]></dc:creator>
        <pubDate>Tue, 07 Apr 2009 15:40:14 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Good point]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3049806]]></link>
        <description><![CDATA[It is also very difficult to track time spent on Agile projects, from what I can tell, depending on how they are managed.J.Ja]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3049806]]></guid>
        <dc:creator><![CDATA[Justin James]]></dc:creator>
        <pubDate>Sat, 04 Apr 2009 12:22:13 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[More difficult to capitalize expenses for Agile projects]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3049279]]></link>
        <description><![CDATA[I'm responsible for budget reporting for large software projects for a fortune 500 company.  We do $200 million annual in strategic projects and whether or not a project manager can capitalize the expenses and thus spread the costs over subsequent years is a huge issue that is often overlooked by PMs moving to an Agile method.  If moving to Agile means that your project doesn't get funded - well - you might reconsider the move.  Have your project accountant or finance contact familiarize you with FASB SOP 98-1 and related documents before switching to Agile for large projects.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305991-3049279]]></guid>
        <dc:creator><![CDATA[adams_john73@...]]></dc:creator>
        <pubDate>Fri, 03 Apr 2009 12:29:53 -0700</pubDate>
    </item>
    </channel>
</rss>

