piclist 2009\01\29\102146a >
Thread: Agile programming (was Re: [P|C] Banksel)
www.piclist.com/techref/microchip/devprogs.htm?key=programming
face picon face BY : Rolf email (remove spam text)



See comments inline....

Vitaliy wrote:
> "Rolf" wrote:
> [snip]
>
> Rolf, thank you for the background, it is very interesting.
>  
welcome ;-)
> 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.
>
>
>  
This is a common misconception about Agile, I know that I have
misconceptions of it as well. You can see that. I also know that "the
company" has investigated the concept and appl;ied some of the concepts
in certain ways, but overall we have not become an agile development
software house.
{Quote hidden}

I'm not going to comment on the details of Agile computing - I don't
know them well enough...
{Quote hidden}

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.). The
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....
>> 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.
>
>
>  
Point taken.
>> 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.
>
>  
our non-agile software process has also garnered many awards, and
continues to do so.
>  
>> unfortunately it is a bugger
>> to integrate with the rest of the system.
>>    
>
> What do you think makes it so?
>
>
>  
The rest of the suite has a common look and feel (return codes on batch
processes, command-line arguments, color schemes in GUI's, etc. This
makes documentation/integration/education much easier). This particular
project uses different programming languages, different interfaces, and
different report formats. While it does it's job fine, it is also
different enough to become problematic.
{Quote hidden}

As I say, I believe our development cycle has aspects of Agile in it,
but it has aspects of other methodologies as well, waterfall being part
of it, and there is rapid prototyping in places too.
> 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.
>
>  
Yes, but not for the reason you insinuate.
> - 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.
>
>  
Partly, but subtly different enough for your characterization to be
misleading.
> - You routinely revise your assumptions and requirements throughout the
> duration of the project.
>
>  
Yes, but again your characterization to be misleading.
> Am I right?
>
>  
Good try.
> 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.
>
>
>  
Sure, Agile may fit the 'natural' model of how programmers work, but try
to make a big bank look like a programmer!
{Quote hidden}

Fine, I'll not comment on the details of the Agile concept....
> - "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.
>  
Fine, I'll not comment on the details of the Agile concept....

{Quote hidden}

Fine, I'll not comment on the details of the Agile concept.... I can see
the advantages to the above sort of approach.
{Quote hidden}

No, my assumption is that building an agile team that had all the
expertise required to fulfill a typical business requirment of ours
would require the expertise of too many people to form an effective
Agile team. This assumption may be wrong, but, doing a quick in-the-head
analysis of recent things I have worked on, they have required the
specialist input of many dozens of people, and since there are many
concurrent projects we all work on, we would all have to be part of
dozens of Agile teams to make things work.... and then you just end up
with dozens of Agile teams competing for access to the resources instead
of a more orderly scheduling/directing/management process. Again, my
understanding of Agile is fuzzy, so I may have just expressed many
myths, but, right now I have about 6 distinct issues 'in the air' that
each in the grand scheme could be an Agile project.
>> 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.
>
>
>  
As I understand it, an Agile team is dedicated to particular business
logic building. In some ways the company has tried it (with some
success), but in other ways, in my area of expertise, it has not been tried.
>> 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
> efficient.
>
>
>  
Size matters. Typically when the client is involved it is a big project.
When the client is 'internal', the project is small. When we have a real
client we are less 'Agile'.
{Quote hidden}

We do that often (unit tests first, code to make the test pass, then
implement continuous regression testing so that it never later breaks,
etc.).
{Quote hidden}

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.
> 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.
>
> Vitaliy
>
>  
We have looked.... and learned some things, and discarded others.


I think, in conclusion, that the thing which makes Agile programming
hard for us is the concept of our client relationship. Take a typical
project....

1. an international regulatory body decides that financial institutions
need to be able to report certain risk metrics (this sort of thing
happens surprisingly often).
2. many of our clients are affected by this, and have a relatively
limited release schedule (couple of years) to get the numbers available.
3. our financial GURU's investigate the regulation and discover various
models that could solve the issues (takes a few months). They then go to
the clients, regulators, and other experts and discuss the models
required, and what limits are reasonable on the expectations of the
regulations. Typically there are issues that need months to resolve,
some issues take longer, much longer, and some issues are never resolved.
4. the guru's then put together an overall plan of what data is
required, what data is not yet available, what computational modeling
needs to be developed.
5. this gets assigned to a project manager who keeps tabs on the whole
excercise. They arrange for the access to the resources they need (back
to the guru's, to business analysts who determine where the data should
come from, to testers who need to develop test data, test routines, and
other infrastructure, etc., the programmers from multiple disciplines,
etc.). This is all really done at the management level, i.e. the project
manager will determine development needs to happen on component X, and
they ensure that the manager for the X component is aware of the
requirements.
6. there is a lot of back and forward as the component managers try to
shuffle their competing requirements to get a viable project plan with
the available resources, and schedule it all in the available timelines
without shifting existing projects, etc.
7. Development happens in earnest with various teams producing their
respective support at various times. There is often interdependence in
the components such that you have to wait for some functionality form
one component before you can return the favour to them with your
functionality. There is some guessing and imagination involved because
you are still waiting for some of the details to be ironed out at the
top design level.
8. Finally we get close to a completed product, and the guru's come back
and hammer away at the system to ensure that all the known functionality
is implemented, etc.
9. various strategioes are used to validate the models from a number of
perspectives, including financial valadation through regression testing,
unit testing, back testing (an art in itself), etc.
10. the software gets shipped to the clients who put it in to a test
environment for 6 months, and run extreme testing of their own because
fundamentally, they are responsible for the results...

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.

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.

Rolf

<4981C971.3050703@rogers.com> 7bit

In reply to: <CCC68380B44847F2B49ED044669809A8@ws11>
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Agile programming (was Re: [P|C] Banksel)

month overview.

new search...