Question to Scott Ambler

[Sunder Ganapathy]

In an Agile software development environment, the programmer is expected to
know a plethora of technologies, like, OOAD, OOP, CRC cards, etc. If the
programmer is expected to do all the things, right from getting customer requirements to delivery, of course done iteratively, is it not expecting
too much from a pair of programmers . Then what is the role of middle management in the whole exercise . When projects were executed with Project managers, Project leaders, System analysts, Programmers and the like, the activities were seggregated with defined roles. How this can be done in an Agile environment ?

[Glenn Murray]

Originally posted by Sunder Ganapathy:
If the programmer is expected to do all the things, right from getting customer requirements to delivery, of course done iteratively, is it not expecting too much from a pair of programmers . Then what is the role of middle management in the whole exercise ...

Your question answers itself when it is not the case that "the programmer is expected to do all things," as is necessarily the case on larger projects. The programmer can work in an agile manner within the (usually) corporate environment. But somebody has to be Linus.

Cheers,
Glenn

[Jeff Langr]

Originally posted by Sunder Ganapathy:
In an Agile software development environment, the programmer is expected to know a plethora of technologies, like, OOAD, OOP, CRC cards, etc. If the
programmer is expected to do all the things, right from getting customer requirements to delivery, of course done iteratively, is it not expecting
too much from a pair of programmers . Then what is the role of middle management in the whole exercise . When projects were executed with Project managers, Project leaders, System analysts, Programmers and the like, the activities were seggregated with defined roles. How this can be done in an Agile environment ?

Most agile shops are smaller shops, with anywhere from 2 to a dozen developers. With so few resources, it makes little sense to have specialists. You will still have experts, i.e. go-to people for specific problems. But there is little on a typical software development effort that should be beyond the capabilities of a seasoned developer. Not wanting to learn how to do OOAD (using CRC cards is a simple OOAD technique that can be learned in a few minutes) suggests that you're not interested in becoming a senior developer.

However, one of the things that developers on an agile team should not be responsible for is gathering and refining requirements. That's the job of the customer-facing team.

-j-

[Lasse Koskela]

Originally posted by Sunder Ganapathy:
In an Agile software development environment, the programmer is expected to know a plethora of technologies, like, OOAD, OOP, CRC cards, etc. If the
programmer is expected to do all the things, right from getting customer requirements to delivery, of course done iteratively, is it not expecting
too much from a pair of programmers .

Note that not every member of the team need to know all the technologies or techniques involved. As long as the team has enough knowledge of each, they can pair with the right people to get the job done and spread that knowledge while they're doing it.

Originally posted by Sunder Ganapathy:
Then what is the role of middle management in the whole exercise . When projects were executed with Project managers, Project leaders, System analysts, Programmers and the like, the activities were seggregated with defined roles. How this can be done in an Agile environment ?

The question is, should it be done at all?

The reason why agile teams don't really have "middle management" is that the middle management is often pretty much "waste" and is effectively slowing down progress instead of supporting it. For example, the classic division to designers and programmers is surprisingly good at preventing personal development and increasing problems with both the design and the implementation due to the communication gap.

[Ilja Preuss]

Lasse is right - an important point of Agile Development actually is *bringing people together* instead of segregating them.

Regarding middle management, I don't think that they are necessarily a waste. As long as they see their job in helping the team self-organize, getting the necessary resources and communicate to stakeholders outside the team, they can be quite valuable!

[Lasse Koskela]

Originally posted by Ilja Preuss:
Regarding middle management, I don't think that they are necessarily a waste. As long as they see their job in helping the team self-organize, getting the necessary resources and communicate to stakeholders outside the team, they can be quite valuable!

True, but how often have you heard someone refer to such a manager as "middle management"?

[Sunder Ganapathy]

You are mentioning in your reply that "However, one of the things that developers on an agile team should not be responsible for is gathering and refining requirements. That's the job of the customer-facing team."

Actually, Mr. Scott Ambler in his AM site mentions that along with Project Stakeholders, Developers are also needed to document the requirements . He says "Include some developers, particularly when you want to start building an understanding within your team of what the system is to accomplish ".

[Ilja Preuss]

Originally posted by Sunder Ganapathy:
You are mentioning in your reply that "However, one of the things that developers on an agile team should not be responsible for is gathering and refining requirements. That's the job of the customer-facing team."

Actually, Mr. Scott Ambler in his AM site mentions that along with Project Stakeholders, Developers are also needed to document the requirements . He says "Include some developers, particularly when you want to start building an understanding within your team of what the system is to accomplish ".

I think Scott is right in the sense that *everyone* who can contribute or learn something to/from gathering and refining the requirements should be involved. The developers certainly belong into that category.

What Lasse might be getting at is that the Customer (-team) needs to have the final say on what the requirements and priorities are.

Kent Beck is known for stating that he sees the segregation of an XP team into a Customer and a Developer site as a flaw. It will be interesting to see what he writes about that in the second edition of "XP Explained"...

[Sunder Ganapathy]

Why an Indian Edition is not available ? We do have Kathy's famous HF series available in India .

[Lasse Koskela]

Originally posted by Sunder Ganapathy:
Why an Indian Edition is not available ? We do have Kathy's famous HF series available in India .

Probably for the same reason hundreds of other books are not available in India. I assume the problem is that the publisher doesn't see enough potential revenue in making the Indian edition and thus won't make a financial commitment to such an endeavour.

[Scott Ambler]

Hi folks, sorry for missing the conversation last week. My wires got crossed somehow and I thought the promotion was in December, not October. Anyway, I'm a regular contributor and will try to make up for it.

Here are my thoughts on the issue (a very good one, BTW):
1. Everyone on an agile project isn't expected to know everything. However, it is reasonable that they be willing to learn new techniques and ways of working, and be willing to work with others. I'm a firm believer that people should strive to be what I call generalizing specialists, http://www.agilemodeling.com/essays/generalizingSpecialists.htm , although others are calling this craftsperson or even "post modernist developer".

2. In many ways agility is more of a mindset or a philosophy � people who want to become agile can become agile over time. Furthermore, agility is situational; involving a business analyst on a multi-site project to represent a wide range of users can be very agile, involving a business analyst on a small, co-located team can be very non-agile. It's far more important, in my mind, to be willing to work with others, to be willing to learn, to embrace change, to seek feedback, and to focus on delivering working software on a regular basis than it is to be the "technology X" expert.

3. Middle management does have a role to play in agile software development, albeit a different one. They should try to support project teams by getting them the resources that they need and by helping to deflect and/or deal with problems as they arise. Good middle managers likely do this already.

4. Agile techniques are being used in a wide range of organizations, in various domains, and on various sizes of teams. Jutta Eckstien has a really good book out right now on agile approaches for large project teams.

Keep an eye out from my January 2005 column in Software Development (www.sdmagazine.com). IMHO anyone can become more agile if they choose to.

- Scott

[Ernest Friedman-Hill]

Originally posted by Sunder Ganapathy:
Why an Indian Edition is not available ?

Indian editions sell for a small fraction of US and European retail prices, which makes it difficult for a publisher to recoup the investment of developing one. Only titles with enormous sales numbers -- and the HF books are about as enormous as Java books get -- justify the initial cost.

Or so I understand.

[Ilja Preuss]

Originally posted by Scott Ambler:
Jutta Eckstien has a really good book out right now on agile approaches for large project teams.

That's Jutta Eckstein - writing it correctly will increase your probably to find the book at your favorite online bookstore...

[Sunder Ganapathy]

Nice way to put it across, Scott .