A good read. Too often my focus is on the structural aspects of software development – the hard, tangible things, process, doco, etc.
Am currently reading Brooks’ The Mythical Man Month (finally, after years of meaning to do so). He cites several studies into programmer productivity, with some programmers identified being 10 times as productive as low productivity programmers. Certainly gels with my experience.
One consideration not covered in your article is that of the additional process required for a product (vs project). With 90% of the total software effort being in software support, lightweight methodologies must still produce sufficient non-software artifacts to allow effective application support for many years of service.
From Alistair: You are right – that’s the whole point of the “markers for the followup game” in the Cooperative game manifesto for software development (discussion: Re: Cooperative game manifesto for software development). Many agilists forget that. (Thanks for adding to the discussion. As a courtesy to the other readers, could you please use your real name in these discussions?)
-by Alistair on 12/5/2008 at 11:52 AM
I really enjoyed the article. It is interesting that the rigor and breadth of the analysis brings us back to the observation that our real problems are rarely if ever technical ones — they are human ones. People …are the issue.
There are many points of needed methodology change suggested. I appreciate the recommendations for future work. I am keenly interested, however, with the problem of how an organization can put into place all the pre-requisite elements to optimize the likelihood for team-level success. What combination of methodology, training, team member skills sets, selection critieria, environmental support, performance and reward criteria, etc, can be implemented to help ensure success? Much of what I’ve read and seen focuses on internal team mechanics. The insights are helpful but seem to beg the question of what senior management should be doing to raise the liklihood of success. Now.
-by John Napier on 7/15/2009 at 2:13 AM
The question boils down to “How can I change someone else?” which has the general answer – You Can’t.
The change you are asking for is something along the lines of “How can get people to become curious, caring, disciplined?”
The subssequent variant of the question has one of two answers – “How can I engage you as a consultant to change my people … ?” Which has the general answer, You Can’t. This is because a consultant shows up and then vanishes.
The second variant of the question is “How can I as a manager create or change the environment so that people are more likely to …?” To which the answer is, “It’s a long shot, but here it goes ..”
AFAIK, one of the more interesting jobs of a manager is to create an environment where people feel more curious or more caring or hold each other to discipline. This does start Now, as you write, and continues for a long time.
More requires much more space than I have here, and enters on general leadership and managment … not sure what I should next here…
Nice question :). Alistair
-by Alistair on 7/23/2009 at 4:55 PM
This is the best article I have read for a while, actually offering something refreshing.
I don’t claim to be an expert on people – far from it, but it seems to me that to figure out what motivates people is as simple as talking to them. When you talk to someone you can figure out what’s the thing that makes them come alive.
Actually, to figure out what would work for your people you would first need to get to know your people. This is a slow method and in the quick-fix world we live in, probably not the answer many people are looking for. We’re in too much of a hurry to stop and think, grasping frantically for silver bullets. And that’s exactly what we’re getting, and the werewolves stay unaffected.
When I think about the teams I’ve worked in, all the individuals in these teams were different. Some of them work well w/some people and other w/others. Some almost exclusively alone. Yes, it’s that chemistry thing again.
In a perfect world you would find people that would naturally fit together, like pieces of a puzzle. To do this, you might need to be able to hand pick the team. This reminds me of – perhaps Joel Spolsky – writing about giving all the team members a veto regarding a new team member.
I think it was probably Tom DeMarco who wrote that there are no generic methods to make teams jell. There’s just things that ascertain that they won’t. I’m now suspecting that he might not be entirely in the right on that one. He’s probably right about it in a general sense, but it doesn’t mean that there wouldn’t be teams that would respond to some actions, in specific cases. And to get to that you would again need to know your people.
The only conclusion to which I can come here w/this now seems to be that one would first need to create a safe athmosphere where people actually become willing to share what makes them tick. Where you have open communication, you can get to know your people and this may be the first step to finding out what might work w/them.
So no quick fixes, just being a person, being present for your team. Being open and honest – and positive, w/whatever consistency you’re blessed w/. People actually are pretty good at telling whether you care about the team you’re working w/ and about the thing you’re creating. I think you’re one big step closer when you care and another, if you can find a positive way to express it.
We’re social creatures, and I think we’ve evolved to pull together in a small group. It’s unleashing this that might be the magical ingredient. How to get there, how to win the trust of your people and to find a way to align towards a common goal has to take some type of bonding. And it all probably starts w/being friendly, honest, trust-worthy and caring. Maybe it’s about caring as much about the people as it is about caring about the goal. Maybe it’s even making the people your goal. Maybe we should study how communities are built, how villages evolve, how families work to see what we’re really looking for.
Perhaps. Food for thought, at least.
I now recall reading once that people actually are looking for something greater in life, a meaning, a purpose, something to strive for. Teams who have succeeded in making their work this purpose have even reported in some cases like they were “on a mission from God”. Such state of clarity of vision and purpose is of course really rare. But I would like us not forget this. This is at the far end of a team that’s really committed, really working together. It’s grand.
One more thing that I just recalled from Systems Intelligence and specifically regarding Losada’s results regarding high-performance teams: Their inquiry/advocacy ratio is 22.3 times that of a low performing team. Their positivity/negativity ratio is 15.5 times that of low performing teams and their reference to other/self is 27.5 times that of low-performance teams. I guess that’s what “jell” looks like in numbers.
-by Susanna Kaukinen on 8/31/2009 at 6:00 PM
This is an excellent article and I agree with many of your sentiments. In the evolving world of modern IT, it is hard to believe that there are relevant and insightful articles more than a few years old.
This said, I am troubled/disappointed by your lack of evidence to support your main assertion (that people are first-order components in software development). It is not that I disagree with this statement, but (aside from anecdotal evidence and a potentially semi-related study into communication) you present no quantitative data to demonstrate it. The list of projects that you examined (Table 1) may demonstrate that methodology is not the only factor contributing to project success, but it does not demonstrate that people are a source (let alone the most significant source) of ‘iron in walls’. Whilst I appreciate that at the time such thinking was relatively new, I would expect greater thoroughness before calling for 20-50 years of its study as a primary area of software engineering. So, how about it Mr Cockburn, do you have some data to back up your claims?
I would also like to know how you feel about this paper given 10 years hindsight. Obviously some practices (like Cleanroom) have faded into obscurity, whilst others (like XP) have contributed greatly to modern software development. What I am more interested in, though, is what you might write today. For example, you mention that email/documentation is ineffective compared to face-to-face communication. What then are your thoughts on the body of collaborative tools (e.g. wikis, blogs, IM, etc) that are seemingly integral to the success of modern development? Likewise you suggest that methodologies should cater for inconsistent people to promote robustness. Whilst the fundamental inconsistencies of humanity have not changed, this decade has seen a different breed of developer emerge from universities (dare I say, less cowboy). Should we still be focused so heavily on promoting inconsistency?
Thanks & Regards,
Mark Bugno, Parabios
-by Mark Bugno on 11/9/2009 at 10:17 PM
I would write pretty much the same article today. You are right – people haven’t changed much in the last 10 years (nor would one expect them to). Face to face still outplays wikis; citizenship still matters; new programmers are still undertrained and undercommunicative.
I’ve learned more about trust, collaboration, communication, etc in the last 10 year, but it’s really only adding to the base, not changing the base.
-by Alistair on 6/1/2010 at 12:52 PM
This is a seminal article recently cited at an Agility seminar in New York. It is a must read by all software people and those who pay their salaries. Cockburn’s approach is humanistic and it works!
The non-linear behavior by the people component fits well with my experience and as an engineer I know we need tight feedback control to prevent a nonlinear system from becoming unstable. I put in place technicians and expediters as interfaces between developers and testers. Then I set up an extensive libraries and code analysis tools run by the technicians who I called software manufacturers. They built our systems, control the change process and maintained the build and the test machines. They were in-line and not support. They made all deliverables to clients. These people prided themselves in knowing what version was working where and that the agreed to standards of code structure were followed.
Managers were asked to adjudicate disagreements and manage by exception; not to make all decisions. Middle managers are a problem. They fight hiring people better than them, new processes and new technologies. They are on the hook for delivery and become more conservative as things go badly.
Success is difficult to measure. To me it is the ability to solve the customer’s problem even when they do not understand it themselves. The trust and loyalty of the customer is the measure of success; but only if you are profitable.
In any human endeavor, good managers are critical. In software projects they are critical. You can not replace bad managers with good processes and you can not automate a chaotic process. Expert project managers learned all this by the school of hard knocks. We need to teach this common experience so that we do not continue to repeat mistakes and yet expect different results.
Cockburn declares the end of software engineering. I disagree. It is too bad that software engineering has become to mean software process engineering. Making technical trade-offs about the characteristics of a product and dealing with non-feature functions such as having the appropriate reliability, security and safety are all software engineering questions that need more attention. The software engineer must know how to improve system availability by an order of magnitude or make sure that the software system is robust to buffer overflows and memory leaks. Consider the merging need for Green Software solutions. Do you know how to design software that reduces power usage? The professional software engineer must master these subjects. They are not professional coders.
My book puts people first too, followed by the product, the project structure and then the process. (See Trustworthy Systems through Quantitative Software Engineering, Wiley 2005, ISBN 978-0-471-69691-9 chapter 2 and section 11.9)
As Pogo, a great American philosopher, said, “We have met the enemy and they are us.”
-by Professor Larry Bernstein on 5/12/2010 at 2:08 PM
Alistair, it was good to re-read this.
For the topic of “Personality profiles” I have found that Belbin Team Roles are helpful. (My “Completer/Finisher” tendencies on his ratings are easier for me to relate to than the outputs of other “profile” tools that I have used.)
I was lucky enough to see Meredith Belbin speaking a few years ago, and he related evidence for his approach predicting success (one memorable example was about ocean-going yacht crews).
For more, including tests (which I think need to be paid-for), see belbin.com (no personal connection).
Hope it may help.
-by Bob Corrick on 5/13/2010 at 7:37 AM
Thanks for the great article. I would like to know if I can reproduce figure 1 in my blog, keeping its reference of course.
-by Ricardo Mayerhofer on 6/3/2010 at 4:49 PM
Yes you may, thanks :). Alistair
Hello Alistair, what a wonderful article to find and I enjoyed reading it very much, and every ones comments too.
Prior to reading ‘Peopleware’ and ‘The Psychology of Computer Programming’ I never considered people and their continual interactions as being a critical factor in the success of a project. It wasn’t something I was taught. Following the software development process was always pushed as being the route to success. This I think is a root cause; a lack of education, early, to the importance of teams with good communication skills.
Recently, by observing a project I wasn’t involved in, I saw proof that the success or failure of a project is down to direct free flowing communication amongst the team; as well as the teams ability to act on the decisions generated from that communication.
In this case the cultures of the people involved was the issue. One culture was open to one on one discussion while the other culture was based on information flowing up the corporate hierarchy and decisions coming down (almost military like).
What was observed was although the team members sat at desks next to each other any discussions between them had to involve several levels of management. Even decisions made in informal chats about the project between the team members were shared with upper management who could then veto the decision with their own.
In this case there was direct face to face communication between those working directly on the project but the decisions of the project were made by people who weren’t in the best position to make them; people who weren’t part of the everyday discussions.
The project is several months late and still in no position to be released.
The “few good people stepping in at key moments.” are trying to do so but what they suggest is either being ignored or being scrutinized; stopping flow.
All the best,
-by Derek Smyth on 7/31/2010 at 10:24 AM
Thanks for the comment and notes, Derek. Best wishes, Alistair
-by Alistair on 7/31/2010 at 10:42 AM
Thank you for a fanastic article.
I am ecstatic to find someone with a focus on people in software. It is such an rare but critical area of study. After all, human beings are why software exists at all. No wonder we are a primary contributor to a project’s success or failure!
After 17 hard fought years as a software tester, manager and consultant, I am being asked to develop some trainings to try to teach what I have learned. Fortunately, or unfortunately, most of what I am discovering that I have to teach is more about working with people than about any magic or even repeatable formula for performing certain tasks. The high-level tasks are mostly the same every time, but the people, their actions and decisions are the factors that seem to influence the what, how and why I perform those tasks.
How thrilling to find some academic articles to support what my experience is telling me!
-by Sheila Conway on 9/29/2010 at 4:51 PM
I often come back to this page, and this time I noticed the phrase about people as active devices. This to me makes the analogy between people and engineering components a little more strongly than the words in your title.
In your experience, how well do people seem to develop their understanding by using analogy? I struggle myself, and I feel that I must be missing something.
(I tend to seek reports based on experience, and I tend to learn by example, including (slowly) my own experience. I don’t get much from stories that seem to be invented to make a point (changing real names and incidental detail where the writer cannot report them is fine of course).
Your [J-L] reference takes me into psychology which I feel will be helpful.
PS spell check ‘Softwrae’ in your [Hu] reference :-)
-by Bob Corrick on 11/12/2010 at 2:29 AM
Thank you for the informative article. I also found the readers’ comments to be extremely informative.
I loved Susanna Kaukinen comment about knowing people. We know that people are different. What works with a person doesn’t necessarily work with another one. A dilemma arises when you want to manage a group of diverse people, each best suited to a different management style, or each ticks by a different approach. How do you treat people differently and yet keep common rules? But if you do that, you get the maximum productivity of each of your team members, and with a team spirit maintained, the maximum productivity of the team.
Regarding the “People as communicating beings” idea, I agree but need to highlight that team members remoteness shouldn’t be taken as a scapegoat for project failure. Physical proximity matters, yes. But not having should not just mean you lack something, but rather that you need to keep a few things in mind when communicating with that/those team member/(s). I personally find a little awarness and some maturity work things out.
-by Nahla Ghoneim on 1/7/2011 at 7:07 AM
Hi, Sheila! That’s the exact reason my company is called “Humans and Technology” – I get hired for technology reasons, but the dominant contribution is usually on the humans side. Cheers. Alistair.
-by Alistair on 1/10/2011 at 9:39 AM
These ideas made a great impact on me when I read them in your book Agile Software Development several years ago. Still, as I revisit these concepts again in this exposition, I wonder if I’ve really given them enough consideration. I still regard the mechanistic model of process—usually present in the methodologies we call “high discipline”—to be a force fit to the endeavor of software development, regardless that they “can work”. But even Scrum has certain aspects of mandatory discipline—it is “high”? It does seem to be of a different nature, I think, more suited to humans—but why do I think that; what’s the key difference? Characterizing those non-agile processes as “mechanistic” is as close as I’ve been able to capture it.
Perhaps the more important question is where this thinking should lead an organization. Is even a commitment to “become an agile organization”, in effect, imposing a culture that may be inappropriate for many of its members? Should/can an organization instead commit to … ah, the “culture with no name”? A culture defined only by the local consensus of the members of its various parts? Perhaps that is, in fact, largely the realty, despite what senior management claims.
However, I can still believe there is some effective balance point where a company states and reinforces some goals and principles of its culture as well as a small set of practices for people to communicate and coordinate in pursuit of those practices. I suspect that agile concepts provide a good template for such, but perhaps they all need to be re-examined again in light of the characteristics of people that you’ve identified.
Have you looked at “Software For Your Head” by the McCarthys? Perhaps something along those lines is more fundamental to effective teams than even agile concepts?
-by Rich McCabe on 3/30/2011 at 3:59 PM
Hi, Rich! The 1st point I’d like to make is the difference between working with the grain of the human device versus against the grain. So many of our classical process approaches work against the grain, and we should recognize and change that. That doesn’t mean that processes are unimportant (see What is a process good for? (discussion: Re: What is a process good for?)), just we need to be aware of the nature of the humans we drag into the story. 2nd, yes I know McCarthy’s work, attended his class, and yes he’s on something more fundamental, and still insufficient to the questions we’re both interested in. Cheers, Alistair
-by Alistair on 3/30/2011 at 6:35 PM
“How do you treat people differently and yet keep common rules?”. Dr Thomas Gordon has developed Leadership Effectiveness Training to answer that very question. His book is an easy read, yet the framework he proposes is extremely powerful.
And dealing with people invariably leads to change. I recently discovered Gerald Weinberg’s book “Quality Software Management: Anticipating Change” that has some good points on that topic.
Hope that helps!
-by Geoffroy Seive on 5/26/2011 at 2:09 PM
“I would write pretty much the same article today.” Indeed, why tamper with a near-perfect successor to Weinberg, Brooks, and DeMarco/Lister? But I would like to see a sequel of the same depth sometime (that you may have already written — I seen “elephant carpaccio”) on the non-linear client on the other end of the communication link. In a tandem pair of s/w development courses I ran recently, with senior CS students as developers in one course and students in a masters program in product design as clients, moving the students to understanding and delivering client value was not as hard as getting clients to frequently iterate and update the developers on exactly what that value was!
-by Chris Riesbeck on 6/27/2011 at 11:30 AM
_Thanks for that. I periodically notice that there was 15 years between Weinberg/Brook and DeMarco, and another 15 between DeMarco and me. Sobering. I hope it’s not another 15 years before the next person in this line shows up. Sadly, it appears to be, since I wrote that in 2000 (well, 1999), and it’s already 2011. Fortunately, agile development has made the topic palatable, so there are more of us saying these things.”
For the client side of the story, I agree – that will be hard training, indeed. I work with that a bit, but it is harder to corral all the clients and teach them this stuff. :). Alistair
This article is very useful and timely not just for me being the QA Manager in our company, but also for my boss (The President) because we are revamping our people in our Dev. Team and QA Team for them to become more productive. Thanks.
-by Helen Sebastian on 7/18/2011 at 4:20 AM
-by on 7/22/2012 at 1:10 PM
your captcha is broken :p
-by on 7/22/2012 at 1:11 PM
what sort of broken?
Development processes from waterfall through agile have a critical dependency on customer/client feedback, whether the customer is internal or external to the organization funding the development group. The consequence is that whether the time constant is long or short, lacking comprehensive communication with the customer is a consistent predictor of difficulty if not outright failure. Worse yet, failure modes associated with lack of customer/client feedback are rarely detectable early enough to mitigate (citation required, but my anecdotal experiences both good and bad seem to support the hypothesis…).
Unsurprisingly, customers and clients are at least as nonlinear as people, and at least as influential as developers. :-)
In my experience, development managers sometimes have a few sticks but almost no carrots: On relatively rare occasions, process gates are established where client input is required to move forward. Even then, such approvals are considered to be privileges subject to “waiver”, rather than responsibilities that must be discharged for project success.
Is there any research into the topic of client/customer excitement? How might a development organization excite a client organization, internal or external, enough to get their attention consistently through the lifetime of a project?
-by Leonard Samuelson on 7/23/2012 at 3:49 PM
Could it be that the true value in a software development methodology is not the effect it has on the software but in the bringing together of people with a similar outlook?
From my own perspective: I basically learnt software engineering from Ward’s wiki (around the same time this article was published, though I wasn’t aware of the article at the time), and I still find myself agreeing with the same people I did back then, even though the ideas have evolved somewhat.
-by Richard Cordova on 7/24/2012 at 6:33 AM
Your blog is very informative & important :
-by web design,real estate ncr,software development company on 11/18/2012 at 1:10 AM
Thanks for the article, it is immensely valuable and enlightening. One comment about consistency and changing of habits. My father always used to tell me
“Hurry up if you know that you are slow.”
I can’t get my head around people who lack the willingness to exercise some self control. If there is a clear picture of a clean desk in someone’s mind, and someone else offers a plausible recipe of how to accomplish it, how can one reject that? I have a hard time working with such people — that is, with most people, it seems.
-by Matthias Büchse on 1/2/2013 at 10:01 AM
Addendum: I think I have first-hand experience with stepping in and doing the right thing. It is unsatisfying and demoralizing because you work outside your designated responsibility without authorization from above, so even vis-a-vis your success people may treat you with reservation. Also it feels like coercion, as if people are exploiting that you are one of the members who takes on some responsibility. (Some project members only work for the money and don’t realize that they are spending their life on it, and that they might as well make it’s success a priority.)
-by Matthias Büchse on 1/2/2013 at 10:55 AM
It’s 2013 and this post should be still read by anyone claiming experience in work with teams. I am absolutely stunned that i a) forgot about this piece or b) never read it before in it’s entirety.
-by Sebs on 10/22/2013 at 2:11 PM