|
I've worked with more development processes than I care to remember, and at this point my conclusion is that none of that matters. It's people that decide whether a project succeeds or fails - process has little to do with it.
|
|
|
|
|
Yep,100% correct.+5
Nothing is Impossible for Willing Heart.
|
|
|
|
|
I agree. As soon as a process is created, the universe (as Rick Cook said about programming, but it applies here as well) brings forth a bigger idiot to make the process frustrating and ineffective.
|
|
|
|
|
|
I've been doing this more than a quarter-century now. I'm continually surprised by manager-types not seeing the correlation between hiring smarter people and getting better results.
While the methodology certainly helps, I agree with Nemanja's point.
The truth is, on anything above minor complexity, every corner case can't be thought of beforehand. Also, taking X amount of time (typically measured in weeks if not months) to define every last requirement is a recipe for failure; by the time those documents are created, the business needs have changed.
To me, that's the big strengths of agile; you have a goal, build the application toward that, and as you discover weird cases, you raise and address them. As the business needs change, well, it's just software; hopefully your design allows for some not-too-bad rework.
|
|
|
|
|
I used SCRUM and I'm currently using KANBAN.
I really like using them, although we can debate if they can effectively be applied in a fixed-time/fixed-budget developments... but this is another issue.
Using them makes the projects more successful, without any doubt.
The two main reasons I identify from the field are: Visibility and Perception.
Visibility avoids surprises.
At all times everybody knows what's going on. If there are impediments or if someone is lazy or slow or whatever else influences the estimation, it will clearly show right away.
This lets us act way ahead preventing or in the worst case expect trouble.
Perception is something that is also related to visibility.
If you actually only know that you're late near the end, your perception of delay is worse than if you already knew way before. Even if the end result is the sometimes the same, with better visibility we're able to better manage expectations.
Everybody will know that there's a problem, everybody will be able to contribute to a solution and most of all, all this will be done way ahead of disaster.
So at the end, software development is as it has always been, unpredictable.
There's no way around this. It can be greatly improved with experience and bigger safety margins but if you're stepping in a new technology or just assembled a new team, there's no methodology that will assure you 100% on-time success.
Agile methodologies will basically improve the project visibility, improving the perception of delay.
|
|
|
|
|
AlexCode wrote: Agile methodologies will basically improve the project visibility, improving the perception of delay.
Agreed. This, along with with the ability to clearly identify the cost of spec changes to all stakeholders, have been the top two benefits of the agile process in our company.
/ravi
|
|
|
|
|
So far I haven't been working on a project that use any agile methodology as envisioned by its creators.
We had a stint in Extreme programming (is this correct choice of words? ), but reigning project manager wasn't up to it and it ended in several burst's of rage and quarreling.
Also we started some projects as agile, but they ended up in who knows what direction... lack of discipline and lame project management are to blame (I strongly believe so).
In current team, most of the time we work by principle of iterative development, so we have no sprints, rushes, daily chats and accompanying documentation as preached by some agile standards.
From time to time we work in some bastard form between waterfall and iterative approach (big picture is purely waterfall, but on smaller scale progress between steps is mostly iterative).
Mislim, dakle jeo sam.
|
|
|
|
|
I would say that the main contributor to out less successful projects were because of promises that were made by our project managers or marketeers after the given correct inputs from the product owners and more specifically the disregard of the inputs given by the product owners and the promise to deliver something in half the time. It has nothing to do with agile.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
