Please create an account to participate in the Slashdot moderation system


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Well, it's about time... (Score 1) 299

Where I worked for, our rule was: We deliver on time. We deliver major features for the iteration. Others are negotiable and can be dropped or shifted to the next. This kind of strategy allowed us to develop projects of 18-20 iterations of 3 weeks each and be major feature complete and stable at the end while having delivered working code every 3 weeks to the client so they could start seeing progress and testing and writing manuals and so forth.

On time delivery of an iteration (and repeatedly doing so) gives a customer confidence in your ability. Do this a few times then if you hit a big snag, you've got some cred in the client bank and can negotiate for a feature shift or a partial implementation in an iteration.

When you don't deliver software frequently and regularly, you can get to the end of the project and the customer can shelve the excellently functioning product for some trivial reason (I have seen it happen - insane, but customers make choices like that). Deliver early and often and the customer's issues get identified early (good communication also required) and handled.

Comment Re: Be honest (Score 1) 299

Our approach to that same problem would be:

You have a story that looks like 20 story points but your average velocity for the team is 13. We need to either have a slightly longer sprint (say a third week which should yield about an additional 7 points based on your 13 over 2 weeks or we need to add some manpower to increase our velocity. If those aren't feasible, then we should create two substories that each describe a portion of the work and then work on one in one iteration and one in the next.

You can't be religious about every assertion made in theoretical models of how to apply something. We built (ported) a huge system from one OS to another (N-tier, multiple host types, complex interactions within a software stack on a host and across between hosts) and of course there were some big stories at the start. So we broke them down.

We also knew that in the early sprints, until enough things were together, we couldn't do much functional testing (too many bits needed for anything to work). So we set the testing expectation moderately in the early sprints with more weight on that as enough of the structure came together to allow functional testing.

Seriously, it sounds like you guys are too rigid and too unimaginative by an order of magnitude.

Comment Re: Be honest (Score 1) 299

Not accurate. Management usually has broken out content by major features and knows roughly how many sprints will be needed. It is quite possible to use Agile and have a view to the future, it just isn't set in stone and inflexible.

It sound like most Agile detractors (or detractors of any tool or technology) have had issues with them being put in place in a very inflexible way.

Flexibility (just enough process to be useful, not enough to be cumbersome) is generally the best approach. It's not always a clear point and it sometimes needs to be dynamic. What is known though is that if you try to treat any technology or methodology like a religion (zealotry and can't get enough), bad outcomes ensue.

Comment Re:Be honest (Score 1) 299

Because you are enamoured of process (obviously or these guys wouldn't be employed) and have picked expensive tools, you get down on the method as if it is responsible for those choices....

We used Rally (Rallye?) and it worked very well for us and I don't think it was extortionate in costs.

I've seen a lot of waterfall projects die under the weight of tools and management ideas (too terrible to be methodologies). Same with other ideas like XP Programming (always doing pair work is insane for experienced teams but having that as an option is not).

You can always mis-apply a technology or conceptual approach poorly enough to kill a project.

Comment Re: Be honest (Score 1) 299

If you don't understand the requirements well enough to create broad users stories for features (to be refined and broken down further into smaller subordinate user stories in the iterations where those featurs are worked on), you certainly don't know enough to estimate them and you'll never be able to tell a client or funding source how much the work is going to cost (even broadly).

User stories can be as big a mire as you choose. When we used Agile on a $1M+ contract, we delivered in something like 18 sprints (the last ones were bug killing sprints) and the major items sought were delivered. Lots of 'nice to do' were too, but not all. We only ever spent about one afternoon doing sprint planning (for a team of about 6 at our end and another few overseas) for any sprint (there was preplanning for major features by sprint but we'd have to develop the subordinate user stories at the start of each sprint and put our estimates in).

The project was very successful.

The way a manager of mine once put it: You need process, but just enough. Too much and you die under the weight of it, too little and you get lost in the bushes with no idea when you'll finish or if you'll finish. That applies to any methodology: Waterfall, Objectory, Rational, Agile, etc.

Comment Re:The real problem (Score 1) 299

Mostly not.

For instance, Ottawa was having a train tunnel put through downtown with a limestone geology. The company did test drills all along. Then they agreed to a fixed top end cost (the City forced that as they knew this could go badly). Along the way, sinkholes, collapses, and the predictably bad geology making things tough on the contractor.

Most of these big projects either are so overpriced to begin with to cope with the massive uncertainties or they end up being so late and overbudget it isn't funny.

The thing about the software world is in many cases, if you told the customer actually how much the thing the customer wants done and done right would cost, they'd give up at the start.

Once they are $600K into a project, another $50K here or there (adding up possibly to another $200 or more) is absorbed with ill grace but follows the doctrine of sunk costs and not wanting to lose that investment so sending more money down the hole....

Comment Re:Furthermore (Score 1) 299

One of the reasons clients come to software companies is because they DO NOT understand software. Thus, they want things that they would ask for in other business areas or engineering areas where concrete schedules and tasks (such as building buildings) are not particularly new.

Educating your customer is difficult but having done so, you reap some significant rewards. Also having an uneducated customer can sometimes be worse for your team than no customer at all (I've been on the sorts of projects that broke project teams and lead to significant talent outflow).

Comment Re:Well, it's about time... (Score 1) 299

Accountability can kind of be built into Agile development by the way in which features for sprints are assigned and then results and velocity are tracked at the granular level. Of course, this depends on the how the Agile is attempted. I've seen it done in ways that didn't couple the product closely to the business requirements leading to wasted effort and inefficiency too.

Comment Re:Be honest (Score 1) 299

Well, I agree with days, and maybe weeks, but likely never months. Generally in my experience, if you can't estimate a thing in days or a few weeks, you haven't broken it down enough and don't understand it well enough. Plus shaving time to make tight bids or to satisfy management is a lot harder when you are working in terms of weeks because a week can be a lot to lose.

The problem most times with estimates for truly new types of work (like some I was involved in during the mid nineties on mobile computing for our federal police) was that there are a lot of technical unknowns and some may actually be insoluble or very lengthy to address. That can blow those very low granularity estimates all to heck. I think that project was months late and finished $200K or more over budget on an $800K or $1.2M project (I forget now exactly).

On the other hand, I've been on projects where we did a $46K technical investigation/requirements development assistance first on a $250K project after and totally de-risked the thing from a technical perspective as well as being sure we knew what features we wanted and what tech was best. So we built the $250K project on-budget and within about 1 week of the planned schedule (just to take out some final glitches).

I've also worked on Agile projects where they estimated by sprint and the only larger scale planning was feature planning per sprint. Of course, that was for a product company, not a contracting company - they have very different project planning requirements in my experience due to how they get their funding (customers won by bid versus from corporate leadership investing in a new product).

The problem with Agile and the world of big companies is that most accounting departments and management techniques and de-risking analysis wants definitive progress indicators and deadlines for market and costs for funds allocation in accounting ahead of when Agile can provide these things. Many managers and accountants still love the fiction inherent in waterfall project planning. Our Agile work did deliver excellent product in what I think of as minimum time (my opinion) but it gave many of the waterfall lovers apoplexy and dealing with higher level management and accounting apoplexy isn't always a simple thing for project technical managers/leaders.

Slashdot Top Deals

Anything free is worth what you pay for it.