Very cool, if true

are there really any TheoryD people left out there? Surely only optimistic newbies and those long away from the coalface...

From:

Management . Bloody tons of them.

From:

The Theory D Theory P divide seems similar to a philosophical debate in my own field of management accounting. We do a lot of planning and there appears to me to be a divide between those who think the plan is the Plan to and those who think that the Plan is more of a Guideline. Those who believe in the Plan put a lot of front end effort into it and a lot of back end effort into variance analysis. Those who think take the Guideline approach put more effort into understanding the risks to the plan and working the plan so that a aspired for good outcome happens.

Personally I like a good well understood plan. It helps to have something to aim for. The work you have to do to have a plan is useful for understanding the environment. Having to explain why reality is not like the Plan is useful for understanding your trajectory but anyone who persuades themselves that the Plan is any more than a Guideline and that it will deliver itself through its own shear excellence is in for a profound disappointment.

I’m with Dwight Eisenhower. A Plan is useless, Planning essential.

From:

I totally agree that you need a plan.

It just needs to be a flexible one that can be adapted to fit changes, take into account delays, and work under a wide range of circumstances.

And it shouldn't take 50% of your total time to produce it.

From:

No, no where near 50% of your time.

You are never going to deliver the Plan exactly as written and therefore you are going to have problems. For me the important thing is understanding the plan enough to know when you have a big problem or a small problem and then having the capabilty to change what is happening so that the same overall outcome is delivered, or at least that an acceptable result is delivered.

I try to spend a lot of time reworking forecasts and trying to understand what happens to the total outcome if we change this particular part of it.

I’m talking mainly about my own experience of budgeting and financial planning here.

From:

Yeah, I think we're on the same page here.

From:

It was a really interesting article.

It helped me understand why I sometimes felt I was a bit out of place in my last job and why, in particular, I struggled with one of my managers there. I saw a lot of our relationship in the interactions of Type D managers and Type P teams.

From:

Yeah - it clarified a few things for me about the differences of approach. Knowing the different axioms which cause differences helps me understand (and work with) other people much better.

From:

If you do scrum with 2 week sprints, then planning activities take about 1 day in 10, and the plan is only guaranteed to be good for the next 10 days.

Scrum (done well) is pragmatic; that is, it is based on experience of software development; that is, it is theory P in extreme.

Edited Date: 2011-06-06 05:05 pm (UTC)

From:

yeah I'm a Scrummy/Agile git - love it! Gotta have the environment sorted - I'm currently just about bootstrapping us up into CI with Bamboo (we have all the other Atlassian gear - JIRA etc, so it seemed natural). Bit of a pain if you don't have existing build scripts, but not bad overall (says me who was writing CI software 10 years ago VB6/VSS/MSI...then were the days...)

From:

Scrum itself is Agile project management. It (rightly) says nothing about development practices besides letting the team have a high degree of autonomy, and helping them inspect and adapt. In practice though, you tend to head straight for the known agile development best practices such as CI and unit testing.

From:

yeah, I didn't make that clear in my comment - Scrum is a management technique and agnostic as to dev methodology.

From:

Apparently so are your comments (like all five versions of this one) :->

From:

Hey, repeated "that is, it is" is a tricky construct when you're in a hurry.

From:

anton-p-nym.livejournal.com

Who was it that said, "the plan is there to provide a common basis for improvisation"?*

-- Steve thinks that's a bit exaggerated, but has a lot of sense within it.

* Memory suggests it was in relation to the West German military during the Cold War, but that's suspect and beyond that I got nutthin'.

From:

"no plan survives contact with the enemy" - Google tells me it's Helmuth von Moltke

From:

He may have borrowed the idea from von Clauzwitz. It's one of the principles he discusses in his seminal work On War, which is probably the first book on Organisation Design.

He goes on to talk about the need for subordinates to be able to flex their own bit of the plan locally and to understand and enact best practise so that senior management can get on with the job of recieving and understanding new data and information and then flexing the big plan to fit the changing circumstances.

Von Moltke went on to succeed von Clauzwitz as boss of the Prussian Military academy. From memory.

Bearing in mind the stereotypes of military persons and Germans it says quite a lot for Type P's that von Moltke

From:

"the plan is there to provide a common basis for improvisation"?*

I do some improv. The guidelines on best practise certainly give us a common base to work from.

We all know ground rules. We all know what we're trying to achieve and we know that we can use these guidelines as a language in which to talk to each other whilst performing.

From:

khbrown.livejournal.com

So how far is it an 'us' vs them thing? And what do management think about you -- do developers fail to express/assert themselves properly and just say 'yes, we can do it' when they cannot?

Is it ultimately a two cultures thing? Thinking here of Knuth's The *Art* of Computer Programming, as the product of a *mathematician*

East is east, and west is west, and never the twain shall meet?

From:

To be fair, most people start off thinking that things are deterministic. How hard can it be to work out what people want, write it down, do a bit of design, estimate the effort, and implement it?

It's only after that's been done a few dozen times that people realise that the answer is "impossible." Developers tend to be as guilty as anyone when they're first starting out.

A large part of the problem is that few people anywhere actually take an interest in theory - they just want to be handed a toolkit and get on with it. So it doesn't matter if it's been shown in textbooks 300 times that development is probabilistic, most managers will never read it.

From:

andrewhickey.livejournal.com

*to make a hollow laughing sound*

I have just spent the last three weeks writing a 17,000-word test plan for a single piece of functionality, estimated test time four weeks. I never name my employer online and try to keep my work and online lives as separate as possible, but it's one you've heard of.

From:

andrewhickey.livejournal.com

Oh, and by last three weeks, I mean last three weeks including evenings and weekends...

From:

could have written the tests in that time! Can't you sell them TDD? But sounds like at least the testing is thorough?

From:

momentsmusicaux.livejournal.com

I believe in the conclusions of theory P, but in the premise of theory D.

I don't think it's probabilistic. That just sounds silly. There is stuff you want to do, and a way of making that stuff be done. If you had a perfect understanding of your requirements, then theory D would hold. It's just that reality gets in the way, and you never do, and requirements change, and so on. So deterministic in theory, but not useful to treat it as such.

From:

Except that a lot of the time people don't know what they want to do in advance. They have a vague idea, and it's not until they start using it that what they _really_ want to do is known (and then sixth months later things have changed and it's something else that needs to happen).

And, of course, working in the financial industry I've worked on projects where the regulatory requirements changed twice on me before we were done.

From:

khbrown.livejournal.com

Does Extreme Programming help here, or is it just another buzzword compliant thing?

Have there ever been any studies of how regulations, tax codes and so forth work to stimulate development? Like with accounting software: One year's version could easily be updated with new rules, but instead you have to buy a new version. Or VAT: how many hours of work were generated by a change from 17.5% to 20% and looking through code for constants or even magic numbers?

From:

XP is a type of Agile software development, and is thus one of the approaches that acknowledges that development is probabilistic. It's definitely better than waterfall :->

Software doesn't tend to be written in a rules-powered manner. Largely because that would require upfront thought, and enough time to do things sensibly, neither of which tend to occur in most software development.

From:

momentsmusicaux.livejournal.com

That's what I said -- in practice, theory D is not useful.

(I'm just too much of a pure mathematician... *everything* is deterministic at least in theory ;)

From: