Team Project Managment, how do you do it?

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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...
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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 :)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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.
d3ad1ysp0rk
Forum Donator
Posts: 1661
Joined: Mon Oct 20, 2003 8:31 pm
Location: Maine, USA

Post 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.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

So when is your brain scanning app being released Hockey? ;)
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post 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?
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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 :P
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...
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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 :)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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?
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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.
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Post 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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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. :)
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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?
Post Reply