Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
> We have a mostly open-plan office (6 floors of 'loft' style work areas
> with a few offices on each floor for various people who routinely have
> to deal with confidential matters (reviews, conference calls, etc.).
Sounds like a good arrangement.
> one 'agile' project team moved in to the corner conference room to all
> be together, and we now insist they shut the door when they play opera!
> They mostly stick to themselves, we mostly stick to ourselves....
That's funny. :)
>> This is consistent with a survey that DDJ did in 2007: teams using Agile
>> report a higher success rate than traditional teams.
> our non-agile software process has also garnered many awards, and
> continues to do so.
Right, the ratio was something like 65%/75% success rate
(traditional/agile). There are other factors to consider, though -- quality
of the end product, how much it meets customer needs -- which are said to be
in favor of Agile.
Scott Ambler writes the "Agile Edge" column for Dr. Dobb's Journal. If you
have access to the magazine, I would highly recommend you to read his
It sounds like the problems you describe, have little to do with development
> Sure, Agile may fit the 'natural' model of how programmers work, but try
> to make a big bank look like a programmer!
I think the nature of the project is irrelevant. If you have a set of
practices that result in better software, why would it matter whether this
software is used to create financial models, control a spacecraft, or run a
I think I understand where you're coming from. Let me ask you this: right
now, who decides which teams/people get access to the resources? How many
people direct/manage the various projects?
It seems to me that regardless of the development methodology, the amount of
available resources (time, people, equipment) remains the same. It is
possible to multitask in an Agile environment just as well (or better) as
you would in a traditional environment.
However, regardless of the chosen project methodology, it is a good idea to
keep the number of concurrent projects to a minimum. There are two reasons
1. Every time you switch between projects, time gets wasted, because it
takes time to "get in the zone", remember the place where one left off.
2. Switching pushes the completion date of both projects into the future
(makes them both late). In a business environment, getting a product to
market sooner has great benefits. In other words, if you have a choice:
- Release Project A in three months, then release Project B three months
after that, or
- Switch b/w Proj A & B, and release both six months later,
The first choice is usually preferred. This is of course simplified, but in
general if you have many projects, doing them serially rather than in
parallel is usually more efficient.
> Writing the tests first does not reduce bugs, it just means the bugs are
> in the tests, *and* the code, and thus sometimes harder to find.
Hm, having limited experience w/ TDD, I'll try to abstain from arguing, but
it certainly sounds counter-intuitive.
> Getting back to your earlier points where you guessed the way things
> work at my work, well, requirements change over time, regulation and
> models that take years to develop can change too, and the effects can be
> significant in a lot of places, and time is limited to get things to the
> client (in a 2 year delivery schedule, the first 6 months can be
> requirement analysis, the next year can be development, testing,
> integration, and the last 6 months it has to be at the client and
> working reliably). There is no time to wait for the requirements to
> settle before starting the development cycle.
Agile would be perfect for you, then.
>From the Manifesto: "Responding to change over following a plan "
>From the Principles:
"We follow these principles:
"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage. "
> Basically, the way I see it is that our clients can not be 'Agile', and
> this feeds back the whole way through the development cycle.
It's actually one of the Agile FAQs is "How do you interact with the
customer, when he has not bought into Agile?" My answer is -- if there is a
will, there is a way. :) After all, if you show the customer the benefits of
the Agile approach (faster time to market, lower risk, better quality) it is
really a no-brainer. If you don't believe in it yourself, of course there is
nothing to talk about.
I have no personal interest in converting you to Agile -- I'm not a
consultant, and you and I have never even met. I just think that the
principles are sound, they do in fact work, and are therefore at least worth
considering. If it makes you and your company a little productive, everybody
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