What's new
Fantasy Football - Footballguys Forums

Welcome to Our Forums. Once you've registered and logged in, you're primed to talk football, among other topics, with the sharpest and most experienced fantasy players on the internet.

Obamacare: Obama just straight up lied to you, in your face (3 Viewers)

Statorama said:
I feel for ya Foos, I really do. I manage the large dollar projects for the bank division I work for, and I know all too well about sponsor's "moving the goal posts" mid-project or large scale "scope creep" after the requirements have been approved and signed off on. Combine that with the inevitable "yeah, I know the requirement says that, but what I really meant was this" and it had to have been an impossible situation for you guys.
Foosball God said:
JZilla said:
It's really no different than paying somebody to build you a house. If you select a bad builder then I guess it's your fault when they build your house wrong. If you ask for a ladder to the moon and they tell you no problem, they can do that, then I guess it's your fault for asking. :shrug:
Except that you tell the builder they must build the house by a certain date and you'll have an architect deliver the blueprints. But then the architect doesn't deliver the blueprints and you instead have the builder draw the plans while they are trying to build the house. And when the builder tells you that certain things aren't going to be possible and still allow for the building inspectors to come in and check the house before you live in it, you tell the builder to build it anyway.

So yeah, it's pretty much exactly like your example.
It's nice to blame the customer but honestly nobody ever wants to hear it. :cry:

This contract wasn't properly managed. Neither were either of yours. The contractor's failure as well. I'm not surprised you righties don't know how business works. You don't even know how reproductive organs work.

 
Last edited by a moderator:
otello said:
Some key testing of the system did not take place until the week before launch, according to this person. As late as Sept. 26, there had been no tests to determine whether a consumer could complete the process from beginning to end: create an account, determine eligibility for federal subsidies and sign up for a health insurance plan, according to two sources familiar with the project.
This is dumbfounding. The CGI project lead must have been (rightfully) ####ting his pants before the debut of this thing. 5 days to test this kind of system - I have no words.


Foosball God said:
Except that you tell the builder they must build the house by a certain date and you'll have an architect deliver the blueprints. But then the architect doesn't deliver the blueprints and you instead have the builder draw the plans while they are trying to build the house. And when the builder tells you that certain things aren't going to be possible and still allow for the building inspectors to come in and check the house before you live in it, you tell the builder to build it anyway.
Welcome to the world of govt. contracting. I've certainly had this happen a time or two to me, but luckily never on anything that is anywhere close to the publicity of this. I feel sorry for the CGI folks, to be honest.

 
otello said:
Some key testing of the system did not take place until the week before launch, according to this person. As late as Sept. 26, there had been no tests to determine whether a consumer could complete the process from beginning to end: create an account, determine eligibility for federal subsidies and sign up for a health insurance plan, according to two sources familiar with the project.
This is dumbfounding. The CGI project lead must have been (rightfully) ####ting his pants before the debut of this thing. 5 days to test this kind of system - I have no words.

Foosball God said:
Except that you tell the builder they must build the house by a certain date and you'll have an architect deliver the blueprints. But then the architect doesn't deliver the blueprints and you instead have the builder draw the plans while they are trying to build the house. And when the builder tells you that certain things aren't going to be possible and still allow for the building inspectors to come in and check the house before you live in it, you tell the builder to build it anyway.
Welcome to the world of govt. contracting. I've certainly had this happen a time or two to me, but luckily never on anything that is anywhere close to the publicity of this. I feel sorry for the CGI folks, to be honest.
I'm sure the CGI folks are not sweating it, they got a nice payday. You get a payday like that and you'll let the client screw up the project as much as they want.

 
JZilla said:
This thread is unbearable of course, but trust me, the technical issues are entirely the company's fault. In this world the government is the paying customer, nothing more. Your job as the contractor is to deliver. If the customer is unreasonable, guess what, they're ALL unreasonable. Your job is to work with that and deliver.

But blame away, the gov't probably (clearly) did do a crummy job in the selection process but once that's done all they do is set requirements.
And in the few projects I have done with the government, this seems to be VERY hard for them. We had an 18 month project with them....at the 17 month mark we still didn't have about 10% of the requirements solidified. I'm confident this company ran into very similar problems with something this high profile. We never took another contract with them after our first was over.

 
Last edited by a moderator:
Cronyism as its best.

In an interview with CNN, Johnson said the federal government is increasingly relying on a shrinking list of preferred contractors for its technology work in a process that is producing lackluster outcomes.

"There's been a consolidation of incumbent vendors and they've gotten lazy as a result," Johnson told CNN. "They haven't kept up with the market."
A few days before launch... :wall:

On Tuesday, the Washington Post reported that a trial run of Healthcare.gov days before its launch crashed the site with a just a few hundred users online.
Any estimates on what this "tech surge" will cost? How many hundreds of millions?

Like he did with the Gulf oil spill, Obama has brought in outside experts in a move labeled a "tech surge" to try to assist in fixing the website problems.
Clay Johnson, who served as a Presidential Innovation Fellow beginning in August 2012, wrote in a blog post on October 7 that signs of flaws on Healthcare.gov were apparent from the day it went online, including the use of placeholder text in the site's code.

:

"The contractors who made this website were at best sloppy, and at worst unqualified for the job," Johnson wrote.

:

"Healthcare.gov got this way not because of incompetence or sloppiness of an individual vendor, but because of a deeply engrained and malignant cancer that's eating away at the federal government's ability to provide effective online services," he wrote.
"The problem here isn't just the result of bad programming," he wrote. "It's the result of bad systems and bad architecture from the get-go. When you try and build the world's biggest shopping mall and the only place you can buy your support beams from is a balsa-wood mill, your building is going to collapse."
:lmao:
 
Last edited by a moderator:
Leave it to the Republicans to botch the roll-out of a Democrat's Hindenberg. All they had to do was get their popcorn ready but they couldn't even do that right.

 
DrJ said:
JZilla said:
DrJ said:
JZilla said:
This thread is unbearable of course, but trust me, the technical issues are entirely the company's fault. In this world the government is the paying customer, nothing more. Your job as the contractor is to deliver. If the customer is unreasonable, guess what, they're ALL unreasonable. Your job is to work with that and deliver.

But blame away, the gov't probably (clearly) did do a crummy job in the selection process but once that's done all they do is set requirements.
How do we know the requirements weren't met? It apparently does all of the things it's supposed to do - if you try hard enough and tolerate enough errors. We could actually call the website functional depending on how you want to define it.
The contractor's job is to manage the customer's requirements. You can't get a bad requirement. If you do, it's your fault. If the customer asks you for something you can't produce, you have to go back to them with a no, and here's why, and here's what we can do instead.

