CanAgileMethodsGetInTheWayOfProblemSolving

I ran across a very interesting article

http://moosehead.cis.umassd.edu/cis580/readings/AgileProblemSolvers.pdf

Could it be that the high degree of communication encouraged by agile methods is just a tool? And like all tools, it's more appropriate for some jobs than for others?

The article also goes so far as to suggest that, when these agile methods are taken as a universally "Good Thing", we may actually be discouraging those individuals that can contribute substantial value in non-agile ways. And such non-agile contributers may actually be highly effective in ways that teams practicing agile methods cannot.

ChrisHofstaedter 2005.05.24

See BestPractice and UsefulPractices

MikeMelendez 2005.05.24

Paraphrasing - agile methods may not support good problem solving.

In my experience, a lot of programming effort is spent doing something other than coming up with solutions for hard technical problems. --DaveLiebreich 2005.05.24

The article invokes the ghosts of great problem-solvers past (Newton, Aquinas) and asks if they would have felt at home in an Agile project. The question whether they would have felt at home in any team effort - or for that matter in any modern corporation - is not asked.

A wonderful quote from the article:

"Since software engineers must solve problems that are more concerned with things than people, generally a concern for things is an advantage. Even when the problems appear to be more about people, such as a graphical user interface design, the software engineers can best analyze and solve them if they think of these problems as involving things."

How's that for circular reasoning ?

In addition, the article assumes without argument that you are either a "people" person or a "things" person, with nothing in between; and that being good at one detracts from being good at the other.

Agile methods can get in the way of problem-solving; just not in the simplistic way the article's author is assuming.

LaurentBossavit 2005.05.24

As I read it, the article's key contention is

"A programming methodology should accommodate the working style of an organization�s best programmers�and agile methods may not. Agile methods could push people who excel at problem solving into the background, giving center stage to programming
team members who can talk well but might lack the analytical skills necessary to do the difficult design and coding tasks."

I disagree. A methodology facilitates delivering things of value to customers for reasonable costs. If a methodology that doesn't cater to the "best" programmers works better than one that does, so be it. And if you have members of a software development team who aren't up to coding tasks, you have an entirely different problem, regardless of whether you're doing Agile or not (though Agile methodologies tend to flush out "talkers" fairly quickly).

The idea of organizing surgical team around a star performer works in some situations (like, say, surgery), but it's a risky model. For one, you might not be able to hire stars. And if you do, unless you can get their skill distributed around the team, you suffer from a low Truck Number risk. If the star walks, you're toast. You're more likely to be able to staff a project with merely good people. Agile seems to work quite well with good people.

DaveSmith 2005.05.24

I certainly agree that the stereotypical "Chief Surgeon" model carries too many risks to be viable. I also agree that the a great many of the tasks performed by development teams are not "deep problem solving" tasks for which this "solo-problem-solver" may offer distinct advantages. Nonetheless, isnt there a place for both personality types on modern development teams? Or is the "solo-problem-solver" a dinosaur in today's development world?

Does the "methodology" have to cater to one type versus another? Wouldnt there be benefits to accomodating both types within the team's development practices. Or is this just oil and water?

Also: Agile methods can get in the way of problem-solving; just not in the simplistic way the article's author is assuming. - Could you elaborate on this one a bit?

ChrisHofstaedter 2005-05-25

Agile methods rely on teamwork. They're intended for problems too complex for one individual to solve. And I do mean "complex", not "hard". One person can solve the Poincar� conjecture. It takes more than one person to understand and simplify a complex, "problem rich" environment, say, air traffic control.

Agile methods will get in the way if you use them to solve problems better suited for solo work. That's different from saying that agile methods will "marginalize" individual problem solvers in a team.

LaurentBossavit 05.05.26

Laurent writes Agile methods rely on teamwork. They're intended for problems too complex for one individual to solve. And I do mean "complex", not "hard".

Laurent, I suspect that a higly skilled invidual could produce the required software but the production schedule would NOT be acceptable to the customer.

From what I see, the customer who engages an agile team has had too many software failures. Software that doesn't work looks like a speed rather than quality problem to the people at the top of the organization.

The tops are willing to try anything to solve this production problem. They are happy to tradeoff both quality and economy for speed. And agile teams have a process that responds directly to that need.

I'm sure that the proponents of agile methods would argue about the nature of the tradeoff. Some would say it produces higher quality software. Some would say that the it is the most economical method for production. Some would say that the customer comes out ahead in every dimension. Perhaps. But regardless of the results of those arguments, I believe the desire of the people who make the decision is speed.

If I were marketing agile methods to the tops, I would focus my story around producing functional software at the fastest possbile speed.

My apology for the thread drift. I started with another thought but the above came out. Maybe that's the nature of any thread about agility.

