Page 2 of 3
Posted: Wed Apr 25, 2007 1:11 pm
by timvw
Hockey wrote:
If you don't have deadlines, your not properly setting your specs in the first phase of the SDLC. Yes Agile and XP advocate allowing feature creep or "change" but no where have I read that you should ignore deadlines. Rather the idea I got from it all was KISS. Keep problems small so estimating is accurate.
I more or less agree on this one.. What i've remembered most is the idea of 'having shorter iterations, communicating more, having all parties involved (input and feedback).. So that by the time your 'deadline' is there there is a good chance that atleast the 'core' features are there...
Last time i complained about an unrealistic deadline to a business person he simply told me to get more staff.. It didn't matter how much it would cost, he just wanted us to the job got done... because with multibillion contracts (energy sector) there is simply no 'mutual understanding' when you don't deliver in time...
Posted: Wed Apr 25, 2007 2:54 pm
by alex.barylski
timvw wrote:Hockey wrote:
If you don't have deadlines, your not properly setting your specs in the first phase of the SDLC. Yes Agile and XP advocate allowing feature creep or "change" but no where have I read that you should ignore deadlines. Rather the idea I got from it all was KISS. Keep problems small so estimating is accurate.
I more or less agree on this one.. What i've remembered most is the idea of 'having shorter iterations, communicating more, having all parties involved (input and feedback).. So that by the time your 'deadline' is there there is a good chance that atleast the 'core' features are there...
Last time i complained about an unrealistic deadline to a business person he simply told me to get more staff.. It didn't matter how much it would cost, he just wanted us to the job got done... because with multibillion contracts (energy sector) there is simply no 'mutual understanding' when you don't deliver in time...
Wow. You agree with me? I'm shocked and flattered. it's not often people see the method to my madness.
I figured when you said billion dollar budget you must have been working on a large gov't type contract. It's my understanding of hearing horror stories that in these situations it is best to hammer out most details off the hop and skip using Agile/XP, instead following a more traditional scholarly approach to software design; think NASA where mission criticality is impetus.
The reasons:
1) Deadlines are more important
2) Bottomless budgets (money is easy to spend when it's not yours)
3) High mission criticality;
Obviously NASA requires a bit more assurance than an Energy company might, but having a single system go down affecting a single business is certainly less worry than a major hydro plant failing and knocking out several thousands businesses.
I read a research paper a few years back on NASA software development. It was interesting, but the statistics were most impressive.
Don't quote me on the numbers but the difference is the point I am trying to make:
The comparison was Windows or Linux or similar.
Windows: Number of bugs / 1000 lines = 15
NASA: Number of bugs / 1000 lines = 0.0005
Like I said the stats were crazy. But the developers of that software have managed to produce a relatively solid source base. I think it said the bugs discovered were like one every 5 years or something.
You can't get that kind of accuracy following Agile/XP you need to follow a different methodology, more strict, set deadlines, specs, etc...
XP is really only for RAD scenarios where the dollar is the most important factor. Advocating good choices over quick hacks.
At least this is the impression I have been left with of Agile/XP.
p.s- this system. Is it written in PHP? Or java? I've actually consider applying at our local hydro company as I seen a job ad a while back. Think it could be neat.
Cheers