That's what they pay for and cousin they pay a lot.
Obviously you can get a bad requirement. Whose fault that is would depend on who made the error.
That's why Agile is the key ingredient here. You get to these moments of truth much faster.

My company has built some pretty important member websites across the country and Agile is the only way to make it work. The sprints may become the Bataan Death Sprint - but you get done and everyone agrees to where you are at and you know things work before you move on to the next set of goals. You need a hell of a scrummaster and PM of course and a customer who is involved every single day - and the important ingredient are developers that can listen, work quickly, ask salient questions and hold each others work to the fire and not accept crap.

The killer on these large projects are the testing - especially the scalability tests, building effective test scripts takes a lot of work when you only see the "finished" work a few days before- it's very tough when you finally bring the individual parts together. And it is always done up against the gun. Heck the hardest part is just trying to get the customer to set the SLA's to begin with - and on a project like this it's uncharted territory.

I'm going to be quite interested to see the choices made here - the technology choices for me will be a key to understand where they dug themselves a hole. In the end there are plenty of member portal patterns out there to copy and it should have been a matter of scalability if you ask me. Depending on the SLA's that may have been the real scary part for the government in facing the actual amount of nodes needed to run this and just having their mind blown.
Yeah...I work in an agile environment today....it sucks especially for large projects that go on for months/years. It might work in an instance where you're just delivering small enhancements every few months, but where infrastructure set ups, network configurations, webserver configurations etc etc are necessary, it's a bogus methodology. Like trying to fit a square peg in a round hole.

 
DrJ said:
JZilla said:
DrJ said:
JZilla said:
This thread is unbearable of course, but trust me, the technical issues are entirely the company's fault. In this world the government is the paying customer, nothing more. Your job as the contractor is to deliver. If the customer is unreasonable, guess what, they're ALL unreasonable. Your job is to work with that and deliver.

But blame away, the gov't probably (clearly) did do a crummy job in the selection process but once that's done all they do is set requirements.
How do we know the requirements weren't met? It apparently does all of the things it's supposed to do - if you try hard enough and tolerate enough errors. We could actually call the website functional depending on how you want to define it.
The contractor's job is to manage the customer's requirements. You can't get a bad requirement. If you do, it's your fault. If the customer asks you for something you can't produce, you have to go back to them with a no, and here's why, and here's what we can do instead.

That's what they pay for and cousin they pay a lot.
Obviously you can get a bad requirement. Whose fault that is would depend on who made the error.
That's why Agile is the key ingredient here. You get to these moments of truth much faster.

My company has built some pretty important member websites across the country and Agile is the only way to make it work. The sprints may become the Bataan Death Sprint - but you get done and everyone agrees to where you are at and you know things work before you move on to the next set of goals. You need a hell of a scrummaster and PM of course and a customer who is involved every single day - and the important ingredient are developers that can listen, work quickly, ask salient questions and hold each others work to the fire and not accept crap.

The killer on these large projects are the testing - especially the scalability tests, building effective test scripts takes a lot of work when you only see the "finished" work a few days before- it's very tough when you finally bring the individual parts together. And it is always done up against the gun. Heck the hardest part is just trying to get the customer to set the SLA's to begin with - and on a project like this it's uncharted territory.

