I've done both longitudinal studies and statistical studies in corporate environments starting in 2004 up until the present. Indeed, technology has improved and made some things about remote work arrangements better. And you are right, that there is an objective fact that costs are saved when using distributed/remote teams. But that cost savings is more than overwhelmed by the increased costs of delayed communication, decrease in communication fidelity, and lost opportunities for communication. So when you measure productivity properly (time value of business results / time value per unit of investment), you will find that the clear winner in most cases is collocation. I also want to be clear: there are other business drivers besides just short term profit so, for example, customer satisfaction might best be served with distributed team members that are close to customers. I'm definitely not saying that all teams are better collocated... just that this particular study appears to be deeply flawed.
The methodology seems to be surveys and focus groups. As if employees will report that distributed / remote work is less effective or productive.
The only way to do this properly is to measure the waste in their processes. The farcical thing is that the report actually identifies a whole bunch of different types of waste that are caused by alleviating some of the challenges of remote work: travelling to get face time, fiddling with technology, delays in communication due to needing to schedule meetings, etc.
I've known for 20 years that distributed work environments such for the business and are great for the employees. I've worked in both collocated and distributed environments and I've actually measured (objectively) the effects of both. Business people; don't be fooled! Distributed teams usually cost more than they are worth!
Around the 90s is when software development was truly in its prime, despite the shit languages and lacking hardware.
Have you heard of the Software Crisis? It didn't magically go away in the 90's. CASE, RUP, SDLCs, CMM/I, ISO, and project management were all trying to fix the software crisis... and didn't. Based on actual data, Agile is the only thing so far that has had an impact (albeit small):
Traditional IT project management (sometimes called "waterfall") produces successful results less than 20% of the time. Agile is an improvement over that. Check out the Standish Group's Chaos Report for 20+ years of data on this problem.
I just meant that using multiples to compare _any_ temperatures is meaningless in C. If you want to do temperature multiples, K is better, and, of course, you're correct that Venus isn't 90x Earth in K either.
The surface temperature there is 470C (878F), approximately 90 times that of Earth.
Maybe if we were talking about the Kelvin scale, but even then, 90x is a pretty meaningless way of comparing temperatures. Much better to maybe mention that at 470C:
He's mentioned in the credits: Alexei Berteig. He does lots of commercial, documentary, and now entertainment video work. He recently moved to Vancouver from Beijing. You can check his stuff out at Fashioner Films.
I was in the Marshall Islands for 4 months back in 1996. The education available there is extremely limited and not of high quality. There is no post-secondary education available there. Standards for STEM subjects are extremely low, and the dropout rate is extremely high. At the time I was there, it was normal to have a first child in your mid-teens (for both men and women). The Seventh Day Adventist church had a semi-decent elementary school on Majuro (the main island) with youth serving as the teachers, but most of the "outer" islands had extremely minimal educational facilities. Anywhere in the US has much much much better education than the Marshall Islands.
A great deal of this good news comes almost directly from the media coverage, not the fact of the the changes to pay structure. Still, it's an interesting case and I look forward to seeing how things are going in the 2 to 5 year range after the media coverage can be removed as a factor in the organization's performance.
AAAARG!!! I can't believe that Atlassian is making so much on this crap. JIRA is the WORST POSSIBLE CHOICE for an Agile environment. The very first value of the Agile Manifesto is "Individuals and interactions over processes and tools". (Agile Manifesto)
Not really - even a stopped clock is right twice a day. As far as TFA is concerned, though, I find it absolutely hilarious that the agile fanclub has now gone so far as to "prove" MMM wrong on a very foundational level. Let me be clear: there are a class of problems that cannot be solved just by working more energetically.
I'm part of the "agile fanclub" and I actually am constantly telling people that the whole reason for Agile is because of the truth of the Mythical Man-Month. Agile is not a silver bullet and if someone told you it is, then they didn't understand Agile. Agile values, principles and tools (such as Scrum or XP), give us an environment where we recognize the limits of complexity and communication and help us maximize goodness (productivity and happiness) given those complexity and communication limits.
Extraordinary claims requires extraordinary evidence, and the claim made in the summary is in the same class of all other extraordinary claims, hence we require more than a simple "here's why our claim might be true".
Strongly agree! This dev-ops thing is good, but it's at the height of its hype cycle right now. It's not a silver bullet and any claims to be one need rigorous evidence.
I worked a number of years ago as Chief Architect reporting to the CIO of a similar-sized organization. To answer your question directly: I didn't normally have admin access to systems. I could get it easily if I needed it. Mostly, what I had was access to the configuration management system which was a reflection of everything else. More importantly, what I had was unfettered access to any _person_ in the organization with a role in technology. For the complexity of the systems I was dealing with, it wasn't really possible for me to know (or want to know) all the details. Detail was, certainly important, but I trusted most other people to get that stuff right. The situation you are in, seems like it would require a lot of clean-up. I was in a similar situation. In my case, the clean-up was necessary because many systems had been custom-built by offshore providers who had low levels of technical skill. The best tool I had going for me was to use Scrum as a way to do incremental cleanup of large systems. Scrum (or other Agile methods) are an enterprise architect's best friend! Build an internal team of people that you really trust to get things right, get them to work in short increments 2 or 3 weeks long, give them the vision of cleaning everything up, but doing it incrementally, and help them prioritize the work. You will be surprised at the amazing things you can do without direct access to the details. (FWIW, I love your analogy about map-drawing, but I don't think it applies.)
Okay - perhaps I should qualify a bit: We're 20+ years into PGP and other comm privacy tools. If you're still a newbie you're either really young or you really don't care about comm privacy. So maybe what I meant is that comm privacy is still complex enough that it takes a lot of text and reading to learn it vs. an iPhone which takes about 5 seconds to learn to use it. That's unacceptable for most people who are still in the newbie category of comm privacy.
The fact that this is so long means that by default it's too much for newbies. Communications privacy is not ready for newbies. If you can explain it in 500 words or less (or 2 minutes of video or less) without any further help... that's when it's ready for newbies.
No it wouldn't. Not unless we go back to having hard reset buttons on the front of our machines. The distinction between volatile and non-volatile memory is useful since we still have such shitty software full of bugs and security flaws. I wan't to be able to "reset" my machine without having to erase my hard disk.
So true. When we help an organization "go Agile" it is critical that the managers also use Agile and that they stick with it. But this doesn't mean exactly "by the book" since, for example, Scrum might not be the best approach for a management team. Kanban, OpenAgile, Crystal or other Agile methods or techniques might work better for any given team (including a management team). Long term success of Agile methods in an organization requires that management become Agile too.
That's not even close to enough time for a major cultural change to take place. The Agile Manifesto describes a culture of work that is so fundamentally different from how work was (and still is) performed, that I expect it will take another 15 to 30 years for organizations to really "get it". This is the same thing that happened with Lean manufacturing. Toyota developed it, other manufacturers adopted it as a fad over the course of about 15 years, and then it declined in popularity... but it never died out because it was "correct" and "good". Now, 40 years later, most manufacturers are still learning to be lean, but lean has fundamentally changed the culture of manufacturing. I have clients that will probably be working to adopt Agile methods over a 10 to 20 year period. Agile hasn't failed... Andy Hunt's patience has failed.
Slashdot Mirror
I've done both longitudinal studies and statistical studies in corporate environments starting in 2004 up until the present. Indeed, technology has improved and made some things about remote work arrangements better. And you are right, that there is an objective fact that costs are saved when using distributed/remote teams. But that cost savings is more than overwhelmed by the increased costs of delayed communication, decrease in communication fidelity, and lost opportunities for communication. So when you measure productivity properly (time value of business results / time value per unit of investment), you will find that the clear winner in most cases is collocation. I also want to be clear: there are other business drivers besides just short term profit so, for example, customer satisfaction might best be served with distributed team members that are close to customers. I'm definitely not saying that all teams are better collocated... just that this particular study appears to be deeply flawed.
The methodology seems to be surveys and focus groups. As if employees will report that distributed / remote work is less effective or productive.
The only way to do this properly is to measure the waste in their processes. The farcical thing is that the report actually identifies a whole bunch of different types of waste that are caused by alleviating some of the challenges of remote work: travelling to get face time, fiddling with technology, delays in communication due to needing to schedule meetings, etc.
I've known for 20 years that distributed work environments such for the business and are great for the employees. I've worked in both collocated and distributed environments and I've actually measured (objectively) the effects of both. Business people; don't be fooled! Distributed teams usually cost more than they are worth!
Please enlighten me. Point out a single logical fallacy and I will attempt to fix it.
Around the 90s is when software development was truly in its prime, despite the shit languages and lacking hardware.
Have you heard of the Software Crisis? It didn't magically go away in the 90's. CASE, RUP, SDLCs, CMM/I, ISO, and project management were all trying to fix the software crisis... and didn't. Based on actual data, Agile is the only thing so far that has had an impact (albeit small):
1995 Data - 17% successful software projects (none "Agile").
2015 Data - 11% successful with waterfall, 39% successful with Agile.
Oh dear... Coding is easy, finding people who can code and work effectively in a team is hard.
That's what's important.
And... Coding is easy, finding people who can write bug-free code is hard.
Scrum just makes you build sh*t faster unless you are doing test-driven development, (proper) refactoring and (proper) continuous integration.
What I see are a ton of Agile shops turning out crap, and Agile Evangelists handwaving it away with the excuse that "it's not being done right."
Well if 90% of the places can't do it right, then it's not really a useful system, and all those Scrum Master Certificates are worthless.
Well if 90% of people can't do exercise right, then it's not really a useful system, and all those Fitness Coach Certificates are worthless.
Well if 90% of people can't eat properly, then it's not really a useful goal, and all that education about food is worthless.
Good grief... the lack of logic and insight here is astounding!
PS. The certification part is a whole separate issue.
All sound great in theory, fall apart in practice, and there will always be someone who says, "You just didn't implement it the right way!"
Agile is not communism.
Exercising sounds great in theory, falls apart in practice, and there will always be someone who says, "You just didn't implement it the right way!"
Eating healthy sounds great in theory, falls apart in practice,...
Just because a thing is hard to do or commonly not done well does not mean that the thing itself is bad, wrong, or irrelevant.
Traditional IT project management (sometimes called "waterfall") produces successful results less than 20% of the time. Agile is an improvement over that. Check out the Standish Group's Chaos Report for 20+ years of data on this problem.
It was a bit hard to find a good place to provide feedback. Here is how I did it:
They responded to me by basically saying they were forwarding my comment to the appropriate person.
I just meant that using multiples to compare _any_ temperatures is meaningless in C. If you want to do temperature multiples, K is better, and, of course, you're correct that Venus isn't 90x Earth in K either.
Oops... even with reviewing I somehow missed the connecting words: "Much better to maybe mention that at 470C these elements melt:"
Maybe if we were talking about the Kelvin scale, but even then, 90x is a pretty meaningless way of comparing temperatures. Much better to maybe mention that at 470C:
Read more: http://www.lenntech.com/period...
He's mentioned in the credits: Alexei Berteig. He does lots of commercial, documentary, and now entertainment video work. He recently moved to Vancouver from Beijing. You can check his stuff out at Fashioner Films.
I was in the Marshall Islands for 4 months back in 1996. The education available there is extremely limited and not of high quality. There is no post-secondary education available there. Standards for STEM subjects are extremely low, and the dropout rate is extremely high. At the time I was there, it was normal to have a first child in your mid-teens (for both men and women). The Seventh Day Adventist church had a semi-decent elementary school on Majuro (the main island) with youth serving as the teachers, but most of the "outer" islands had extremely minimal educational facilities. Anywhere in the US has much much much better education than the Marshall Islands.
A great deal of this good news comes almost directly from the media coverage, not the fact of the the changes to pay structure. Still, it's an interesting case and I look forward to seeing how things are going in the 2 to 5 year range after the media coverage can be removed as a factor in the organization's performance.
AAAARG!!! I can't believe that Atlassian is making so much on this crap. JIRA is the WORST POSSIBLE CHOICE for an Agile environment. The very first value of the Agile Manifesto is "Individuals and interactions over processes and tools". (Agile Manifesto)
Not really - even a stopped clock is right twice a day. As far as TFA is concerned, though, I find it absolutely hilarious that the agile fanclub has now gone so far as to "prove" MMM wrong on a very foundational level. Let me be clear: there are a class of problems that cannot be solved just by working more energetically.
I'm part of the "agile fanclub" and I actually am constantly telling people that the whole reason for Agile is because of the truth of the Mythical Man-Month. Agile is not a silver bullet and if someone told you it is, then they didn't understand Agile. Agile values, principles and tools (such as Scrum or XP), give us an environment where we recognize the limits of complexity and communication and help us maximize goodness (productivity and happiness) given those complexity and communication limits.
Extraordinary claims requires extraordinary evidence, and the claim made in the summary is in the same class of all other extraordinary claims, hence we require more than a simple "here's why our claim might be true".
Strongly agree! This dev-ops thing is good, but it's at the height of its hype cycle right now. It's not a silver bullet and any claims to be one need rigorous evidence.
I worked a number of years ago as Chief Architect reporting to the CIO of a similar-sized organization. To answer your question directly: I didn't normally have admin access to systems. I could get it easily if I needed it. Mostly, what I had was access to the configuration management system which was a reflection of everything else. More importantly, what I had was unfettered access to any _person_ in the organization with a role in technology. For the complexity of the systems I was dealing with, it wasn't really possible for me to know (or want to know) all the details. Detail was, certainly important, but I trusted most other people to get that stuff right. The situation you are in, seems like it would require a lot of clean-up. I was in a similar situation. In my case, the clean-up was necessary because many systems had been custom-built by offshore providers who had low levels of technical skill. The best tool I had going for me was to use Scrum as a way to do incremental cleanup of large systems. Scrum (or other Agile methods) are an enterprise architect's best friend! Build an internal team of people that you really trust to get things right, get them to work in short increments 2 or 3 weeks long, give them the vision of cleaning everything up, but doing it incrementally, and help them prioritize the work. You will be surprised at the amazing things you can do without direct access to the details. (FWIW, I love your analogy about map-drawing, but I don't think it applies.)
Okay - perhaps I should qualify a bit: We're 20+ years into PGP and other comm privacy tools. If you're still a newbie you're either really young or you really don't care about comm privacy. So maybe what I meant is that comm privacy is still complex enough that it takes a lot of text and reading to learn it vs. an iPhone which takes about 5 seconds to learn to use it. That's unacceptable for most people who are still in the newbie category of comm privacy.
The fact that this is so long means that by default it's too much for newbies. Communications privacy is not ready for newbies. If you can explain it in 500 words or less (or 2 minutes of video or less) without any further help... that's when it's ready for newbies.
A non volatile PC would be nice.
No it wouldn't. Not unless we go back to having hard reset buttons on the front of our machines. The distinction between volatile and non-volatile memory is useful since we still have such shitty software full of bugs and security flaws. I wan't to be able to "reset" my machine without having to erase my hard disk.
You guys are screwed. Good luck recovering and creating a reasonable culture.
So true. When we help an organization "go Agile" it is critical that the managers also use Agile and that they stick with it. But this doesn't mean exactly "by the book" since, for example, Scrum might not be the best approach for a management team. Kanban, OpenAgile, Crystal or other Agile methods or techniques might work better for any given team (including a management team). Long term success of Agile methods in an organization requires that management become Agile too.
That's not even close to enough time for a major cultural change to take place. The Agile Manifesto describes a culture of work that is so fundamentally different from how work was (and still is) performed, that I expect it will take another 15 to 30 years for organizations to really "get it". This is the same thing that happened with Lean manufacturing. Toyota developed it, other manufacturers adopted it as a fad over the course of about 15 years, and then it declined in popularity... but it never died out because it was "correct" and "good". Now, 40 years later, most manufacturers are still learning to be lean, but lean has fundamentally changed the culture of manufacturing. I have clients that will probably be working to adopt Agile methods over a 10 to 20 year period. Agile hasn't failed... Andy Hunt's patience has failed.
It was irony.