SteveSmith 2005.05.29

Chris,

I'd give a qualified yes to the idea that "agile methods" is "just another tool."

If it's not "just another tool" and Agile is always the best solution, then it's a "silver bullet" by definition. And there are no silver bullets.

The qualification is that I've never seen agile methods implemented "by the book", so I may be missing something.

WillSargent

I'm working with a client where some Agile techniques would be quite useful. Others would be much less so -- or even impossible, given their clients. They brought me in because they wanted to implement a particular Agile technique (test-driven development), and didn't understand why no one wanted to. To be honest, I cannot imagine how to help them implement test-driven development (because of their product's architecture and implementation). But other techniques, such as nightly builds would be quite useful.

Too often, I hear about Agile techniques as a solution, rather than people first seeing what the problem is. -- JohannaRothman 2005.05.31

I just tried to read the article. It's full of non-sequitors, starting with the equating of "the best programmers" with Isaac Newton. And factual errors or distortions (like Newton was not a cooperator because he didn't get along with some of his contemporaries--he got along fine with others, and they weren't building programs not communicating face-to-face, but by snail mail of the time). It goes on from there with vague assertions, logical errors, and fuzzy reasoning.

Look, there's no silver bullet. And there's no silver anti-bullet. After fifty years, I've heard enough of this crap. Any method can produce good results; any method can produce lousy results. There are no "thing" problems, but only people problems. If you use a method that doesn't fit your problem or your people, that's a people problem, pure and simple. - JerryWeinberg 2005.-5.31

Jerry,

Your post is both absolutely right and deeply scary, because I hear it two ways.

The first way is "Pick a method that causes least problems for your team." The second way is "Pick the people to suit the method."

I've heard both statements advocated in blogs, both with a degree of alacrity. I've heard agile methods condemned as a shill, and I've heard speculation that people who don't like paired programming are mentally defective.

This is an emotional issue. Managers make (or are being told to make) hiring decisions based on specific methodologies. The original article is badly written, but it's polemic. The question it's skipping around is not whether Agile works or not, but whether it's socially acceptable to say that it may not work.

WillSargent 5/31/05

Back in the day, it wasn't socially acceptable to say that the big paper & control based methods might not work. I found the position of advocates & gurus curious then as I do now. If your method of choice does not have the possibility of failing, well then you are superfluous, are you not? There is no case to be made, and no need for experts. Anyone can take the method, do the thing, and have success. This is the often unspoken appeal of the new methods of the moment to much of management, an appeal that is exploited by methodo-hucksters of all stripes. Makes me wonder about the advocates, hucksters and gurus.

Johanna's tale above is an example of things coming full-circle, where the method-du-trend is a panacea grasped in desperation, perhaps, and abdication at least. Your job as development manager is to, well, manage development so we all get what we intended from the effort. While the managers involved are culpable, they have company. The staff who aren't getting things done, or if they are, who have allowed the relationship with their management to erode to the point where the guys on hand doing the work are not seen as either the most trusted or the most expert. Pathetic. Of course the hucksters-du-trend are as culpable for hocking their automation / policy / tool chain discipline (Test-Driven Development) as a panacea, along with their superficial-humanist posturing.

Ghaaa. Take a good idea and crank it through the "technology buzz-word life-cycle" from observation & often powerful insight, through slogan to descrediting label. This, too, the agilist advocates have in common with the big-banger formalists. The pity is, there's some damn fine material and even better observations in both camps, if we would but listen. Nearly impossible now that we have "camps" of course.

Again, Ghaaa. Me, I'll go back to building stuff (successfully by a number of measures) mainly by stealing good ideas from anywhere I can find them.

-- JimBullock (Is stealing from the best required, or does it simply up your odds of finding something worth stealing?) 2005.06.01

There may not be a silver bullet, but there are lots of things that most of us do not do which can help you succeed. For example, I believe that specifying all your goals and then ensuring that each is measurable is generally a good idea for any project expected to take substantial resources. Also, avoiding the big bang theory of development where the first deliverable is produced at the end of the project seems a generally wise guideline.

Karpinski [email protected] 3 June 2005

As usual, I'm with Dick, and Jim, and Will. Maybe the problem is that we choose computers because we think they will save work. They will save work (or can), but not for the programmers. It's our job to save work for others, by being successful. Let's do the simple, well-know things first, as Dick says, and then, perhaps, we can look for, and work for, incremental improvements. At this point, it's safe to say that although some total revolution may come that elminates programming work, after 50 years of hearing promises, I'm not holding my breath. Just do the job, and do it well--and applaud all those who are doing it. Let's give them a little attention for a change. - JerryWeinberg 2005.05.04

Kathy Sierra discusses paired programming (or the lack of it):

WillSargent 6/8/05

Updated: Thursday, June 9, 2005