Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
Rolf, thank you for the background, it is very interesting.
What I know about Agile comes from an Agile "bootcamp" I attended about two
years ago, the books on Agile that I've read since, and (somewhat limited)
experience applying it at work. IANAE, but I do know a thing or two about
Agile, and it sounds like when you say "agile", you mean something else.
> When we investigated agile programming we found that it was likely not
> going to fit with our 'culture' because it would actually reduce
> flexibility as we have to regularly switch from development to support
> roles, interspersed with customer interaction and other diversions.
Switching between roles is not a problem for Agile. It is expected that
interruptions will occur, and an attempt is made to make the weekly/biweekly
estimates take them into account. Even combining part time/full time people
is not a problem.
Customer interaction is a must for Agile. Otherwise, you risk delivering a
product that does not meet the customer's needs.
> On the other hand, we have a couple of 'Agile' teams that were put
> together to fulfill specific client functionality where there was no
> existing support for that in the current business solutions. These Agile
> teams were assembled and then sequestered from the rest of us so as not
> to be distracted (actually, a couple of them play opera music to keep
> the pressure down, and we kicked them out because we don't like opera...
You say the Agile team was "sequestered", do you mean that before you were
all in the same room? That's actually what agilists recommend: instead of
every programmer having their own office, they should work as close together
as possible, preferably in a "bullpen" environment. The goal is to reduce
the cost of interaction.
> Still the one team is still going after 2 years, hardly 'Agile'.
I believe this is one of many Agile myths. There's nothing inherent about
Agile that limits the duration or scope of the project.
> And worse, the product they developed has won all sorts of awards, and
> is well regarded in the financial industry,
This is consistent with a survey that DDJ did in 2007: teams using Agile
report a higher success rate than traditional teams.
> unfortunately it is a bugger
> to integrate with the rest of the system.
What do you think makes it so?
What you describe sounds like the traditional waterfall model: you gather
the requirements, then you do the design (on paper), then you implement, and
the final step (not mentioned above) is to test.
Sounds good in theory (to some, to others not so ), but as far as I know,
the waterfall model never works in practice.
I'm going to make a few guesses about the way things work at your company.
- For example, I bet that the Finance Gurus don't simply build the models,
and throw them over the wall. They interact with the people who are actually
going to implement the models, right up to the end of the project.
- Also, you don't build the whole thing all at once, you build it in pieces,
and test each piece. Then you make more changes, and test the pieces again.
- You routinely revise your assumptions and requirements throughout the
duration of the project.
Am I right?
My point is (in case anyone missed it :) that waterfall development
methodology does not work, and that Agile tends to fit the "natural" model
of how programmers work, better.
> Agile development would put together a smallish team to work on the
> whole thing from beginning to end with mini milestones, etc. This would
> not work for us because we often need to get many dozens of people
> co-ordinated to get the functionality available in many components that
> need to be backward compatible for hundreds of other Risk-Management
- The first statement is another myth. Agile is scaleable, even though best
results are achieved in small teams. I've read about projects which were
completed by dozens of geographically dispersed Agile teams (hundreds of
people). It is possible to have several "layers", where for example "product
owners", one from each team, have their own weekly meeting to coordinate the
higher-level efforts. The way it works is the same way you would naturally
break down a large project: by system, by component, by subcomponent, by
- "Milestones" are not an agile concept, it is something you hear about a
lot in waterfall-type projects. Agile has the concept of "iteration": a
short, fixed length of time, at the end of which you must have working
software. Working software, because "code does not lie". Documentation on
the progress of the project often does.
> Basically the scale of development, testing, integration, and regression
> management preclude any one (small) team of people from having the time
> to learn what they need to know to get the job done.
Imagine this: you have your team of, say, ten people working on a small
subset of functionality. There are several other teams that are working on
other subsets. You have short meetings (30 minutes to an hour) once every
two weeks to look at, and prioritize the task list. Your team has a "product
owner" -- basically, a delegate from your team who meets with delegates from
the other teams, to coordinate the higher level task list. If necessary,
this team of product owners can send its own delegate to a yet another
higher level meeting.
You may say this sounds ridiculous, but consider that with a team size of 10
the three levels can coordinate the work of 1000 programmers. If your
company only has 100 people, you only need one extra "layer". Most small
companies only need one.
> While there are people
> in the company that could replace me (and I them), a 'fresh' Agile team
> would take years to gain the collective experience of a bunch of people
> to get the task done, and not also run in to all sorts of compatibility,
> regulatory and other issues.
Your assumption is that you can't use existing people who share this
collective experience, to form Agile teams. Are there any reasons for this,
besides people's natural resistance to "new" ideas?
> An agile team will fail if it is required to disintegrate routinely to
> work on unrelated maintenance tasks. That's basically why it would not
> (does not) fly really well in the areas i work.
Has this been tried at your company? I don't understand why an agile team
would be different from any other team in this regard.
> Still, there are times when we need to build (small) new pograms that do
> whizz-bang things, and we get to do the especially fun stuff of rapid
> prototype development, and then it is close to 'Agile'.
Size does not seem to matter, agile processes still turn out to be more
> For the record, we got a new 'chief' recently up top at work, and his
> philosophy is that maintenance is not much fun, we should all be doing
> agile type development, and we should outsource the maintenance to
> Estonia. Personally I think it would be a mistake because maintenance
> should be the responsibility of the developer if only to ensure that
> they develop maintainable code ... ;-).
I agree with you, you have to eat your own dog food, not feed the Estonians.
I would further suggest that your company should adopt the Test Driven
Development (TDD) approach (another "Agile" thing)
With TDD, you create a scaffolding around your code, so that if you break
something while fixing something else, you know it right away. TDD people
say that you're supposed to write the test first, run the program to make
sure the test fails, then write the code that the test will test. Not too
long ago Timothy J Weber and I talked about ways to make it work for
[EE] Test driven design for embedded applications
I'll admit I haven't tried it yet, although recent bug reports give me
plenty of reasons why I should. :)
In conclusion, if you haven't really looked at Agile, you definitely should.
It can save you tons of wasted effort, and help you produce a quality
product with features that your customers actually find useful.
^ Gerald M. Weinberg: We were doing incremental development as early as
1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's
ServiceBureau Corporation]. He was a colleague of John von Neumann, so
perhaps he learned it there, or assumed it as totally natural. I do remember
Herb Jacobs (primarily, though we all participated) developing a large
simulation for Motorola, where the technique used was, as far as I can tell,
indistinguishable from XP. [. . .] All of us, as far as I can remember,
thought waterfalling of a huge project was rather stupid, or at least
ignorant of the realities. I think what the waterfall description did for us
was make us realize that we were doing something else, something unnamed
except for "software development. quoted in Larman, Craig; Victor R. Basili
(June 2003). "Iterative and Incremental Development: A Brief History" (pdf).
Computer 36 (No. 6): pp 47-56.
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the