Posted: Wed Apr 25, 2007 3:45 pm
by Jenk
Once you get passed the blinkered view of "It must have a deadline" you will see why and how having a deadline is of little significance when it comes to Agile programming.
Versions are for when you baseline your project, nothing more. Like a timeline of changes.
Posted: Wed Apr 25, 2007 6:05 pm
by d3ad1ysp0rk
Hockey wrote:You can't get that kind of accuracy following Agile/XP you need to follow a different methodology, more strict, set deadlines, specs, etc...
Wrong. Accuracy ususally INCREASES with Agile methodologies.
Posted: Wed Apr 25, 2007 10:23 pm
by alex.barylski
Haha...here we go again...
Read the book "Extreme Programming explained" by Kent Beck...
He himself states, that XP or Agile are not for every one or every situation, he then draws on the anaology of mission critical type applications, such as Missle control systems, brain scanners, etc...
Because these projects have a "high criticality" there is little room for error, where as XP is a little more tolerant of bugs (in fact it invites them with it's constantly change specs - common in business world applications). In these types of projects he states, it's likely more important to invest more upfront planning than a traditional business oriented application.
Posted: Thu Apr 26, 2007 3:41 am
by Jenk
So when is your brain scanning app being released Hockey?

Posted: Thu Apr 26, 2007 4:52 am
by onion2k
Hockey wrote:If you don't have deadlines, your not properly setting your specs in the first phase of the SDLC.
What was the deadline for the bit of your application you rewrote half a dozen times?
Posted: Thu Apr 26, 2007 2:55 pm
by timvw
Hockey wrote:
Obviously NASA requires a bit more assurance than an Energy company might, but having a single system go down affecting a single business is certainly less worry than a major hydro plant failing and knocking out several thousands businesses.
Here's an article about a monitoring system in a SUEZ subsidiary that didn't detect a leak, well not in time anyway
http://www.expatica.com/actual/article. ... y_id=22358
Hockey wrote:
Like I said the stats were crazy. But the developers of that software have managed to produce a relatively solid source base. I think it said the bugs discovered were like one every 5 years or something.
You can't get that kind of accuracy following Agile/XP you need to follow a different methodology, more strict, set deadlines, specs, etc...
I don't think that there is a methodology that you can guarantee these results, what i do believe is that most methodologies are based on a couple of 'core principles'.. And in most successful project you will find that these principles where applied (although not always as religiously, but in a more pragmatic way).
Hockey wrote:
p.s- this system. Is it written in PHP? Or java? I've actually consider applying at our local hydro company as I seen a job ad a while back. Think it could be neat.
There is not really *a system*, it's more a set of services that work together (webservices, com+, ... ) Most used languages are c++, java, visual basic and c# Haven't seen applications written in php though...
Posted: Fri May 04, 2007 11:48 am
by Jenk
Apologies for the necro-post, but I have just been shown a presentation from this site:
http://scrum-master.com/ "Top Tips" By Ken Schwaber, and it quite nicely sums up the differences between Agile/SCRUM and "traditional" methodologies

Posted: Fri May 04, 2007 1:14 pm
by RobertGonzalez
Dude, that is pretty tight. I have never seen Lean Manufacturing Methodologies applied to software development. It is like the Toyota Production System meets Development. That is awesome.
/ On a side note, I come from a Toyota facility, so the concept of scrum and the application of 30 day JIT sprints in a pull system makes a ton of sense. I can't believe I hadn't seen this stuff before.
As for the issue with deadlines. How can the client expect to run their businesses when they cannot tell their customers when the business will run? I understand the concept of takt time, production lifecycles and task schedules. But in the end, when a client is buying something, they want to know when they can use it. I cannot see a client taking 'Maybe this iteration, maybe next' as a valid response. I know that the development team goes over the proposed tasks to be complete, and that the client sits with them when they do, and that the development team gives the client an answer on what can be accomplished in that iteration they will be working on. But I seriously believe that the client will, at some point, need to be able to develop an expectation of completion so they can go on running their business.
Case in point: When I took the job I am in now (early September 2006), I was given a 32 page technical specification document and was told that an announcement was going to be made company wide on this new application on January 19 2007. Yes, our team developed in cycles, but we always knew when the product had to be delivered. There was no turning back. We also learned mid-term that the customers were going to start using the application on February 15, 2007. With no exceptions. That made perfect sense to us since we knew when the completion of the first phase release was absolutely necessary. It doesn't seem that SCRUM allows for that. Or am I missing something important in it?
Posted: Fri May 04, 2007 1:45 pm
by Jenk
You only ever have one "deadline" (loose definition,) and that is the first stage; when the product has reached a stage that satisfies core criteria. I.e. the product is functional, and most importantly, you can market it.
However, this is not a deadline - this date is dictated by the thorough estimation of completion of the components/chunks and not a "I want it by next week" type deadline. Both you and the customer review the iteration schedules and agree that the (as Ken puts it) High Risk/Importance chunks will be completed. This date is (usually, there are exceptions) not fixed. It's more of a date of expectancy. Metaphor for it I guess would be a date of birth - the kid will come out when it's ready, not because the calendar says so
It's really quite difficult to explain I guess, but I'm told by my current employers that they/we have not had a deadline for a number of years (I've only been here for 2 months) and even with new customers, there is no real deadline it's just a "when it's done" kind of thing; but with a sense of urgency and importance.
Posted: Fri May 04, 2007 1:54 pm
by RobertGonzalez
I think adoption of this principle would certainly have to be enterprise wide, supported from the highest levels of management and implemented simultaneously across all departments in an organization in order to work. I only say that because the application that I am most focused on right now was launched (phase 1) on February 15. June 30 is the second phase release. September 30 is phase 3 and January 15 2008 Phase 4. These were deadlines set for us outside of my department, agreed upon by my department executive and supported by the team.
Changing that would require an enormous amount of change that would literally require the entire organizational glue (the executives, as it were) to make sure that the process does not get swayed from.
Posted: Fri May 04, 2007 2:37 pm
by Kieran Huggins
The folks at Unspace (a fantastic web/dev shop here in Toronto) did an interesting presentation a while back at a local college about rapid development, dealing with clients, etc... I remember it being very insightful.
http://unspace.ca/innovation/speak
Both Unspace and their sister company, M7 are severely smart, talented people, and their methods seem to work very well for them.
Posted: Fri May 04, 2007 3:13 pm
by Jenk
Everah wrote:I think adoption of this principle would certainly have to be enterprise wide
Not just enterprise wide, but everyone. Clients, 3rd parties, etc.

Posted: Fri May 04, 2007 3:22 pm
by timvw
Jenk wrote:Everah wrote:I think adoption of this principle would certainly have to be enterprise wide
Not just enterprise wide, but everyone. Clients, 3rd parties, etc.

So, can a project be managed in an agile way if not all participating parties (and their requirements) are 'Agile'? I would be tended to say yes, but i've got the feeling that some people preach a more 'purist' style...
Which leads us to the main question: How agile is Agile?