How is work planned/done at your place?

[Dj_Jestar]

And Agile isn't what client's want *most* of the time, it is what developers want, and is what developers want clients to want. In the real world, as pointed out by many posters in this thread, that simply does not happen.

and as pointed out by many posters in this thread, it does happen.

The selective bias in your head is unreal. Nevermind that this all started with OP just asking how others do it throughout the industry, to you swanning it with "Agile never works" claptrap, to you now back peddling and saying "well, on super top secret stuff where you're only given a slither of the whole picture and will rarely ever get the chance to change anything because it's all so super secret and locked down it never works."

 

[D.P.]

D.P. is right imo, and between the rest of the comments in here, I think the whole agile vs waterfall thing has been mostly covered. Waterfall needs bang on requirements, and can suffer very badly when the requirements captured do not reflect the vision of the consumer. Good engagement and contractual flexibility is key to this.

Agile fixes this, but can suffer from scope creep and lack of direction, good project management, and stakeholder management in particular is key to preventing this. A bad or inexperienced team can quickly turn agile into ad-hoc.



This point here is really the key to deciding what method to go down. Trust. When you are working on big government or defence systems, the supplier is trusted only in a very limited extent. It is very often the case that different teams on the project are siloed from each other, and only a small number of people have oversight as to what is being made as a whole. When this is a case, sprint planning is practically impossible. D.P. mentioned a senior admiral having to sign off changes, having to have very senior military and civil service officials is very common on large projects, and again prevents pure agile working.

The final point to consider is in the awarding of contracts, if you have a tightly defined scope and detailed requirements, then it is normall easier to evaluate supplier responses to your proposal.

Great post.
I would like to highlight this part:

It is very often the case that different teams on the project are siloed from each other.

This is very true in these kinds of projects. The large project my parent company was awarded is dived between multiple different companies, each company is responsible for certain pieces of the puzzle based on their expertise and technology. The separate components have to operate as black boxes , e.g. one component awarded to one company may involve highly secure data and technology that cannot ever be shared with anyone else. There is no testing in unison - there is a detailed specification about how the components must communicate and inter-operate. All companies have to abide by the specs or the project will fail, all companies need to be able to coordinate and deliver on time. The different companies may even exist in different countries with different time zones.

the whole project has to be extremely robust to any changes in personnel, something that Agile is incredibly weak at which is why it it is often nicknamed fragile. In a small project where everyone is co-located and can scrum each day then Agile can be very effective -until one person quits and all their vital knowledge and understanding have gone. In large projects you need to be able to replace developers quickly and painlessly.

 

[D.P.]

and as pointed out by many posters in this thread, it does happen.

The selective bias in your head is unreal. Nevermind that this all started with OP just asking how others do it throughout the industry, to you swanning it with "Agile never works" claptrap, to you now back peddling and saying "well, on super top secret stuff where you're only given a slither of the whole picture and will rarely ever get the chance to change anything because it's all so super secret and locked down it never works."

Are you trolling me or just plain ignorant?

 

[Dj_Jestar]

Neither. Next.

 

[D.P.]

Neither. Next.

That wasn't a choice.


You are the one that has gone on and on about how Agile saved your marriage and cures cancer without any acceptance of the reality, which is is there are multiple PM ideologies that all have pros and cons, are all as likely to succeed fail as any other, and are all appropriate for different types of projects. That is why they all exist.

 

[Dj_Jestar]

That wasn't a choice.

Is that supposed to mean something?

You are the one that has gone on and on about how Agile saved your marriage and cures cancer without any acceptance of the reality, which is is there are multiple PM ideologies that all have pros and cons, are all as likely to succeed fail as any other, and are all appropriate for different types of projects. That is why they all exist.

Nope, you're seeing things again. I've not even used the word "Agile" except in a response to you. I've pointed out that any attempt at "nailing everything down" at the start is wasteful - you'll never nail everything down. Something you've denied at first, buy have eventually come around to agreeing with (after much chest beating and bleating about how important you think you are,) by way of changing your tune about fixed contract to iterative working.

 

[john_s]

Yes, which is exactly why Agile doesn't work - the budget and deadlines are relatively fixed, as are the specifications because the specifications were derived over a period of 10 years in this instance. After extensive testing and analyzing they may come back with new specifications and will tenure a new project. Budget is allocated annually for these kinds of things and will be adjusted based on federal budget changes, so even when a project is greenlighted it will take a few years before the money is thereto initiate the project.

Something else to consider on such projects - every single line of coded is analyzed by multiple security professionals to ascertain safety, liveness and security risks. Avery time consuming and expensive project but obviously necessary otherwise the developer could put in all sort of fun things things, like a backdoor for the Russians. Hence, testing is infrequent and occurs once the developer has signed off that the specifications are complete. The code is then burned to DVD and delivered by hand by a military personnel in a handcuffed briefcase.

You missed my point... how many senior admirals are there in the US Air Force?

 

[chroniclard]

I am about to try an Agile approach on our next project, its "only" a roughly 200 hour website system(MVC/Razor/EF) and our dev team is only 3. Should be quite interesting.

 

[mid_gen]

I am about to try an Agile approach on our next project, its "only" a roughly 200 hour website system(MVC/Razor/EF) and our dev team is only 3. Should be quite interesting.

Agile works extremely well in those situations, key thing is to make sure you have an actual end user working with the devs....if you have to have BAs involved, give them the scrum master role or something.