I'm going to be quite interested to see the choices made here - the technology choices for me will be a key to understand where they dug themselves a hole. In the end there are plenty of member portal patterns out there to copy and it should have been a matter of scalability if you ask me. Depending on the SLA's that may have been the real scary part for the government in facing the actual amount of nodes needed to run this and just having their mind blown.
Yeah...I work in an agile environment today....it sucks especially for large projects that go on for months/years. It might work in an instance where you're just delivering small enhancements every few months, but where infrastructure set ups, network configurations, webserver configurations etc etc are necessary, it's a bogus methodology. Like trying to fit a square peg in a round hole.
I will disagree - we use it on all projects and deliver some of the largest sites around with it(hell I'm on a scrum call now) - I've worked on some huge projects and it can work - infrastructure, networks, server configs - all are no problem in sprints. By the way - all large projects take months/years.

 
DrJ said:
JZilla said:
DrJ said:
JZilla said:
This thread is unbearable of course, but trust me, the technical issues are entirely the company's fault. In this world the government is the paying customer, nothing more. Your job as the contractor is to deliver. If the customer is unreasonable, guess what, they're ALL unreasonable. Your job is to work with that and deliver.

But blame away, the gov't probably (clearly) did do a crummy job in the selection process but once that's done all they do is set requirements.
How do we know the requirements weren't met? It apparently does all of the things it's supposed to do - if you try hard enough and tolerate enough errors. We could actually call the website functional depending on how you want to define it.
The contractor's job is to manage the customer's requirements. You can't get a bad requirement. If you do, it's your fault. If the customer asks you for something you can't produce, you have to go back to them with a no, and here's why, and here's what we can do instead.

That's what they pay for and cousin they pay a lot.
Obviously you can get a bad requirement. Whose fault that is would depend on who made the error.
That's why Agile is the key ingredient here. You get to these moments of truth much faster.

My company has built some pretty important member websites across the country and Agile is the only way to make it work. The sprints may become the Bataan Death Sprint - but you get done and everyone agrees to where you are at and you know things work before you move on to the next set of goals. You need a hell of a scrummaster and PM of course and a customer who is involved every single day - and the important ingredient are developers that can listen, work quickly, ask salient questions and hold each others work to the fire and not accept crap.

The killer on these large projects are the testing - especially the scalability tests, building effective test scripts takes a lot of work when you only see the "finished" work a few days before- it's very tough when you finally bring the individual parts together. And it is always done up against the gun. Heck the hardest part is just trying to get the customer to set the SLA's to begin with - and on a project like this it's uncharted territory.

I'm going to be quite interested to see the choices made here - the technology choices for me will be a key to understand where they dug themselves a hole. In the end there are plenty of member portal patterns out there to copy and it should have been a matter of scalability if you ask me. Depending on the SLA's that may have been the real scary part for the government in facing the actual amount of nodes needed to run this and just having their mind blown.
Yeah...I work in an agile environment today....it sucks especially for large projects that go on for months/years. It might work in an instance where you're just delivering small enhancements every few months, but where infrastructure set ups, network configurations, webserver configurations etc etc are necessary, it's a bogus methodology. Like trying to fit a square peg in a round hole.
I will disagree - we use it on all projects and deliver some of the largest sites around with it(hell I'm on a scrum call now) - I've worked on some huge projects and it can work - infrastructure, networks, server configs - all are no problem in sprints. By the way - all large projects take months/years.
Is your whole company utilizing that methodology? How long are your typical sprints and how often do you release code? How big is your company?

ETA: I shouldn't say it's a bogus methodology....I'm sure it works fine in certain sized companies. I can't fathom how it'd have worked in a project like this, working with the government though. Just don't see it happening. It relies on having your #### together and planning.....neither are strong abilities of our government.

 
Last edited by a moderator:
I like the fact that they said when they initially tested it, the site crashed. And they only had a couple hundred people signing up to test it. :lmao:

 
DrJ said:
JZilla said:
DrJ said:
JZilla said:
This thread is unbearable of course, but trust me, the technical issues are entirely the company's fault. In this world the government is the paying customer, nothing more. Your job as the contractor is to deliver. If the customer is unreasonable, guess what, they're ALL unreasonable. Your job is to work with that and deliver.

But blame away, the gov't probably (clearly) did do a crummy job in the selection process but once that's done all they do is set requirements.
How do we know the requirements weren't met? It apparently does all of the things it's supposed to do - if you try hard enough and tolerate enough errors. We could actually call the website functional depending on how you want to define it.
The contractor's job is to manage the customer's requirements. You can't get a bad requirement. If you do, it's your fault. If the customer asks you for something you can't produce, you have to go back to them with a no, and here's why, and here's what we can do instead.

That's what they pay for and cousin they pay a lot.
Obviously you can get a bad requirement. Whose fault that is would depend on who made the error.
That's why Agile is the key ingredient here. You get to these moments of truth much faster.

My company has built some pretty important member websites across the country and Agile is the only way to make it work. The sprints may become the Bataan Death Sprint - but you get done and everyone agrees to where you are at and you know things work before you move on to the next set of goals. You need a hell of a scrummaster and PM of course and a customer who is involved every single day - and the important ingredient are developers that can listen, work quickly, ask salient questions and hold each others work to the fire and not accept crap.

The killer on these large projects are the testing - especially the scalability tests, building effective test scripts takes a lot of work when you only see the "finished" work a few days before- it's very tough when you finally bring the individual parts together. And it is always done up against the gun. Heck the hardest part is just trying to get the customer to set the SLA's to begin with - and on a project like this it's uncharted territory.

I'm going to be quite interested to see the choices made here - the technology choices for me will be a key to understand where they dug themselves a hole. In the end there are plenty of member portal patterns out there to copy and it should have been a matter of scalability if you ask me. Depending on the SLA's that may have been the real scary part for the government in facing the actual amount of nodes needed to run this and just having their mind blown.
Yeah...I work in an agile environment today....it sucks especially for large projects that go on for months/years. It might work in an instance where you're just delivering small enhancements every few months, but where infrastructure set ups, network configurations, webserver configurations etc etc are necessary, it's a bogus methodology. Like trying to fit a square peg in a round hole.
I will disagree - we use it on all projects and deliver some of the largest sites around with it(hell I'm on a scrum call now) - I've worked on some huge projects and it can work - infrastructure, networks, server configs - all are no problem in sprints. By the way - all large projects take months/years.
Is your whole company utilizing that methodology? How long are your typical sprints and how often do you release code? How big is your company?

ETA: I shouldn't say it's a bogus methodology....I'm sure it works fine in certain sized companies. I can't fathom how it'd have worked in a project like this, working with the government though. Just don't see it happening. It relies on having your #### together and planning.....neither are strong abilities of our government.
On most major projects - we use it - here are the "rules" we try to follow - http://disciplinedagiledelivery.com/.

The project and the goals determine the length of sprints - some are a month. Some two weeks. It all depends. Generally you agree to find a finish line for a sprint that has something that can be delivered as working. It may not be released to the customer(or customer clients) at that moment - but a number of sprints would deliver a "final" release. It's lifecycle driven - so how often we release code falls in the lifecycle pattern and that always varies among clients/projects depending on complexity. A "release" maybe comes every quarter to 6 months - I've seen even shorter to around a month(I've rarely seen us commit to this type of schedule - but it's always under commit/over deliver). Ideally you do it so often that a "release" becomes pattern and automated - and you have fewer surprises.

I'm one who thinks it would work best in the government - it as you say requires #### being together. The government projects I've dealt with(but has been a bit) work best when they have a focus of smaller increments to bite off - in my opinion. But we provide the scrummasters/PM usually - not the client(although having a good one at the client can make all the difference)

We are a division of a very large company - but our group is made up of around 1,500 consultants all over the world. This scrum call I'm on has eastern Europe, western Europe, Brazil, India and US resources on it.

 
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.

Can't see it working as well on a massive scale with varied stakeholders.

 
This law is a compromise by Obama bc he wanted single payer but was only able to pass the GOP healthcare law Romneycare.
Stop with this. There was no compromise with the GOP. The "compromise" to get ACA passed was with other Democrats (mostly, the so-called "Blue Dog" Democrats). Make no mistake about it, if every Democrat in both houses of Congress had been willing to vote for single-payer, we'd have single-payer right now.
This is pretty much true. Are you counting Joe Lieberman as a Democrat or an independent? He was caucusing with the Dems but wasn't elected as a Dem. Without him, they never had the 60 Senate votes they needed. And I think he was opposed to single-payer.
Meh, either way. I'm just tired of the "ACA was watered down because of compromises made to the GOP" meme. It's not true. Compromises were made to garner votes, but not to garner GOP votes.
Well yeah, because each time Obama compromised, the GOP moved the goalposts.
umm. they weren t on the pitch. this was a dem game. played by dems coached by dems and officiated by dems. the repubs moved nothing. sorry

 
DrJ said:
JZilla said:
DrJ said:
JZilla said:
This thread is unbearable of course, but trust me, the technical issues are entirely the company's fault. In this world the government is the paying customer, nothing more. Your job as the contractor is to deliver. If the customer is unreasonable, guess what, they're ALL unreasonable. Your job is to work with that and deliver.

But blame away, the gov't probably (clearly) did do a crummy job in the selection process but once that's done all they do is set requirements.
How do we know the requirements weren't met? It apparently does all of the things it's supposed to do - if you try hard enough and tolerate enough errors. We could actually call the website functional depending on how you want to define it.
The contractor's job is to manage the customer's requirements. You can't get a bad requirement. If you do, it's your fault. If the customer asks you for something you can't produce, you have to go back to them with a no, and here's why, and here's what we can do instead.That's what they pay for and cousin they pay a lot.
Obviously you can get a bad requirement. Whose fault that is would depend on who made the error.
That's why Agile is the key ingredient here. You get to these moments of truth much faster.

My company has built some pretty important member websites across the country and Agile is the only way to make it work. The sprints may become the Bataan Death Sprint - but you get done and everyone agrees to where you are at and you know things work before you move on to the next set of goals. You need a hell of a scrummaster and PM of course and a customer who is involved every single day - and the important ingredient are developers that can listen, work quickly, ask salient questions and hold each others work to the fire and not accept crap.

The killer on these large projects are the testing - especially the scalability tests, building effective test scripts takes a lot of work when you only see the "finished" work a few days before- it's very tough when you finally bring the individual parts together. And it is always done up against the gun. Heck the hardest part is just trying to get the customer to set the SLA's to begin with - and on a project like this it's uncharted territory.

I'm going to be quite interested to see the choices made here - the technology choices for me will be a key to understand where they dug themselves a hole. In the end there are plenty of member portal patterns out there to copy and it should have been a matter of scalability if you ask me. Depending on the SLA's that may have been the real scary part for the government in facing the actual amount of nodes needed to run this and just having their mind blown.
Yeah...I work in an agile environment today....it sucks especially for large projects that go on for months/years. It might work in an instance where you're just delivering small enhancements every few months, but where infrastructure set ups, network configurations, webserver configurations etc etc are necessary, it's a bogus methodology. Like trying to fit a square peg in a round hole.
I will disagree - we use it on all projects and deliver some of the largest sites around with it(hell I'm on a scrum call now) - I've worked on some huge projects and it can work - infrastructure, networks, server configs - all are no problem in sprints. By the way - all large projects take months/years.
Is your whole company utilizing that methodology? How long are your typical sprints and how often do you release code? How big is your company?ETA: I shouldn't say it's a bogus methodology....I'm sure it works fine in certain sized companies. I can't fathom how it'd have worked in a project like this, working with the government though. Just don't see it happening. It relies on having your #### together and planning.....neither are strong abilities of our government.
On most major projects - we use it - here are the "rules" we try to follow - http://disciplinedagiledelivery.com/.

The project and the goals determine the length of sprints - some are a month. Some two weeks. It all depends. Generally you agree to find a finish line for a sprint that has something that can be delivered as working. It may not be released to the customer(or customer clients) at that moment - but a number of sprints would deliver a "final" release. It's lifecycle driven - so how often we release code falls in the lifecycle pattern and that always varies among clients/projects depending on complexity. A "release" maybe comes every quarter to 6 months - I've seen even shorter to around a month(I've rarely seen us commit to this type of schedule - but it's always under commit/over deliver). Ideally you do it so often that a "release" becomes pattern and automated - and you have fewer surprises.

I'm one who thinks it would work best in the government - it as you say requires #### being together. The government projects I've dealt with(but has been a bit) work best when they have a focus of smaller increments to bite off - in my opinion. But we provide the scrummasters/PM usually - not the client(although having a good one at the client can make all the difference)

We are a division of a very large company - but our group is made up of around 1,500 consultants all over the world. This scrum call I'm on has eastern Europe, western Europe, Brazil, India and US resources on it.
I realize we are probably hijacking this thread, but let's face it, this is probably the most fruitful discussion this thread will see, so I don't really care. How many test envs do you guys have to "hold" code in while waiting for deployment? I am asking these questions because most folks I talk to have a favorable opinion of agile and I'm wondering how we've screwed it up so badly. Right now it's TOUGH for us to keep those incremental changes in a place that doesn't affect another part of our application. It's my opinion that we don't have nearly the infrastructure to support the methodology, but they respond with "you don't know what you're talking about". Of course they say the same thing when I tell them what we "do" isn't really agile...not even close. I even have opinions from agile coaches that tell me what we do isn't agile.

 
Commish and Drew, good work here. Slap also had a good point about the size of the stage here, might be too big for Agile but Drew says no way.

 
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.

Can't see it working as well on a massive scale with varied stakeholders.
PM's are down, apparently.

 
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.Can't see it working as well on a massive scale with varied stakeholders.
Agreed. I utilize agile more in smaller projects and with emergency installs, given the team involvement required for agile. It's one thing to ask a hundred people for an hour of their time one day each week than to ask the same group for four hours of their time each business day for three weeks straight. Agile would also require us to have our testing staff available throughout the project which puts a strain on other projects, as well as taking operations away from production level responsibilities. UAT testing in Agile is a nightmare for our company, even though it may be a breeze for others. Each time I'm forced to invoke an Agile approach (typically due to a time crunch) it's a huge culture shock. A fully utilized Agile approach requires commitment from the top down, which our company isn't yet ready to embrace as a primary methodology.

I'd like to stress that I do prefer Agile. I'm typing on an IPad so I won't get into the reasons, but I'd be up for a discussion on it later if the conversation is still active. Overall, I feel Agile produces the "best" product at the end of the project.

 
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.

Can't see it working as well on a massive scale with varied stakeholders.
PM's are down, apparently.
Didn't mean to get in the middle of all the :hophead: with good discussion...apologies :D
No. He said it required a lot more from the PM. I was making a joke. Apparently a dumb one. :bag:

 
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.

Can't see it working as well on a massive scale with varied stakeholders.
PM's are down, apparently.
I like this discussion better to be honest.
Yup. That joke was a colossal piece of crap, apparently. And to think when I wrote it, I laughed and thought "That's pretty funny." Shows what I know.

 
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.

Can't see it working as well on a massive scale with varied stakeholders.
PM's are down, apparently.
Didn't mean to get in the middle of all the :hophead: with good discussion...apologies :D
No. He said it required a lot more from the PM. I was making a joke. Apparently a dumb one. :bag:
:lmao: Sorry GB....Missed it.

 
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.

Can't see it working as well on a massive scale with varied stakeholders.
PM's are down, apparently.
I like this discussion better to be honest.
As do I. Especially since this is the type of discussion that will lead to resolving the problems the site is facing from a bunch of random people on a fantasyfootball message board. The heart and soul of what this country is supposed to be.Schlzm

 
DrJ said:
JZilla said:
DrJ said:
JZilla said:
This thread is unbearable of course, but trust me, the technical issues are entirely the company's fault. In this world the government is the paying customer, nothing more. Your job as the contractor is to deliver. If the customer is unreasonable, guess what, they're ALL unreasonable. Your job is to work with that and deliver.

But blame away, the gov't probably (clearly) did do a crummy job in the selection process but once that's done all they do is set requirements.
How do we know the requirements weren't met? It apparently does all of the things it's supposed to do - if you try hard enough and tolerate enough errors. We could actually call the website functional depending on how you want to define it.
The contractor's job is to manage the customer's requirements. You can't get a bad requirement. If you do, it's your fault. If the customer asks you for something you can't produce, you have to go back to them with a no, and here's why, and here's what we can do instead.That's what they pay for and cousin they pay a lot.
Obviously you can get a bad requirement. Whose fault that is would depend on who made the error.
That's why Agile is the key ingredient here. You get to these moments of truth much faster.

My company has built some pretty important member websites across the country and Agile is the only way to make it work. The sprints may become the Bataan Death Sprint - but you get done and everyone agrees to where you are at and you know things work before you move on to the next set of goals. You need a hell of a scrummaster and PM of course and a customer who is involved every single day - and the important ingredient are developers that can listen, work quickly, ask salient questions and hold each others work to the fire and not accept crap.

The killer on these large projects are the testing - especially the scalability tests, building effective test scripts takes a lot of work when you only see the "finished" work a few days before- it's very tough when you finally bring the individual parts together. And it is always done up against the gun. Heck the hardest part is just trying to get the customer to set the SLA's to begin with - and on a project like this it's uncharted territory.

I'm going to be quite interested to see the choices made here - the technology choices for me will be a key to understand where they dug themselves a hole. In the end there are plenty of member portal patterns out there to copy and it should have been a matter of scalability if you ask me. Depending on the SLA's that may have been the real scary part for the government in facing the actual amount of nodes needed to run this and just having their mind blown.
Yeah...I work in an agile environment today....it sucks especially for large projects that go on for months/years. It might work in an instance where you're just delivering small enhancements every few months, but where infrastructure set ups, network configurations, webserver configurations etc etc are necessary, it's a bogus methodology. Like trying to fit a square peg in a round hole.
I will disagree - we use it on all projects and deliver some of the largest sites around with it(hell I'm on a scrum call now) - I've worked on some huge projects and it can work - infrastructure, networks, server configs - all are no problem in sprints. By the way - all large projects take months/years.
Is your whole company utilizing that methodology? How long are your typical sprints and how often do you release code? How big is your company?ETA: I shouldn't say it's a bogus methodology....I'm sure it works fine in certain sized companies. I can't fathom how it'd have worked in a project like this, working with the government though. Just don't see it happening. It relies on having your #### together and planning.....neither are strong abilities of our government.
On most major projects - we use it - here are the "rules" we try to follow - http://disciplinedagiledelivery.com/.

The project and the goals determine the length of sprints - some are a month. Some two weeks. It all depends. Generally you agree to find a finish line for a sprint that has something that can be delivered as working. It may not be released to the customer(or customer clients) at that moment - but a number of sprints would deliver a "final" release. It's lifecycle driven - so how often we release code falls in the lifecycle pattern and that always varies among clients/projects depending on complexity. A "release" maybe comes every quarter to 6 months - I've seen even shorter to around a month(I've rarely seen us commit to this type of schedule - but it's always under commit/over deliver). Ideally you do it so often that a "release" becomes pattern and automated - and you have fewer surprises.

I'm one who thinks it would work best in the government - it as you say requires #### being together. The government projects I've dealt with(but has been a bit) work best when they have a focus of smaller increments to bite off - in my opinion. But we provide the scrummasters/PM usually - not the client(although having a good one at the client can make all the difference)

We are a division of a very large company - but our group is made up of around 1,500 consultants all over the world. This scrum call I'm on has eastern Europe, western Europe, Brazil, India and US resources on it.
I realize we are probably hijacking this thread, but let's face it, this is probably the most fruitful discussion this thread will see, so I don't really care. How many test envs do you guys have to "hold" code in while waiting for deployment? I am asking these questions because most folks I talk to have a favorable opinion of agile and I'm wondering how we've screwed it up so badly. Right now it's TOUGH for us to keep those incremental changes in a place that doesn't affect another part of our application. It's my opinion that we don't have nearly the infrastructure to support the methodology, but they respond with "you don't know what you're talking about". Of course they say the same thing when I tell them what we "do" isn't really agile...not even close. I even have opinions from agile coaches that tell me what we do isn't agile.
Ideally - Dev-Integration-QA-Test-Prod - and Developers/Teams with a POC environment each.

Everything is virtualized - either in the cloud or on big iron. Environments are snapshotted and move up and done the chain depending on the situations - and sometimes there are 2 or more "Dev" environments.

 
Last edited by a moderator:
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.

Can't see it working as well on a massive scale with varied stakeholders.
PM's are down, apparently.
I like this discussion better to be honest.
As do I. Especially since this is the type of discussion that will lead to resolving the problems the site is facing from a bunch of random people on a fantasyfootball message board. The heart and soul of what this country is supposed to be.Schlzm
Probably best to just dismiss Congress and the President....the FFA has got this.

 
I prefer agile but I feel like it requires a lot more from the PM and developers....which is often very hard to obtain. Seems to work better in smaller, more connected groups.

Can't see it working as well on a massive scale with varied stakeholders.
PM's are down, apparently.
I like this discussion better to be honest.
As do I. Especially since this is the type of discussion that will lead to resolving the problems the site is facing from a bunch of random people on a fantasyfootball message board. The heart and soul of what this country is supposed to be.Schlzm
FootballDevGuys.com

 
CGI had an open ended contract. There was zero incentive to worry about costs and every incentive to let everyone have their say and delay as much as possible. If they did it wrong or not as intended, they would get paid to fix it.

 
The sad

CGI had an open ended contract. There was zero incentive to worry about costs and every incentive to let everyone have their say and delay as much as possible. If they did it wrong or not as intended, they would get paid to fix it.
Yeah because CGI wanted to make a bad impression with CMS and not get any more work.

The sad part is that if you ask what methodoligy this project is run on people would tell you Agile. It's not even close.

 
Ideally - Dev-Integration-QA-Test-Prod - and Developers/Teams with a POC environment each.
Everything is virtualized - either in the cloud or on big iron. Environments are snapshotted and move up and done the chain depending on the situations - and sometimes there are 2 or more "Dev" environments.
And do you have all the components to each env? Meaning same hardware, database sizes, amount of data, switches, firewalls, routers etc? This is what I think it takes, but our infrastructure folks whine about it costing too much money. It's a very expensive methodology to architect....they don't seem to get that. So, we have a dev, uatnext (future releases going in) uatnow (copy of prod for "troubleshooting), prod and dr. The only two envs that come close to functioning the same are uatnext and prod. I believe THAT's our problem. You're just confirming my thoughts that our infrastructure isn't close to being what it needs to be. I can't imagine how much it'd cost to get the right amt of envs up to support this process the correct way.

 
Commish - and Stat - Not sure if you have seen this

http://www.slideshare.net/agileindia/the-agile-scaling-model-asm-be-as-agile-as-you-need-to-be

It has some thoughts around large agile projects.
Oddly enough...IBM is the one who "set up" and "trained" all the people who were here when this originally was kicked off. What they did, sucks, but I'm guessing they were told to fit a square peg in a round hole as well. That's the MO of our management. The funny thing is...when new people (like me) come on board...there is no formal training so if you've never seen the process or aren't familiar with the terms you're SOL trying to "learn" our way of doing it.....I've been in this group over a year and still don't have it.

 
Ideally - Dev-Integration-QA-Test-Prod - and Developers/Teams with a POC environment each.
Everything is virtualized - either in the cloud or on big iron. Environments are snapshotted and move up and done the chain depending on the situations - and sometimes there are 2 or more "Dev" environments.
And do you have all the components to each env? Meaning same hardware, database sizes, amount of data, switches, firewalls, routers etc? This is what I think it takes, but our infrastructure folks whine about it costing too much money. It's a very expensive methodology to architect....they don't seem to get that. So, we have a dev, uatnext (future releases going in) uatnow (copy of prod for "troubleshooting), prod and dr. The only two envs that come close to functioning the same are uatnext and prod. I believe THAT's our problem. You're just confirming my thoughts that our infrastructure isn't close to being what it needs to be. I can't imagine how much it'd cost to get the right amt of envs up to support this process the correct way.
Lots of ways to reduce costs in all of these areas. We have Sandbox, DEV, QA, PRD, DR and they're all basically alike. From my perspective, they're identical but I can't vouch for what you Dev and Application guys do to ruin all of that after I hand it off. You want another environment? No problem, I can put together most of it in minutes. Identical to these. You want an exact copy of your production database attached to it as well? Alright, but that'll take another minute or two. And I'm literally the only guy managing this infrastructure for a billion dollar manufacturing firm. I don't know how you guys can have teams of people that can't get this right. :)

 
Commish - and Stat - Not sure if you have seen this

http://www.slideshare.net/agileindia/the-agile-scaling-model-asm-be-as-agile-as-you-need-to-be

It has some thoughts around large agile projects.
Oddly enough...IBM is the one who "set up" and "trained" all the people who were here when this originally was kicked off. What they did, sucks, but I'm guessing they were told to fit a square peg in a round hole as well. That's the MO of our management. The funny thing is...when new people (like me) come on board...there is no formal training so if you've never seen the process or aren't familiar with the terms you're SOL trying to "learn" our way of doing it.....I've been in this group over a year and still don't have it.
You are using RTC?

 
Commish - and Stat - Not sure if you have seen this

http://www.slideshare.net/agileindia/the-agile-scaling-model-asm-be-as-agile-as-you-need-to-be

It has some thoughts around large agile projects.
Oddly enough...IBM is the one who "set up" and "trained" all the people who were here when this originally was kicked off. What they did, sucks, but I'm guessing they were told to fit a square peg in a round hole as well. That's the MO of our management. The funny thing is...when new people (like me) come on board...there is no formal training so if you've never seen the process or aren't familiar with the terms you're SOL trying to "learn" our way of doing it.....I've been in this group over a year and still don't have it.
You are using RTC?
I know RTC as Real Time Communication and/or Real Time Clock. Not sure what RTC is in this context.

 
Ideally - Dev-Integration-QA-Test-Prod - and Developers/Teams with a POC environment each.
Everything is virtualized - either in the cloud or on big iron. Environments are snapshotted and move up and done the chain depending on the situations - and sometimes there are 2 or more "Dev" environments.
And do you have all the components to each env? Meaning same hardware, database sizes, amount of data, switches, firewalls, routers etc? This is what I think it takes, but our infrastructure folks whine about it costing too much money. It's a very expensive methodology to architect....they don't seem to get that. So, we have a dev, uatnext (future releases going in) uatnow (copy of prod for "troubleshooting), prod and dr. The only two envs that come close to functioning the same are uatnext and prod. I believe THAT's our problem. You're just confirming my thoughts that our infrastructure isn't close to being what it needs to be. I can't imagine how much it'd cost to get the right amt of envs up to support this process the correct way.
Lots of ways to reduce costs in all of these areas. We have Sandbox, DEV, QA, PRD, DR and they're all basically alike. From my perspective, they're identical but I can't vouch for what you Dev and Application guys do to ruin all of that after I hand it off. You want another environment? No problem, I can put together most of it in minutes. Identical to these. You want an exact copy of your production database attached to it as well? Alright, but that'll take another minute or two. And I'm literally the only guy managing this infrastructure for a billion dollar manufacturing firm. I don't know how you guys can have teams of people that can't get this right. :)
DrJ has this right - it should only take a few minutes(or more) to build - usually the problem we have is getting approval for another Cloud instance at places we work. But I've worked at many places that skimp - these aren't the big kids though.

As for the other components - on many of the projects that we work with some of those pieces aren't replicated until QA/Test.- some earlier depending on the situation. DB's obviously are around at Dev but a Firewall/Load Balancer is later in the equation.

The key I think is to build smaller teams around environments and technology - use services frameworks - glue and test - then have the UX guys do the magic and have testing hold them to the fire.

 
Ideally - Dev-Integration-QA-Test-Prod - and Developers/Teams with a POC environment each.
Everything is virtualized - either in the cloud or on big iron. Environments are snapshotted and move up and done the chain depending on the situations - and sometimes there are 2 or more "Dev" environments.
And do you have all the components to each env? Meaning same hardware, database sizes, amount of data, switches, firewalls, routers etc? This is what I think it takes, but our infrastructure folks whine about it costing too much money. It's a very expensive methodology to architect....they don't seem to get that. So, we have a dev, uatnext (future releases going in) uatnow (copy of prod for "troubleshooting), prod and dr. The only two envs that come close to functioning the same are uatnext and prod. I believe THAT's our problem. You're just confirming my thoughts that our infrastructure isn't close to being what it needs to be. I can't imagine how much it'd cost to get the right amt of envs up to support this process the correct way.
Lots of ways to reduce costs in all of these areas. We have Sandbox, DEV, QA, PRD, DR and they're all basically alike. From my perspective, they're identical but I can't vouch for what you Dev and Application guys do to ruin all of that after I hand it off. You want another environment? No problem, I can put together most of it in minutes. Identical to these. You want an exact copy of your production database attached to it as well? Alright, but that'll take another minute or two. And I'm literally the only guy managing this infrastructure for a billion dollar manufacturing firm. I don't know how you guys can have teams of people that can't get this right. :)
I'd think it's much easier if one had control over everything. We don't have that luxury because of federal guidelines. We aren't allowed to do our own authentication, another group does that. We aren't allowed to do our data loads either...another group does that. Seems like apples and oranges here, but glad it's simple for you. Though I'm not sure it's smart for a company to have a single person on the hook for network (routers, firewalls, switches etc), server, database, performance, app servers, web servers etc. By law we have to have different groups for all these things (separation of duties).

 
Commish - and Stat - Not sure if you have seen this

http://www.slideshare.net/agileindia/the-agile-scaling-model-asm-be-as-agile-as-you-need-to-be

It has some thoughts around large agile projects.
Oddly enough...IBM is the one who "set up" and "trained" all the people who were here when this originally was kicked off. What they did, sucks, but I'm guessing they were told to fit a square peg in a round hole as well. That's the MO of our management. The funny thing is...when new people (like me) come on board...there is no formal training so if you've never seen the process or aren't familiar with the terms you're SOL trying to "learn" our way of doing it.....I've been in this group over a year and still don't have it.
You are using RTC?
I know RTC as Real Time Communication and/or Real Time Clock. Not sure what RTC is in this context.
I will stop here - I don't want to use FAA as a commercial for what we do. But PM me and I'd be happy to point you in some directions. When you mentioned IBM "installing something" I thought you meant RTC.

Rational Team Concert - https://jazz.net/products/rational-team-concert/

Urban Code - http://www.urbancode.com/

Take a look here - whether you use these tools or not - the concepts that they help you plan around are the important take away. You can roll your own with a number of other things from free to purchase.

 
Commish - and Stat - Not sure if you have seen this

http://www.slideshare.net/agileindia/the-agile-scaling-model-asm-be-as-agile-as-you-need-to-be

It has some thoughts around large agile projects.
Oddly enough...IBM is the one who "set up" and "trained" all the people who were here when this originally was kicked off. What they did, sucks, but I'm guessing they were told to fit a square peg in a round hole as well. That's the MO of our management. The funny thing is...when new people (like me) come on board...there is no formal training so if you've never seen the process or aren't familiar with the terms you're SOL trying to "learn" our way of doing it.....I've been in this group over a year and still don't have it.
You are using RTC?
I know RTC as Real Time Communication and/or Real Time Clock. Not sure what RTC is in this context.
I will stop here - I don't want to use FAA as a commercial for what we do. But PM me and I'd be happy to point you in some directions. When you mentioned IBM "installing something" I thought you meant RTC.

Rational Team Concert - https://jazz.net/products/rational-team-concert/

Urban Code - http://www.urbancode.com/

Take a look here - whether you use these tools or not - the concepts that they help you plan around are the important take away. You can roll your own with a number of other things from free to purchase.
Oh...no, they "installed" the methodology...came and gave classes etc. The software for backlogs, epics etc is Version 1.

 
Ideally - Dev-Integration-QA-Test-Prod - and Developers/Teams with a POC environment each.
Everything is virtualized - either in the cloud or on big iron. Environments are snapshotted and move up and done the chain depending on the situations - and sometimes there are 2 or more "Dev" environments.
And do you have all the components to each env? Meaning same hardware, database sizes, amount of data, switches, firewalls, routers etc? This is what I think it takes, but our infrastructure folks whine about it costing too much money. It's a very expensive methodology to architect....they don't seem to get that. So, we have a dev, uatnext (future releases going in) uatnow (copy of prod for "troubleshooting), prod and dr. The only two envs that come close to functioning the same are uatnext and prod. I believe THAT's our problem. You're just confirming my thoughts that our infrastructure isn't close to being what it needs to be. I can't imagine how much it'd cost to get the right amt of envs up to support this process the correct way.
Lots of ways to reduce costs in all of these areas. We have Sandbox, DEV, QA, PRD, DR and they're all basically alike. From my perspective, they're identical but I can't vouch for what you Dev and Application guys do to ruin all of that after I hand it off. You want another environment? No problem, I can put together most of it in minutes. Identical to these. You want an exact copy of your production database attached to it as well? Alright, but that'll take another minute or two. And I'm literally the only guy managing this infrastructure for a billion dollar manufacturing firm. I don't know how you guys can have teams of people that can't get this right. :)
I'd think it's much easier if one had control over everything. We don't have that luxury because of federal guidelines. We aren't allowed to do our own authentication, another group does that. We aren't allowed to do our data loads either...another group does that. Seems like apples and oranges here, but glad it's simple for you. Though I'm not sure it's smart for a company to have a single person on the hook for network (routers, firewalls, switches etc), server, database, performance, app servers, web servers etc. By law we have to have different groups for all these things (separation of duties).
No, I agree it's entirely stupid, I've told them as much. Couple in the fact that I don't even like my boss/job and they're playing with fire. They're bribing me to stick around with large bonuses right now. :)

Definitely agree that it's a lot easier when you have full control over a number of areas as well. Like I said, I can't really vouch for what happens after I hand environments off. The best way to describe our environment is virtually unmanaged, and ultimately the people I hand my stuff off to aren't very good, barely understand a word I say because they're years behind on technology, and it limits how much impact what I do has on the company. Doesn't matter much that I can roll out an environment in minutes when the teams behind me aren't positioned well to take advantage of it and have to hire teams of consultants to do their jobs constantly.

 
Last edited by a moderator:
Okay, answer this question as if I am a dummy (shouldn't be hard), what is agile?

I am an accountant not a software programmer or consultant. I would love to have some idea what you guys are talking about.

 
Okay, answer this question as if I am a dummy (shouldn't be hard), what is agile?

I am an accountant not a software programmer or consultant. I would love to have some idea what you guys are talking about.
Hey dhockster - it's a "methodology" used in the IT world to manage project - it could be used elsewhere. It is a set of processes and "rules" - that hopefully help you deliver a better project/product faster. It has evolved over time and as with any IT "religion" you can get enough nuances that someone will tell you that you are no longer agile - or using something different.

Originally it was conceived as follows from the Agile Manifesto - from wikipedia

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more
Plenty of items out on the net to get you further

 
Last edited by a moderator:
Okay, answer this question as if I am a dummy (shouldn't be hard), what is agile?

I am an accountant not a software programmer or consultant. I would love to have some idea what you guys are talking about.
Hey dhockster - it's a "methodology" used in the IT world to manage project - it could be used elsewhere. It is a set of processes and "rules" - that hopefully help you deliver a better project/product faster. It has evolved over time and as with any IT "religion" you can get enough nuances that someone will tell you that you are no longer agile - or using something different.

Originally it was conceived as follows from the Agile Manifesto - from wikipedia

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more
Plenty of items out on the net to get you further
Thank you. I was getting parts of that from your discussion, but this helps a lot.

Serious question: Is the ACA project too big for anyone to implement in a somewhat efficient manner (regardless of methodology used)? Or is the government biting off more than it can chew?

 
Serious question: Is the ACA project too big for anyone to implement in a somewhat efficient manner (regardless of methodology used)? Or is the government biting off more than it can chew?

An answer to that is a tough one - I've been in the trenches too long to start throwing stones.

Based upon some of the issues I've heard with the site - in my opinion a well run agile project would never had had some of these problems. That doesn't mean it would have succeeded or failed - that is up to your team in the end. As I said before it's not like this is completely unprecedented when it comes to the pattern. There are lots of member portals deployed out there in other industries - but healthcare member portals are a familiar pattern at this point in the insurance industry. The size is a bit scary sounding- and having all the parts working well across states certainly would be an issue - but the science is there that to me says it's doable. It may not have been fun - it may have been a painful painful birth - but for the money number people are throwing around on this I'm thinking my firm could have given it a pretty good shot - and to be fair several of our competitors as well could have done this. I will say it would have required the full 3 years. Those out there in IT delivery know - in that first year you think you have it down cold that it will be a piece of cake - but in the end there are always - always heroic efforts needed to meet deadlines and budgets and to overcome hurdles. I am guessing that they really wasted a lot of time early on thinking they could catch up - and it kills you when it's time to truly test it. I've been there and done that - and it is a natural human reaction. What an Agile methodology will help with is making those daily efforts add up into something. You are constantly showing something and getting the validation that you are on the right track - and if your team is made up of competitive smart people you'll deliver daily on your part. Those days add up and bingo you have delivered a huge project.

 
Serious question: Is the ACA project too big for anyone to implement in a somewhat efficient manner (regardless of methodology used)? Or is the government biting off more than it can chew?

An answer to that is a tough one - I've been in the trenches too long to start throwing stones.

Based upon some of the issues I've heard with the site - in my opinion a well run agile project would never had had some of these problems. That doesn't mean it would have succeeded or failed - that is up to your team in the end. As I said before it's not like this is completely unprecedented when it comes to the pattern. There are lots of member portals deployed out there in other industries - but healthcare member portals are a familiar pattern at this point in the insurance industry. The size is a bit scary sounding- and having all the parts working well across states certainly would be an issue - but the science is there that to me says it's doable. It may not have been fun - it may have been a painful painful birth - but for the money number people are throwing around on this I'm thinking my firm could have given it a pretty good shot - and to be fair several of our competitors as well could have done this. I will say it would have required the full 3 years. Those out there in IT delivery know - in that first year you think you have it down cold that it will be a piece of cake - but in the end there are always - always heroic efforts needed to meet deadlines and budgets and to overcome hurdles. I am guessing that they really wasted a lot of time early on thinking they could catch up - and it kills you when it's time to truly test it. I've been there and done that - and it is a natural human reaction. What an Agile methodology will help with is making those daily efforts add up into something. You are constantly showing something and getting the validation that you are on the right track - and if your team is made up of competitive smart people you'll deliver daily on your part. Those days add up and bingo you have delivered a huge project.
Thanks, I appreciate you taking the time to answer thoughtfully.

 
Okay, answer this question as if I am a dummy (shouldn't be hard), what is agile?

I am an accountant not a software programmer or consultant. I would love to have some idea what you guys are talking about.
It's a PM approach where you do a bunch of mini "sprints" and deploy small amounts of code/application throughout a period of time instead of doing very large releases that have many changes deployed at once. If you have a project in a typcial "waterfall" methodology and you have 15 requirements to your project, you set a period of XX weeks in the release. During that time you code all the requirements and add them to the test env....near the end of the release schedule everything is tested as once and rolled out at once. In agile, you may have a sprint where you code 3 requirements, test them, then roll them out....then the following you might have 8 items, you test them and then roll them out. By the end all 15 have been deployed and tested. Make sense?

 
Serious question: Is the ACA project too big for anyone to implement in a somewhat efficient manner (regardless of methodology used)? Or is the government biting off more than it can chew?

An answer to that is a tough one - I've been in the trenches too long to start throwing stones.

Based upon some of the issues I've heard with the site - in my opinion a well run agile project would never had had some of these problems. That doesn't mean it would have succeeded or failed - that is up to your team in the end. As I said before it's not like this is completely unprecedented when it comes to the pattern. There are lots of member portals deployed out there in other industries - but healthcare member portals are a familiar pattern at this point in the insurance industry. The size is a bit scary sounding- and having all the parts working well across states certainly would be an issue - but the science is there that to me says it's doable. It may not have been fun - it may have been a painful painful birth - but for the money number people are throwing around on this I'm thinking my firm could have given it a pretty good shot - and to be fair several of our competitors as well could have done this. I will say it would have required the full 3 years. Those out there in IT delivery know - in that first year you think you have it down cold that it will be a piece of cake - but in the end there are always - always heroic efforts needed to meet deadlines and budgets and to overcome hurdles. I am guessing that they really wasted a lot of time early on thinking they could catch up - and it kills you when it's time to truly test it. I've been there and done that - and it is a natural human reaction. What an Agile methodology will help with is making those daily efforts add up into something. You are constantly showing something and getting the validation that you are on the right track - and if your team is made up of competitive smart people you'll deliver daily on your part. Those days add up and bingo you have delivered a huge project.
My experience with government projects tells me they don't operate quick enough to do agile. As I said before, you have to have your #### together. Well, politics stops a lot of that and it delays decisions. What I'd envision happening is a lot of stuff being slated for a sprint and simply getting pushed to the next sprint because it was NIGO. You'd have had to have gotten the government on board with the philosophy and I'm here to wish you good luck with that. PLUS, you'd have to have to have all the systems this new one was interacting with to buy into the philosophy as well. That's a big issue for us. We are the only app in our enterprise that subscribes to the agile methodology. The rest don't. It's incredibly difficult to plan even the simplest of changes when two groups are deploying in very different ways and are on very different pages when it comes to timeline.

 
The Commish said:
dhockster said:
Okay, answer this question as if I am a dummy (shouldn't be hard), what is agile?

I am an accountant not a software programmer or consultant. I would love to have some idea what you guys are talking about.
It's a PM approach where you do a bunch of mini "sprints" and deploy small amounts of code/application throughout a period of time instead of doing very large releases that have many changes deployed at once. If you have a project in a typcial "waterfall" methodology and you have 15 requirements to your project, you set a period of XX weeks in the release. During that time you code all the requirements and add them to the test env....near the end of the release schedule everything is tested as once and rolled out at once. In agile, you may have a sprint where you code 3 requirements, test them, then roll them out....then the following you might have 8 items, you test them and then roll them out. By the end all 15 have been deployed and tested. Make sense?
Yes, thanks for your input. Is the advantage of agile that you have a better idea of what needs correcting quicker because you test fewer things at a time and therefore there are fewer thngs that could be failing?

 
This has been a disaster, but no more than any private company doing it would have been.
Of course. Which is why it was moronic for the gov't to make assurances and deadlines (and come up with and sell an unworkable system in the first place) when everyone should have realized it was a much bigger task that required more careful planning.

 

Users who are viewing this thread

Top