Healthcare.gov failed despite agile practices • Hacker News Board

Re: Healthcare.gov failed despite agile practices

#81

Post by LekkoscPiwa » Sun, Nov 03, 2013, 8:48 PM UTC

robomartin wrote: post #58

LekkoscPiwa wrote: post #56

Earlier quoted context omitted.

US has lower life expectancy than Poland. It has lower life expectancy than any of the 19 developed nations. It has life expectancy at the level of developing Eastern European nations like Poland, Slovakia, Estonia, etc. At the same time US spends the biggest percentage of its GDP on healthcare. More than Germany does, more than France doesm more than UK does, more than Japan does. And people in France and Japan live…

I am not arguing the merits or details of the ACA. That's pointless at this stage of the game. You can go argue that with someone who might be interested. I am not. What I am highlighting here is that, due to the ACA, for the first time our nation is seeing in all it's splendor how things are done in government and how ugly all of it is. Add to this the horrible NSA stuff and other issues and, well, I just can't see…

US is number 51 in life expectancy according to CIA Factbook. All the 50 countries that have higher life expectancy have public health care system. Look at it from competitiveness standpoint: your capitalistic approach to the healthcare yields worse results that public one. I mean those are facts. Now, you can obviously come up with all kinds of theories why it is not so, but ignoring this statistic just make you look like someone with a lot of fairy tales to tell. 51. Are you telling me that all those who are better have worse system? Is that right?

https://www.cia.gov/library/publications/the-world-factbook/...

Re: Healthcare.gov failed despite agile practices

#82

Post by jarrett » Sun, Nov 03, 2013, 9:14 PM UTC

phreanix wrote: post #57

YZF wrote: post #26

Earlier quoted context omitted.

But what about the technical/professional side of things? I know there's no silver bullet but those of us who have been through a few projects have a pretty good idea of what's going to work and what isn't. We can tell, well in advance, what's going to work and what isn't both in terms of the technical approach and the management process. Agree? If that is the case how do we convert that intuition into something that…

While recognizing the completely different context, I'd approach it like organized sports management/coaching. There you have disparate members with similar skillsets but different roles that as a whole contribute to one thing: winning. Trust, respect, belief in each other's abilities, and most of all, pushing HARD to accomplish a shared goal and vision. You have a captain who plays, a coach who is trusted completely…

Exactly. These types of social attributes are necessary for a software project to succeed. The problem, of course, is that you can't devise a system which will reliably organize an arbitrary group of people* into the kind of effective team you describe.

* As an example of an "arbitrary group of people," consider the set of contracted engineers, contracted managers, government employees, and insurance company personnel that had to work together on healthcare.gov. These are people who were not previously on a team together, and who cannot be expected to be of a uniformly high quality.

Re: Healthcare.gov failed despite agile practices

#83

Post by jarrett » Sun, Nov 03, 2013, 9:19 PM UTC

YZF wrote: post #26

jarrett wrote: post #17

Earlier quoted context omitted.

> figure out some way to qualify what makes good software engineering I doubt we'll ever be able to distill it to a formula. People ran successful software projects decades ago, long before any methodologies were formally described. And they have failing projects now, even when they use a supposedly good formal methodology. Instead of another alternative to waterfall, scrum, or agile, I'd propose the following ingred…

But what about the technical/professional side of things? I know there's no silver bullet but those of us who have been through a few projects have a pretty good idea of what's going to work and what isn't. We can tell, well in advance, what's going to work and what isn't both in terms of the technical approach and the management process. Agree? If that is the case how do we convert that intuition into something that…

> We can tell, well in advance, what's going to work and what isn't both in terms of the technical approach and the management process. Agree?

Yes, those of with experience can usually spot this stuff early on. But that doesn't mean we're in any position to do anything about it. Most often, software projects come pre-populated with people and institutional cultures. We don't get to pick the people and design the cultures from the ground up. At least not when we're contracting.

> If that is the case how do we convert that intuition into something that can work in the real world?

If you're building a startup that sells a product, then you hire good people and foster a healthy company culture. You're not beholden to any one outside entity, so you're not forced to import any such entity's preexisting pathologies.

If you're contracting? I think you just have to accept that projects will involve destructive people and cultures at times. Sometimes they'll cause projects to fail. In that case, the best you can hope to do is to protect yourself and your reputation.

Re: Healthcare.gov failed despite agile practices

#84

Post by memracom » Mon, Nov 04, 2013, 4:01 AM UTC

So yet another magic bullet doesn't really work. Maybe one day we will learn that it is not the process that matters but the people. Good people will work with a good process that looks a lot like agile, but if you cram that same process down the throats of a random group of developers then you are going to get random results.

The details of the methodology don't matter. If you look at what http://semat.org/ is proposing for the standard engineering methodology for developing software you will find that it IS agile, but it is not specified down to the nth detail and more importantly, it is extensible and adjustable so that any significantly sized project can build their own compliant methodology and process within the SEMAT framework. That part is so often missing, where the developers themselves discuss how to go about building the software, and management listens to them and defers to the developers because they are software engineering professionals.

Re: Healthcare.gov failed despite agile practices

#85

Post by phreanix » Sun, Nov 10, 2013, 3:46 PM UTC

jarrett wrote: post #82

phreanix wrote: post #57

Earlier quoted context omitted.

While recognizing the completely different context, I'd approach it like organized sports management/coaching. There you have disparate members with similar skillsets but different roles that as a whole contribute to one thing: winning. Trust, respect, belief in each other's abilities, and most of all, pushing HARD to accomplish a shared goal and vision. You have a captain who plays, a coach who is trusted completely…

Exactly. These types of social attributes are necessary for a software project to succeed. The problem, of course, is that you can't devise a system which will reliably organize an arbitrary group of people* into the kind of effective team you describe. * As an example of an "arbitrary group of people," consider the set of contracted engineers, contracted managers, government employees, and insurance company personne…

What if product managers were trained to be more like sports coaches? Motivation, the right game plan, and working hand in hand with other products managers? Doesn't an organization like NASA work somewhat the same way? Different teams tackling different parts of a project and ending up with a rover on Mars?