Hi, I was captivated by the great analysis Martin made bet. Predicted Planning and Adaptive Planning. I enjoyed the first segment of Martin's talk but had few questions/concerns about the ThoghtWork's approaches due to the following points made during the talk: 1. use of elec. tool to see the task board when the team is not co-located. Yes, it is good to know that they utilize the board but shouldn't Thoughtwork help the organization setup so that team is co-located thus eliminating the use of electronic board. I believed in each team being co-located but cross-teams can be distributed. 2. In my experience, tech people love tools. so, I often find it that team members don't like using PostIts - physical board. so, i am puzzled by his remark that teams love the physical board. 3. Pair-Programming - perhaps different activities stimulate a different part of brain, but pair-programming brings collective ownership and sharing and learning. the talk started out great but fizzled into giving me some disappointment as i ponder that he might be somewhat out of touch with the real software people. Sue
I love these types of talks. At ~00:09:20-00:10:00 he hits a very key point about the mgmt side of 'agile' being adopted by mgmt/companies and almost completely glosses over the design issues implicit in this 'methodology' - ok. sure he plugs his decade old book/paper . . . blah blah make sure you pay attention to these kinds of things as well blah . . . etc. Fuckin' great Martin. The real crux of the biscuit IS FUCKING DESIGN; and, not just DESIGN, but DESIGN FOR CHANGE. Mgmt doesn't give a fuck about design much less understanding that designing for CHANGE (a.k.a. Agile buzzword compatibility) requires discipline and commitment UPFRONT. This means having mgmt. that knows and is willing to accept and pay the toll upfront. It also requires engineers who plan on sticking around more than 12-18 mos. to realize this vision and benefit from the effects of having built a system that is adaptive and solid. Or, dare I say, agile.
Too bad they don't show the slides in a box somewhere. Anyone who knows what book Martin Fowler is referring to at 39:13? Could it be this one: Pragmatic Thinking and Learning: Refactor Your Wetware, Andy Hunt, 2008, The Pragmatic Bookshelf, ISBN 978-1-934356-05-0 ? (Reference copied from wikipedia)
It seems the sentence he almost said at the end is "If a team is doing extreme programming the same way they were doing it a year ago, then they are no longer doing extreme programming."
Extreme Programming and agile are probably from around end '90-ies to 2000-nds. Same era as the scroll mouse :-) The agile manifesto came in 2001 agilemanifesto.org/history.html
+wharup Hey Wharup, unfortunately we had a technical problem with the end of the talk... following one of our follower, the last sentence could be : "If a team is doing extreme programming the same way they were doing it a year ago, then they are no longer doing extreme programming."
+Terry Ahlander I find the "wh" pronounciation very interesting. It shows where the US american english language came from in the first place, and how much and rapidly it changed to become the world's most flexible human language.
Is adaptive planning not predictive as well? Uncertainty is inherent to projects. This is why any project plan, by default, is predictive and adaptive and must be treated as such. Plan first, adapt the plan during the course of the project when it is wise to do so.
I believe he in incorrect on the account of not being able to use both halves of the brain. 1) We use both halves of our brain when listening to music, playing music. 2) Women (so I've heard) are able to use both halves of their brains as there are more connections between the two halves in a female brain. Perhaps an argument for more women software developers?
Hi,
I was captivated by the great analysis Martin made bet. Predicted Planning and Adaptive Planning. I enjoyed the first segment of Martin's talk but had few questions/concerns about the ThoghtWork's approaches due to the following points made during the talk:
1. use of elec. tool to see the task board when the team is not co-located. Yes, it is good to know that they utilize the board but shouldn't Thoughtwork help the organization setup so that team is co-located thus eliminating the use of electronic board. I believed in each team being co-located but cross-teams can be distributed.
2. In my experience, tech people love tools. so, I often find it that team members don't like using PostIts - physical board. so, i am puzzled by his remark that teams love the physical board.
3. Pair-Programming - perhaps different activities stimulate a different part of brain, but pair-programming brings collective ownership and sharing and learning.
the talk started out great but fizzled into giving me some disappointment as i ponder that he might be somewhat out of touch with the real software people.
Sue
I love these types of talks. At ~00:09:20-00:10:00 he hits a very key point about the mgmt side of 'agile' being adopted by mgmt/companies and almost completely glosses over the design issues implicit in this 'methodology' - ok. sure he plugs his decade old book/paper . . . blah blah make sure you pay attention to these kinds of things as well blah . . . etc.
Fuckin' great Martin. The real crux of the biscuit IS FUCKING DESIGN; and, not just DESIGN, but DESIGN FOR CHANGE. Mgmt doesn't give a fuck about design much less understanding that designing for CHANGE (a.k.a. Agile buzzword compatibility) requires discipline and commitment UPFRONT. This means having mgmt. that knows and is willing to accept and pay the toll upfront. It also requires engineers who plan on sticking around more than 12-18 mos. to realize this vision and benefit from the effects of having built a system that is adaptive and solid. Or, dare I say, agile.
12:50 People are not predictable (middle finger) ;)
he really did that
🤣 🤣
Is there a second part somewhere? :(
Hwy is there no part 2?
:^)
Man, I really want it
The last part is cut out, please re-upload if possible
Too bad they don't show the slides in a box somewhere. Anyone who knows what book Martin Fowler is referring to at 39:13? Could it be this one: Pragmatic Thinking and Learning: Refactor Your Wetware, Andy Hunt, 2008, The Pragmatic Bookshelf, ISBN 978-1-934356-05-0 ? (Reference copied from wikipedia)
It is not complete. Where is the rest? Part 2 maybe?
It seems the sentence he almost said at the end is "If a team is doing extreme programming the same way they were doing it a year ago, then they are no longer doing extreme programming."
Where is the other part?
This video ends abruptly at 43 minutes. Can you please fix this?
How old is this? The picture at 40:20 has a computer with a CRT and a mouse w/o a scroll wheel.
Extreme Programming and agile are probably from around end '90-ies to 2000-nds. Same era as the scroll mouse :-) The agile manifesto came in 2001 agilemanifesto.org/history.html
No part 2? Now I'll never know what is a plastic kangaroo. :(
+Georgi Mihaylov Just google rubber duck debugging. That's my guess :)
seriously, where is the other part ?
40:15 what does he say there?
hand gesture at 12:50 does not seem to fit in the presentation
Plz. Where's the other part? ㅜ_ㅠ...
+wharup Hey Wharup, unfortunately we had a technical problem with the end of the talk... following one of our follower, the last sentence could be : "If a team is doing extreme programming the same way they were doing it a year ago, then they are no longer doing extreme programming."
+USI Events It's so unfortunate. Anyway, thank you so much for giving me the precious sentence. :-D
LOL...Martin flips the bird at 12:51
The WH sound destroyed this entire video for me...not an easy listen
+Terry Ahlander But wuh-hy?
+Terry Ahlander I find the "wh" pronounciation very interesting. It shows where the US american english language came from in the first place, and how much and rapidly it changed to become the world's most flexible human language.
Mark Marino iarNi manq st
Sebastian Schulz fas bok
@@SebastianSkadisson I can tell you, this is NOT how British English sound...
Is adaptive planning not predictive as well? Uncertainty is inherent to projects. This is why any project plan, by default, is predictive and adaptive and must be treated as such. Plan first, adapt the plan during the course of the project when it is wise to do so.
Oh holy shit! Video was cut!
+Jonas Erik Barreto yes, we know and that's a shame... sorry for that, we had a problem.
"khu-y" is how he pronounces "why"
martin is awesome at looking like he knows what he is talking about.
which he does, but agile...
Giving you the finger at 12:51
How does that end? 'If a team is doing Extreme Programming...' then? Don't upload videos that
I see what you
cool hwhip!
Hard cut at the end there. Always leave them wanting more...
Newman!
hhhhhwaiii
Huaiiii xD
I believe he in incorrect on the account of not being able to use both halves of the brain. 1) We use both halves of our brain when listening to music, playing music. 2) Women (so I've heard) are able to use both halves of their brains as there are more connections between the two halves in a female brain. Perhaps an argument for more women software developers?