IKE Double Pump

[AllAmerican75]

This description shows more about what's fucked up in shipyard maintenance than it does anything to critique Agile. If you're working in Agile, this is a time problem, not a scope problem. The idea that a "partially delivered warship" is on the table assumes that someone is going to come back to you and say "no more, you're out of money" when you've been interacting with them every one month to two weeks, showing them the latest progress, and updating them on your best estimate of when shit is going to be done.

The great fallacy of waterfall methodologies is assuming that your initial estimate is anything approaching right, when you're making it at the point of maximum ignorace. In software as in ship maintenance, you don't know what you don't know until you crack the shit open and start working. So your initial estimate of scope, time, OR cost will be at best plus or minus 33-50 percent off. Agile junks the Gantt chart in environments like this. There are too many variables that you can't hold constant, or even measure at all. Which means predictions beyond about three months are useless. So get to work, learn what's actually there, and refine your plan based on what you know now, not what you knew at the beginning or two weeks ago.

Google the Cynefin framework and its differentiation between "complicated" and "complex." Waterfall is designed for things that are complicated, like making a Swiss watch or building a building. Agile is designed for things that are complex. Software systems are complex. Politics is complex. It sounds like shipyard maintenance is complex. The weather is complex. We don't ask a weatherman what the weather is going to be like on one day 6 months from now, because we know he'd laugh in our face and say he doesn't have any way of knowing beyond some vague range.


The fact that the government sucks out loud at Agile doesn't make Agile a bad idea when it's appropriate to use it. That's like looking at the Browns' and Lions' 0-16 seasons, and drawing the conclusion that no one can ever play football. In the words of consultant Ron Jeffries, you tried baseball, and it didn't work. If you can't make Agile work in software, well, frankly you work for an organization that's fine with being mediocre. Even the medical and financial fields are looking hard at how to mesh their compliance requirements with Agile. It absolutely can be done.

I think we agree here. I meant my statement more as a critique of the way the government does business. I will say that so far, nobody has quite cracked the code on how to do Agile hardware and deal with the imposed linearities imposed in the process. For instance, you may be able to develop a GUI without having full functionality of the software behind it. I can't swap out a diesel generator without removing the piping and hull plating in the way. That all takes time and is subject to slippage.

My comments were mainly highlighting the same failures yours are. We aren't flexible with our messaging and roadmapping/scheduling. That's because there are hard statutory restrictions that prevent us from being flexible. Changes to these statutory restrictions would literally take an act of Congress. It all goes back to the money and the fact that being flexible with our scheduling makes it difficult for the bean counters to tie funding to milestones or project completion.

All of this goes back to the fact that the regulations, organization, and processes that we use within our military industrial complex is stuck in the 1980s and needs to be completely overhauled.

 

[Max the Mad Russian]

All of this goes back to the fact that the regulations, organization, and processes that we use within our military industrial complex is stuck in the 1980s and needs to be completely overhauled.

You mean the need for REAL project management, like in private civil engineering?

 

[AllAmerican75]

You mean the need for REAL project management, like in private civil engineering?

We need something. Because Congress is tight with the purse strings and demands we prove that the American taxpayer isn't getting ripped off, they have imposed regulations that do not allow for flexibility.

I really think Agile in some form or another is the future. In fact, I've spent the last year of my life trying to figure out how we do Agile and DevOps for the Navy.

 

[taxi1]

You mean the need for REAL project management, like in private civil engineering?

Not a good comparison, since the private civil engineering is about building things with well-known technologies and components, while this stuff is always bringing in something new, resulting in surprises. And surprises are extremely rarely good.

On the maintenance side, we're not even 100% sure of what we have until things get disconnected and looked at.

 

[Pags]

I'm well aware, but even in Agile, you never plan to 100 percent capacity, let alone beyond it. You leave a buffer based on demonstrated velocity that either gets eaten up by unexpected events, or the team pulls in additional work once they've met their commitment. An Agile team that's 100 percent booked is a team that's not Agile, because they can't adjust and pivot without dropping something they already projected they'd do.

Waterfall or Agile, you always always factor in risk by decreasing scope and/or increasing time.

Let's just say we work in very different fields so the methodologies are different and leave it at that. SW Dev ≠ the real world.

 

[taxi1]

Let's just say we work in very different fields so the methodologies are different and leave it at that. SW Dev ≠ the real world.

Thread drift, but additive manufacturing moves them closer together. We've found it quicker to print and test a design then it is to analyze it in an analysis code, especially for really complicated geometries. It changes the design process. Neat.

 

[ChuckMK23]

We need something. Because Congress is tight with the purse strings and demands we prove that the American taxpayer isn't getting ripped off, they have imposed regulations that do not allow for flexibility.

I really think Agile in some form or another is the future. In fact, I've spent the last year of my life trying to figure out how we do Agile and DevOps for the Navy.

Say it with me... "minimally viable product"

 

[nittany03]

Let's just say we work in very different fields so the methodologies are different and leave it at that. SW Dev ≠ the real world.

An ironic comment, as software continues to eat the “real world.” Fridges have Wi-Fi, cars update themselves via cellular connections, and I can check the temperature of the meat I’m smoking on my Traeger via my phone. Edit: Oh, and Saab uses Agile to build the Gripen.

But all that aside, whether waterfall or Agile, software or the building trades, the private sector generally views overpromising and underdelivering as a Bad Thing.

The idea that you have to plan for 100 to get your workforce to give you 90, and that if you plan for 80 you’ll only ever get 80 out of them, is dated Taylorism. Agile Principle #5: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

 

[Jim123]

The things you can use a smartphone to do were almost unimaginable not so long ago- almost unimaginable. Bill Gates talked about killer apps and the idea of using a miniature electronic gadget to book a restaurant reservation while you're driving your car and a bunch of other neat stuff.

I'm not sure he envisioned using it to check up on a bluetooth meat thermometer but who knows... I'm pretty sure somebody back in the 1990s thought it would be a viable to have wireless sensors for all kinds of things we take for granted- measuring your vital signs, your exercise, blood oxygen saturation, heating and air conditioning control, doorbell cameras... one day you're gonna go in for a medical procedure and, oh, never mind.

 

[Pags]

An ironic comment, as software continues to eat the “real world.” Fridges have Wi-Fi, cars update themselves via cellular connections, and I can check the temperature of the meat I’m smoking on my Traeger via my phone.

But all that aside, whether waterfall or Agile, software or the building trades, the private sector generally views overpromising and underdelivering as a Bad Thing.

The idea that you have to plan for 100 to get your workforce to give you 90, and that if you plan for 80 you’ll only ever get 80 out of them, is dated Taylorism. Agile Principle #5: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Dude, it's a methodology not a religion. I'm not trying to start a weiner measuring contest either, just want to say we work in different fields.

And this has nothing to do with people. It has to do with weather, airplanes, and changing priorities. No matter how much of a trusting environment I give the airplanes they're still going to do their own thing.

This one will really blow your mind: every year when I do workforce planning, on paper my teams are over 100% tasked, often 150%. But that's ok because many of the projects I'm planning to will be delayed. Having other projects on deck allows me to fill in the space between the big rocks as the schedule and priorities allow. White space for the team and resources is bad.

 

[Pags]

Thread drift, but additive manufacturing moves them closer together. We've found it quicker to print and test a design then it is to analyze it in an analysis code, especially for really complicated geometries. It changes the design process. Neat.

That's just a different way to make a prototype part.

 

[insanebikerboy]

You plan assuming that maintenance is going to work miracles on your airplanes and understand your priorities. Its better to have a 10 line sked and fly 9 of those lines then it is to have an 8 line sked and fly 8 lines.

Call me crazy, but a 100% sortie completion rate that supports a customer or give a chance to complete planned training objectives is soooooo much more effective than a 90% sortie completion rate that you now have to scramble to fix in the next days schedule.

100% completion in running a project/flight schedule/etc, causes zero downstream, second and third order effects. A 90% completion screws up all of those downstream plans.

 

[taxi1]

That's just a different way to make a prototype part.

The real gain comes when you plan to ultimately additively manufacture the part, so when you are done you are done. Not a prototype.

Prototyping the part would be analogous to prototyping an algorithm in Matlab, then implementing in C.

 

[Spekkio]

I think that all of the talk about how to find efficiencies in project management is a great discussion that's answering a different problem.

The Navy knows it takes on average x months to overhaul y class ship with a standard deviation of z weeks. From a macro scale we should just plan on the avail taking x + 2z. The odd avail that goes really long or the cases that go a month over won't move the needle... Yea a crew will bitch about being extended 3 weeks on occasion but in the scheme of things that's not the end of the world.

Instead we say x is too long so we want it to be 0.75x because setting tight deadlines is how you 'hold people accountable' and get people to work faster. Then we plan our entire ship rotation around that and when the number comes out to be x everyone is suddenly surprised about how that could possibly happen.

Finding growth work only affects the project timeline when the job is critical path. A good portion of overruns come from unsat tests that require rework.

Finding efficiencies to make the availabilities shorter will help, but I'm not entirely convinced that 0.75x doesn't become a moving target as a result.

 

[Pags]

Call me crazy, but a 100% sortie completion rate that supports a customer or give a chance to complete planned training objectives is soooooo much more effective than a 90% sortie completion rate that you now have to scramble to fix in the next days schedule.

100% completion in running a project/flight schedule/etc, causes zero downstream, second and third order effects. A 90% completion screws up all of those downstream plans.

To be clear in the examples I'm talking about I'm not talking about operational tasking. I'm use the flight sked as both an easy way to describe my thoughts to this audience and because I deal with flight skeds in flight test. But they're test skeds and there's no bad guys who need killing at the other end of the flight.

What I'm trying to say is:

1. Know your priorities
2. Know what resources you need and their status
3. Build a sked around realistic assumptions
4. Control what you can to stick to your plan
5. Face up to reality when you can no longer control things
6. Replan with new assumptions

So my in my "plan 10 be happy with 9" example I'm really saying "plan 10 be happy with 9 but need 8." Your top 8 go on the known good resources and the other two are nice to have. If they don't work out today, tomorrow, this month then you reattack. 8 keeps you on your long term plan while 10 gets you ahead to make up for the days you only get 6.

Plan as smartly as you can, manage priorities, and execute as much as much as you can. In short, speed and violence. But in a boring PM sort of way.