Lazy developers hate agile and scrum
During the #sapphirenow key note, CO-CEO of SAP Jim Hagemann Snabe said that he saw no drawbacks of introducing scrum to part of SAP product development and the challenge now was to scale it to the entire company.
I tweeted this, but received immediately a response from an analyst that ”Developers hate scrum”
I thought this was a somewhat strange statement, as in my experience 98% of developers love scrum and the rest fear it because of the transparency.
I then got two more interesting replies from twitter, one from @webtonull stating the rest fear it because it is experienced as surveilance (meaning your not really doing it as intended). The other was from @cvitan who came up with the catch-line “lazy developers hate scrum”.
Myself and Twan van den Broek, who has experience from running scrum in SAP projects (see his presentation on the topic), figured out we’d do a short video to share with the world and the SAP Community. This video is shown below
Filed under: Elsewhat | 26 Comments
Tags: agile, SAP, sapphirenow, scrum
Recent Comments
I just came across your web site and had to do a comment:
After watching your video I think you have an extremly single-tracked mind regarding the objections against scrum. It seems you are trying to have developers that dislike scrum to shut up so the are not categorized as lazy developers. This is nothing else than a suppression technique. But lets have a look at the transparency of scrum that you are appreciating so much. This “looking over the shoulder” treatment of devoted co-worker are nothing else than undercuting of their credibility. If you motivation for using scrum is to reveal lazy developers you ar killing the the motivated and effective developers at the same time. Further, making elegant, effective software systems is more of an art than building a brick wall. Thus, the mechanical nature of scrum does not fit development of software of a certain complexibility. Just think of the small but extremly elegant piece of code that makes up the binary search algorithm. This is art and you can’t require a developer to estimate the number of hours it will take to do the research work that results in such an algorithm. I think software developers (young and inexperienced) are the only profession who accepts this kind of treatment.
Appologize for the late feedback; have been on vacation and have had a long backlog.
First of all I want to make clear that I am not “trying to have developers that dislike scrum to shut up so the are not categorized as lazy developers”. I wanted to quell/respond to a statement that “developers hate scrum” because I believe from my own experience as a scrum master and in large enterprise projects that this is not the case at all. I can agree that my response to this was a bit tabloid, but sometimes a more provactive message is required.
But even if there is just 1% of developers that resist/hate scrum, I want to understand why they do this and how scrum was applied at that case. I really respect that scrum is difficult in many cases; I would recommend reading Vijay’s excellent blog on how he has not been able to get it working on very large (100+ developers) global contracting projects (see http://andvijaysays.wordpress.com/2010/04/16/south-beach-diet-didnt-work-for-me-and-neither-did-agile-development/). I’ve had many good constructive conversations with Vijay about this.
The most common criticism I hear is related to that people feel like they are being controlled and as you say someone is “looking over the shoulder”. This has nothing at all to do with someone “undercuting of their credibility” when you are running scrum. Scrum advocates two principles; transparency and common team commitment. Common team commitment means that the team as a whole should take responsibility for delivering what they committed to in the start of the sprint. In most case the team is not able to do this (as we as humans are poor estimators and because it projects have lot of uncertainty) and thats ok, but the team should take ownership and try to be as efficient as possible (ie. reduce waste). The daily standup is the most important meeting in order to understand progress during a sprint, and if there is no progress from a team member the others should be interested in how they as a team can move forward. It might be that the team member has been doing work for someone else, in which case it is the scrum masters responsibility to protect the team from distracting tasks unrelated to the current sprint. It might also be that the team member was on facebook half the day because he was lacked motivation and was stuck in his current task. Then you need to identify that as quickly as possible and that is what scrum has mechanisms for.
“making elegant, effective software systems is more of an art than building a brick wall”. If it is art can be discussed (maybe you are not keeping it simple enough), but it is very different from construction work. The reason for that is that there is so much uncertainty. AND THAT’S EXACTLY WHY YOU NEED TO USE SCRUM and not a waterfall approach that tries to plan everything in advance.
Any work; including things like optimizing search algorithms, can be broken down into smaller task and worked on (though I would probably use kanban for the search problem). You might not have any idea how long it will take, but you are committed to use a team for sometime in order to try to make progress. Innovation happens in groups and for the enterprise whole-day workshop approach as done is scrum is IMHO the best approach (see http://www.ted.com/talks/lang/eng/steven_johnson_where_good_ideas_come_from.html ).
I’m surprised to learn that I’m a lazy developer (or am I just bad and trying to hide my badness? I can’t tell). My various coworkers, bosses, former bosses, former clients and friends-in-the-industry will be surprised to learn that I’m a lazy, bad developer because I loathe (yes, not dislike, but loathe) scrum.
Why do I loathe scrum? Let me count the ways:
1) Committing to something I know I can’t achieve is stupid. Committing to less than I know I can achieve is also stupid. Thus, there is no way to “commit” to work at the beginning of a sprint that isn’t stupid. I can either overcommit, making my commitment irrelevant since I know I won’t be making it, or undercommit and “game the system”, which usually leads to POs and the almighty scrum master adding more work halfway through the sprint when the team runs out (the alternative being what… we sit around and do nothing until the next sprint starts?). You yourself acknowledge this with “In most case the team is not able to do this (as we as humans are poor estimators and because it projects have lot of uncertainty)”. What exactly does the word ‘commit’ mean to you? if you’re married, is your ‘commitment’ to your wife as shallow and subject to change as your ‘commitment’ to a sprint? Are they even remotely the same?
2) Meetings. Meeting. OMFG meetings. I’ve worked for huge companies where my team was responsible for cross-department software and frameworks and haven’t had nearly so many meetings. I’ve done huge amounts of (somewhat superfluous) upfront design in meetings, and I still had less meetings (sorry “work sessions”) than I do in scrum. I have a useless meeting every day where I say that I don’t have any impediments and uptalk whatever I’ve been working on or will be working on. Then I have “backlog grooming” which is basically me and the whole rest of the team doing the job of a project manager, then all-day “retrospectives and sprint planning” which wastes an ENTIRE DAY of my time for really no benefit to velocity or environment.
3) The ‘Cult of Scrum’ mindset, very clearly evidenced by this blog post, which basically says that Scrum is perfect, works for everyone and everything that that anyone who hates scrum is a heretic, or a lazy, terrible developer. I’ve never worked in a less “agile” (using the dictionary definition of agile here) environment than Scrum. Never been told I need to attend so many pointless meetings and do so many pointless things. I would VASTLY prefer waterfalll, not because you can write a perfect spec up front but because waterfall wastes less of my time than scrum does.
I could go on (and on, and on). I’ve worked in several different organizations that have implemented Scrum or Scrum…but and frankly I hope never to work in another one.
Thanks for taking the time to write this comment.
First of all, I was making the case that lazy developers hate scrum, not that everyone that hates and loathes scrum are lazy. Quite the contrary, there are many reason why someone would dislike scrum.
Let me just make some comments on your 3 ways of scrum loathing:
1. I agree that commitment in scrum cannot be compared with the commitment you do to your wife. The definition I use towards the scrum teams is more along the lines of “We as a team believe that based on the knowledge we have at this point of time, it is realistic to deliver the business value represented by these user stories. We will do our best to complete it, but remember that shit happens”.
Yes estimation is hard, but as the product/solution, user stories and the team improve and matures you do get a gut feeling of what the team is able to deliver in a two-week iteration(scrum says 2-4 weeks, but I am an advocate for 2 weeks). Regardless, it is easier to estimate a sprint of two weeks than a project of 8 months
2. It is always positive that the team challenges the purpose of meetings and flag if they considered some of them waste. Heck, focusing on reducing waste is the core principle in lean.
From a scrum point of view the meetings are there for a reason, but especially the scrum master has to have focus on the format so that it delivers value. If not, they may well end up doing more harm than good.
The daily standup is a meeting by the team and for the team.If you don’t care about what the other people in your scrum team is doing, you are not a team. (I am not saying that everyone in the team should do everything, but that you are in the all in the same boat and should have the competency together to complete the user stories you receive)
The backlog grooming is a meeting where the team doesn’t focus on the current sprint, but looks forward. The product owner ideally knows what gives most business value for the coming sprints, but the team needs to mature how to achieve this business value. If you don’t do this, the planning and start of the next sprint will usually be rocky and waste even more of your time. Of course, if the product owner has no good plan and poor quality on the user stories, the meeting will fail and the team will feel that they’re left with a lot of extra work someone else should have done. But then, the scrum master should make sure this doesn’t happen again and maybe start a process to educate/replace the product owner.
The retrospective is all about improving how you work as a team. If no-one on the team is interested in working as a team but instead wants to have a well-define responsibility area, then perhaps scrum is not the right process.
In some cases, a very good developer will deliver more value than a scrum team that is relatively new. But I am still convinced that if you get this very good developer into the right team, his competence and drive will make the team much more productive and deliver in with higher quality than the sum of each individual.
3. I do hate the ‘Cult of scrum’ where you are not allowed to criticize scrum. In hinsight, the video was a bit too sensationalist.
(but so was the claim that triggered it, that all developers hate scrum)
I don’t think we’ll ever agree, but I appreciate the discussion.
Several developers nailed the issues in their responses, yet you disregard. Yes, I know you responded, but you did disregard. That’s the problem, developers vs. managers.
Let me ask you these questions:
Have you ever been a developer?
If so, have you ever been a developer on a scrum team?
If so, have you ever developed in anything prior to Agile?
My guess is that your experience has been at the lowest level a project manager. If you were a developer at one point, I’m going to guess that you’ve been out of it for a long time.
Managers love Agile – it gives them an excuse to micromanage and call it something other than micromanagement. Let me stop you before you pull up the standard response in the scrum master’s handbook: “but the team manages themselves”. Suuure they do, as long as they do it exactly as Agile has prescribed. An actual self managed team wouldn’t go through 3/4 of the garbage that agile says they should.
You assume that 98% of them like probably because none of them bother to argue with you about it. As evidence of this blog you are refusing to listen, and have labels already picked out of them if the don’t cooperate. You have a response for every developer’s concern, much as my management has had here. I think it was even part of their training to dispel agile-rebellious developers as non-team players: “Here is what they’ll say, and here is how you ignore them”.
Developers worth their salt hate agile with a passion. It is a stifling and demeaning method of project management who’s failings are masked with phrases like “self managed teams”.
There is one great aspect of agile – heavy continual involvement from the customer, and embracing the concept of changing priorities. The benefit stops there.
Let me first answer your questions:
Yes, have been a consultant and developer within large enterprises for the last 9 years.
However, the last couple of years I’ve worked more with the business on strategic initiatives and how IT can support them on a high-level.
I definitively prefer working in projects and have no interest in becoming a line manager and having resource responsibility.
At the same time, I’ve can as far as I remember have had small hobby project on the side, where I can get the programming itch out of me.
Yes. I’ve been a developer on several scrum teams where the projects and stakeholders had varying maturity of scrum usage.
I’ve also been part of a non-IT scrum teams where we have looked at process improvement and future project assignments.
I’ve been part of large and small waterfall projects, from the merger of large companies to minor functional improvements to existing solutions. Some of the project have been very successful and some just plain ok.
In these projects I’ve had roles from developer to team lead to solution architect.
As I’ve stated before this is not within the underlying principles of scrum, so it is more the fault of the implementation than of the actual methodology.
It is an interesting discussion though – that scrum gives increased possibility to manager-abuse of developers.
Well, if that happens and they won’t budge when you argument with them, there is only one solution.
LEAVE THE COMPANY! It’s a free market out there, and see how well they do without developers.
What 1/4 of scrum/agile would a self-managed team use?
Damn, you discovered the world-wide conspiracy.
But seriously, I’ve tried to have a constructive discussion here after posting a sensasionalist video.
This is actually I great quote. I respectfully disagree, but a great quote.
Team work with shared responsibility has come to stay, heck we even changed our education system to revolve around team work from the first grades (at least here in Scandinavia).The business will slowly adapt this, but yes there will be growing pains.
Hi Dagfinn
As SAP Scrum Master i have to say that not all of us hate scrum, in fact we use it not only for development, but for other practices as well, at the end this is the benefit of Agile, that is flexible and you can adapt it easy.
The obstacles are quite clear you have to start with the commitment for all involved parties, you cannot have a Product Owner that is there only to give “sponsorship”, the PO must be actively involved in the project.
So, from my experience using Scum in Development and in Non-Development areas is that the key is the commitment and you have to avoid the following 5 points:
- Staff Dedication: You have to be clear what is the % of dedication for all the crew
- Executive Support: This means they are sponsors, not Product Owners (you can call them PO, but is better if you also have a real one)
- Identify conflictive elements at the begining, those people that is hard to manage the change need to be identified early and as Scrum Master play an evangelist role with them.
- Tools are criticals: without the right tools we are lost, excel helps but in a large project is another risk factor.
- Administrative task: we use to keep Scrum only for Development but there is a lot of administrative task that should be involved as well, and all should be part of the cake, we cannot handled it separated, they should use Scrum for a success
I’ve also used Scrum for personal projects, not related at all with Software and I’m glad to see the results.
Kind Regards, Luis
Hello
There are a number of things I find troubling about this video, but especially the comment that developers are “10 times” more effective.
10x? Where did you get this number? Who advertises such an improvement?
Are you telling us in your shop, projects that used to take 1 year now take 1 month?
Jordan
Hi,
What I am refering to is research done on hyper-productive teams.
The paper “Fully distributed Scrum: The secret sauce for hyperproductive offshored development teams” has done research into this area.
To quote from it “Combining Scrum with XP engineering practices has generated hyperproductive teams with 5-10 times industry average performance since 1993″
The paper is available at
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.3309&rep=rep1&type=pdf
I didn’t remeber the actual numbers during the interview, so I appologize for it being in the high-end of the scale.
Teams I’ve been working in and with are no where near this increase in productivity and in my opinion agile/scrum should not sold in with a promise of improving effectiviness. I do believe however, that a team can be more effective than the sum of the individuals.
Dagfinn
A couple of other interesting sources if you are interested in learning more about hyperproductive teams.
Jeff Sutherland talk for Google on the topic
Short article
http://www.theagileengineer.com/public/Home/Home_files/HyperProductiveAgile_Article.pdf
Aha of course. A paper written by Sutherland himself.
This alone makes it quite questionable. I have read the paper, and I find the data quite suspect.
For instance they say “Table 1 shows Scrum projects easily outperform the
waterfall project. Xebia Distributed Scrum is close to
the collocated Scrum and the performance of the
SirsiDynix and Xebia project is very similar. This
shows that the high performance fully distributed
Scrum approach is reproducible and not unique to the
SirsiDynix environment.”
First of all this has nothing to do with Scrum itself (as quoted in your video) this is about DISTRIBUTED Scrum + XP. Totally different.
Nevertheless, they claim the performance of Sirsi and Xebia as “very similar” — when the data in the table is not similar at all.
The Sirsi version took 8x as long as Xebia and 2x as long as Waterfall? That is similar?
Also they never define the waterfall project team etc so we can assume it is a complete and total strawman.
This is not a believable 3rd party study.
Additionally the Scrum environment is very fragile, even a few people leaving can cause the whole thing to melt down as documented here:
http://www.agilejournal.com/articles/columns/column-articles/795-the-four-pillars-of-agile-adoption
It is not merely the “lazy” developers that hate scrum.
Anyone who is a good developer and effective at what they do is going to hate scrum.
Your video depicts nearly every anti pattern I cover in:
http://jordanbortz.wordpress.com/2011/04/06/how-scrumdamentalists-and-xp-zealots-instill-dysfunctional-communication-patterns-in-their-students/
You should certainly read that and stop denigrating people who don’t like scrum by calling them lazy.
Anyone could say “only lazy managers love scrum” because then they don’t have to do anything.
It is grossly unfair to pain everyone who doesn’t agree with this for profit methodology as merely “lazy”.
You can read the rest of my blog for more of my thoughts on Scrum.
Jordan
I agree that the dataset which the paper is based on really is too small to draw any reasonable conclusion on effectiveness. Untill I find some more credible research (I’ve not really looked into this field before) I’ll stop quoting numbers from the paper.
I believe combining Scrum and XP practices is fair in this context as in my experience the increased transparency and focus on waste make most scrum teams investigate one or more XP practices or other software engineering practices. Including offshoring and distributed scrum though brings a totally different dimension into the picture and should be avoided.
Are you aware of any credible research on different software metrics between methodologies such as waterfall, RUP and scrum ?
How you manage to make that conclusion based on that article is beyond me.
In my view the article reviews a project where over time focus has been lost on the scrum process and roles, and only parts of it is being used. In addition, it shows that the surrounding organisation (product owner, PMO office, managers) also should change and embrace more lean principles.
It does point out that there are many perils when implementing scrum and these should not be taken lightly on. Just mentioning scrum and picking some of it to use is no silver bullet as many for some reason believe.
Waterfall project also melt down if no one update the initial plans or the requirement specification as changes happen, but we don’t go around critizing waterfall because of that. The benefit waterfall has is that more people understand the principles and dynamics of the methodology. Unfortunately for scrum, too many organisation do modifications they don’t understand why the do it and what the consequences are.
I like your anti-patterns, but they certainly don’t just apply to the “Church of scrum”.
I’m not calling people who disagree or dislike scrum lazy, I am merely saying that one group of people who may not thrive initially in a scrum team are people who are significantly below average in productivity, is not used to take responsibility and generally not pulling there equal weight. A scrum master should have extra focus on this stereotype when starting up a scrum team in order to make sure that the rest of the team help them improve and integrate them in the team.
Congratulations, you just managed to use four of your own anti-patterns in one sentence!
Well done.
There are perfectly good reasons why people dislike scrum, but in most cases my personal belief is that we can learn a lot from listening and discussing with them. We might never agree, but they’ll understand better what we’re trying to achieve with a scrum team with surrounding stakeholders, and we’ll understand better the dynamics involved in a team of persons. And yes, we should be open to use other methodologies if there are project characteristics that lead to that (such as very low degree of changes overtime).
I had no idea there was such strong feeling against Scrum or Agile. Clearly your video provided a focus for some venting. In support of Scrum and Agile, I have worked in the industry as a developer for 25 years. In that time I’ve been involved with many successful projects, mainly in the banking sector, and the vast majority of them developed with traditional waterfall processes. One of the many faults I’ve found with waterfall is that the feedback loop is far too long. By the time the customer sees what they’re getting the ship is full steam ahead and turning it is difficult.
As a developer, the thing that really rings my bell is being able to deliver a product that meets the client’s needs. To date Scrum and Agile have provided the best platform for me to do that. In my experience successful projects are more about the people than the process. Using waterfall even very good people can develop a poor product. Using Scrum and Agile average people can deliver a very good product. And lets be real, there are a lot more of us average folk than there are rockstar developers.
I’ve also found that Scrum is great for relieving management pressure. Managers like to know what’s going on and to see progress. Scrum provides plenty of good feedback and each sprint delivers some new function or feature. That kind of transparency provides little room for arguments about progress and plenty of evidence that a team is working at capacity.
Thanks for sharing your experiences
“How you manage to make that conclusion based on that article is beyond me.”
I plan on blogging about that in depth in terms of my conclusions from that article, look for it on my blog.
” I am merely saying that one group of people who may not thrive initially in a scrum team are people who are significantly below average in productivity, is not used to take responsibility and generally not pulling there equal weight.”
And those people should have been weeded out prior to adopting Scrum. This should have been visible already. Hence one can and probably should assume that these people were weeded out, hence there is no need in Scrum to weed these people out.
Further, had these people been weeded out already, Scrum would not be necessary.
“Congratulations, you just managed to use four of your own anti-patterns in one sentence!”
Oh? Which four? I said “Anyone” not “Everyone”. I think the point has been made over and over that competent developers don’t feel that Scrum is a benefit, you can scroll up to see that I think….
Jordan
Also FYI re “Waterfall project also melt down if no one update the initial plans or the requirement specification as changes happen, but we don’t go around critizing waterfall because of that. ”
Of course you do. Maybe not you personally but certainly the Scrum Agile crowd does. That is there drumbeat, the holy war. They pretend that “waterfall” can’t adapt to change and that’s why the world needs Scrum.
If it is fair to blame waterfall for overplanning, it is fair to blame scrum for overmeeting, underplanning, and micromanaging the dev team.
Most projects that I have seen fail do not fail because the team wasn’t committed or was wasting time. Most of the projects I see fail are due to not getting the market right, not enough budget, ineffective marketing, etc….
Things which Scrum does NOT address, at least not at the dev team level, other than vaugely alluding to that these problems should be solved somehow….
Jordan
On this we definitively agree on. The process of going from a project organisation where the project has most of the responsibilty on direction and changing that to point to a Product owner from the line organisation which now is responsible is a big leap that should not be taken lightly.
Looking forward to read your views.
In my experience they have not been weeded out, because it is not that visible what each person does. Scrum does improve transparency, but tells you little about what to do with the issues that surface.
From my knowledge of english, the semantics of this sentence is the same whether you use Anyone or Everyone.
As for which anti-patterns you’ve used here I would say:
1) Grandstanding
2) Firebreathing – Demonizing the opposition
4) Wanton Disregard of the Facts
7) Demanding Proof of others but supplying none themselves
Just read a related paper ”
Introducing Scrum in Companies in Norway: A Case Study” which matches my personal experience quite well.
http://proceedings.informingscience.org/InSITE2010/InSITE10p331-351Brekkan794.pdf
Here is one related quote
“The developers that were interviewed all stated that their working environment had improved after Scrum implementation. Different aspects of Scrum were mentioned as factors that contributed
to this improvement and we found that several of the interviewees related this improvement to
team work, that is, co-operation with others gave satisfaction and that the team could organize
they work according to own decisions. In addition predictability of what they were going to work
with and fewer interruptions from other people played an important role”
It might be that the Scandinavian mindset/culture is more suitable to scrum than other countries, but I doubt it is that simple.
Note the difference between:
http://www.merriam-webster.com/dictionary/everyone
http://www.merriam-webster.com/dictionary/anyone
Note also that they do not list the two words as synonyms.
I don’t think you as s Dutch should spend any time lecturing me on correct English.
Look forward to your apology.
Jordan
Note the difference between:
http://www.merriam-webster.com/dictionary/everyone
http://www.merriam-webster.com/dictionary/anyone
Note also that they do not list the two words as synonyms.
I don’t think you as a Dutch should spend any time lecturing me on correct English.
Look forward to your apology.
Jordan
I never claimed everyone and anyone are synonyms, just that the meaning you are conveying with the sentence is the same regardless of which of these word you used. (though everyone implies a bit more empiricial evidence than anyone)
I see no other interpretation on that statement than:
If you are a developer and good at it, you hate scrum
If you have a different interpretation, please come with it.
With the above statement you’re also implying that:
If you are a developer and like scrum, you’re not a good developer.
This in the same way as I might be interpreted to imply that;if you are a developer and like scrum, you’re not a lazy developer (something which is not an intended meaning and one of the reasons why I included “why lazy developers mightfear and hate agile and scrum” in the youtube description).
There really should be a respected unbiased survey on the correlation of developer performance and fondness of scrum methodology. Untill then I guess we’ll never agree
The difference is that Anyone implies the possibility and everyone is the certainty.
You created this abhorrent video, and now you are trying to blame me by nitpicking a sentence.
You’re also completely incorrect that there are “4 antipatterns in one sentence” … POSSIBLY there is ONE if you (misread) what anyone means.
I think I’ve made all the points that can be made here; I have no need to convince you of anything nor do I need to convince you of anything.
You stubbornly refuse to believe even the dictionary in this case.
Jordan
I am still amazed at how some CIOs are fooled by the lure of ‘agile’. They have absolutely no clue as to the permanent wounds that will be left in an organization once the genie is unleashed. Fantastic developers become disgruntled coders. Lazy coders become… well actually they stay the same. And mediocre programmers become lazy coders.
Check out this hilarious video as to why a CIO would even consider agile in the first place.
John
I have been developing for almost 30 years and taken many large projects to market. I have consulted for 20 years and worked for many large corporation. I believe that “motivated” and “highly creative” developers hate scrum. This is simply because they do not need to be micro-managed. In fact, they are put on the defensive by it and it is the best way to not get the best out of them.
Good programmers are driven and motivated by their excitement about technology. Managers are motivate and excited by meetings. As, developers we have noticed this trend for many years. Scrum is the newest expression of this propensity. And, no high quality developers, that I have ever known, are going to be inspired by daily meetings about what they dud yesterday and what they will do today. Programming “velocity” just does not work that way.
“This is simply because they do not need to be micro-managed.”
Scrum isn’t about micro-management. It’s about creating a shared conscience across the team and, it also highlights who’s having problems and who isn’t. i.e. It reveals to an observer who might be motivated and highly creative and who might not, it can hint that a team isn’t functioning well, that some people are being stifled and so on.
Scrum is then, about building high performance teams and delivering some stuff worth a damn (which requires a level of transparency because no team is perfect), that’s why there are observers and do’ers at stand-ups. Observers are coaches and interested parties not controllers or managers.
High quality developers know this, as do the best team builders (I am not a manager, I’m a coach and guide).
“Good programmers are driven and motivated by their excitement about technology”
I disagree, almost all programmers are motivated by that, just take a look at all the magazines (on and off line), twitter feeds, blogs and such. Everyone is doing that and it’s not the mark of a great programmer. A great programmer is motivated by using technologies to make a difference and knows that technology itself doesn’t solve problems, it’s the surrounding work such as design, testing (not just functional), a level of planning discipline etc.
Astroturfing. +1 for working in an ad for your services “Coach”