CMV-22B Osprey Rollout

[croakerfish]

Re: requirement buffoonery. The Cobra has, inexplicably, SAR FLPN functionality. I refuse to believe that was customer driven.

I know a Cobra guy that took part in a SAR. Maybe he got it put in there.

 

[phrogdriver]

Re: requirement buffoonery. The Cobra has, inexplicably, SAR FLPN functionality. I refuse to believe that was customer driven.

Probably because it shares mission computers with the UH-1Y.

 

[phrogdriver]

@ChuckMK23 and @phrogdriver . . . I make my living in the Agile space. You're both right and you're both wrong, I could write a paper as to why, but I'm not doing that on what's my early Friday night. Suffice it to say that Chuck has obviously had a sip or two of the Kool-Aid and knows the buzzwords, but Agile transformation is not always that easy or appropriate. Hell, it's hardly ever easy, and it's horrible when you're just doing it because some exec heard Jeff Sutherland talk about "twice the work in half the time." Writing those words was possibly one of his biggest mistakes.

For Phrog, the definition of an MVP is that you don't have to buy it. You can if you want to, but you don't have to. It's the minimum feature set which you can demo to a customer and get feedback. Then, you come back to the customer on a regular cadence as you keep adding features, to make sure that you're building what's needed NOW, not six years ago when you signed a contract. The point is that at the end of any given iteration, the customer can say "stop, this is what I need, it's good enough," and you're done.

If you want a specific example of this being applied to defense procurement, Saab built the Gripen using Scrum, and there are case studies at scrum.com, which is Jeff Sutherland's consulting company. If you want more examples of this being used in industrial applications, Google Joe Justice, who worked with Elon Musk at Tesla and is one of the leading minds on Agile hardware development as opposed to software. If you want to know more about the theory, research the Cynefin framework and pay specific attention to the difference between complicated and complex problem sets. Traditional DOD procurement assumes a complicated domain, whereas Agile is specifically geared towards complex situations. Stanley McChrystal also does well explaining complex environments in Team of Teams.

No one is buying Gripen because it doesn’t fit into anyone’s defense requirements besides the Swedes’.

I don’t disagree that you can employ different management techniques to iterate more quickly. There have been moves to make requirements capability based instead of platform based to help this along. That said, they will always have to exist. The military is a large institution and it needs discrete equipment capabilities to do its work, which turn into requirements to fill. Whether 80% of the requirement now is better than 100% in ten years is what JCIDS is supposed to help figure out.

DoD 5000 is more tailorable than people often give it credit for. It just takes PEOs with balls to use it.

 

[taxi1]

There have been moves to make requirements capability based instead of platform based to help this along. That said, they will always have to exist.

Every now and then you get a B52, a platform that has the fundamentals right and that has proven infinitely tailorable and lives forever. A good ship should be like that too.

Otherwise, we want to get inside our opponent's weapons development OODA loop, making them constantly update their requirements to counter us. Speed (of capability development) is life.

 

[nittany03]

No one is buying Gripen because it doesn’t fit into anyone’s defense requirements besides the Swedes’.

That's beside the point. I'm just observing that it's a proven use case that Agile can be used to deliver hardware and defense-related procurement. The Swedes got what they needed for their own requirements, which is a win. If export orders were supposed to be bigger, well, that's a separate product management issue.

I don’t disagree that you can employ different management techniques to iterate more quickly. There have been moves to make requirements capability based instead of platform based to help this along. That said, they will always have to exist. The military is a large institution and it needs discrete equipment capabilities to do its work, which turn into requirements to fill. Whether 80% of the requirement now is better than 100% in ten years is what JCIDS is supposed to help figure out.

There are times and places where Agile works well, and times and places where it's a dumb idea. And the same for waterfall-style project management. The time and place is when you are operating in a complex problem set, which means more is unknown or unknowable up front than not. Which means you can't know enough to reliably set down all requirements and plans up front. Instead, by operating in short iterations, and planning and re-planning incrementally, you buy down risk and use small actions in the environment to learn about the environment, then adjust accordingly.

One of the biggest myths in the world is that working MVP-style towards a product goal means that you don't plan and you don't have requirements. This is not the case. All it means is that you finalize and formalize said requirements at the latest responsible time, and have open conversations with the customer on a regular cadence, so that both sides learn together and build the right thing. The vendor can't read the customer's mind, the customer may not know what right looks like until they see it, and sometimes when they see it, they may have better ideas, either because they hadn't thought of them or because the market has changed.

The choice as to whether or not to take an Agile approach is really akin to Clausewitz's old saw that wars have to be fought according to their nature. You have to understand the situation that you're in for what it is, not what you want it to be.

 

[Griz882]

Requirements should be simple:

1. How fast.
2. How far.
3. A decent cup holder.

The rest is just the small stuff.

 

[TacticalTater]

There are two key questions at work in acquisition
1. What do you want?
2. I don't know, whatcha got?

#3 how much are you approved to spend?

 

[phrogdriver]

Requirements should be simple:

1. How fast.
2. How far.
3. A decent cup holder.

The rest is just the small stuff.

It's not that simple when you're dealing with $85M flying computers that need to talk to other flying computers securely, and have to be built to talk with equipment that doesn't exist yet. Most of the issues with today's equipment aren't about the user-level properties or capabilities of the platform.

 

[Griz882]

It's not that simple when you're dealing with $85M flying computers that need to talk to other flying computers securely, and have to be built to talk with equipment that doesn't exist yet. Most of the issues with today's equipment aren't about the user-level properties or capabilities of the platform.

I get it, really I do, just having some fun.

 

[phrogdriver]

I get it, really I do, just having some fun.

Fair enough. There are some on this board who really think things are simpler than they are, though.

 

[ChuckMK23]

“You do all this work, you spend all this money to develop it, you go to the Pentagon, the Pentagon says ‘I love that, I want to buy that,’ and we’ll get back to you in like two years on whether or not we can do it.”

— Rep. Adam Smith, the House Armed Services Committee’s top Democrat, on why he’s endorsing a new Pentagon legislative proposal designed to work around Congressional gridlock and field new technologies faster.

 

[ChuckMK23]

Today's mishap / loss of AF CV-22B out of Yokota is worth a post on this thread -

JB (AA trip-7 FO) gives a great rundown on this mishap and of some of the recent history of the V-22 with the Marine mishap out of Glamis..

Some nice plopter systems discussion...

 

[number9]

Does the Navy publish per-flight-hour incident rates? There are a ton of "those things are dangerous" posts on social media and I think people don't realize just how many hours they fly.

 

[zippy]

Does the Navy publish per-flight-hour incident rates? There are a ton of "those things are dangerous" posts on social media and I think people don't realize just how many hours they fly.

Marine Corps MV-22 had a mishap rate of 3.16/100,000hrs in a 10 year lookback as of 2022.

They get the reputation for being dangerous because they’ve killed and injured a lot of people riding in the back over the years. It’s not like the hornet community plunging one into the ground, killing one or two people. The widow maker reputation probably weighed in on how long they waited until the theaters were more developed in CENTCOM to deploy them there during combat operations.

 

[number9]

Marine Corps MV-22 had a mishap rate of 3.16/100,000hrs in a 10 year lookback as of 2022.

They get the reputation for being dangerous because they’ve killed and injured a lot of people riding in the back over the years. It’s not like the hornet community plunging one into the ground, killing one or two people. The widow maker reputation probably weighed in on how long they waited until the theaters were more developed in CENTCOM to deploy them there during combat operations.

How does that number compare to other platforms? If COVID has taught me anything, it's that Americans don't understand statistics. (I don't mean you, I mean regular people.)