Development roadmap & agility

Hi,

I have a question about general development methods in the context of
agile development.

I'm currently reading 'practices of an agile developer' and it's said
that feedback and interaction with customers are really important.

Imagine you're a developer in a team (not the project leader). You'll
have several tasks to do, let's say
1/ a blog
2/ a pdf generator
3/ a form

You'll have 2 months to deploy your application (others developers have
others modules to build) and a meeting is scheduled in a month with all
the team members and the customer.

Tell me if I'm wrong. An agile developer will write those 3 modules,
even if the code is not 'perfect' (that's to say, perhaps, the 'reply'
function doesn't work on comments in the blog, there are bugs with the
margins in the pdf generator and the form doesn't interact with the db
yet), to have feedback from the customer and the rest of the team to see
if it's what the customer really wants whereas writing a
perfect-tests-passing-with-all-functionalities blog and a semi-generator
pdf? And he will use the second month to proprify the code, write tests,
correct the functionalities among with the objections of the customer
wheras writing the second part of the pdf creator and the entire form?

Thanks for your comments,

Hi Pam, this really depends on the agreement that you have with your
customer. In my prior experience, you would generate a schedule of
deliverables with your customer before starting any development.

This schedule would change if it's agreed upon by both the developing
organization and the customer.

Next, when a deliverable is scheduled to be released to the customer,
it should meet the functionality that the customer defined in their
specification. Thus, it's the responsibility of the developing
organization to get feedback during development before the deliverable
is due. Also, if there's a change in the specification, then it's the
responsibility of the customer to make this aware to the developing
organization before the deliverable is due.

In short, it's the responsibility for both customer and developing
organization to provide feedback and interact with one another during
implementation. If this doesn't exist, then the developing
organization can be building something that doesn't meet the
customer's expectations no the due date.

-Conrad

Hi Pierre,

Pierre-Alexandre Meyer wrote:

I'm currently reading 'practices of an agile developer' and it's said
that feedback and interaction with customers are really important.

Imagine you're a developer in a team (not the project leader). You'll
have several tasks to do, let's say
1/ a blog
2/ a pdf generator
3/ a form

Tell me if I'm wrong. An agile developer will write those 3 modules,

Nope. An agile developer will write the code for the first module, after they'ne confirmed that that's the customer's highest priority and not just an accidental artifact (like maybe somebody just listed stuff in alphabetical order) and they probably won't write all of that. They'll seek feedback from the customer as soon as possible. Way before 'time is up.'

hth,
Bill

Pierre-Alexandre Meyer wrote:

I'm currently reading 'practices of an agile developer' and it's said
that feedback and interaction with customers are really important.

That's not just lipservice. That means you show them your work-in-progress as often as possible, and they review it and tell you if it's done.

If they tell you a given feature is done, you don't argue.

Imagine you're a developer in a team (not the project leader). You'll
have several tasks to do, let's say
1/ a blog
2/ a pdf generator
3/ a form

You'll have 2 months to deploy your application (others developers have
others modules to build)

A team is a team. Everyone should work on all the modules, as they grow. Don't plan-ahead what modules you will need, then distribute them among workers. That causes friction and waste.

and a meeting is scheduled in a month with all
the team members and the customer.

Tell me if I'm wrong. An agile developer will write those 3 modules,
even if the code is not 'perfect'

Don't write for a month before showing anything to the customer. If the customer is legitimately not available for a month (and if your team doesn't mind this warning sign), then appoint someone to be the customer liaison; to research what the customer does and how they work. Let them review the features.

(that's to say, perhaps, the 'reply'
function doesn't work on comments in the blog, there are bugs with the
margins in the pdf generator and the form doesn't interact with the db
yet)

Your list of items was too broad. Don't say "A blog", say "write a post with a date and have it show up. No HTML input, images, replies or anything". That's just one line-item of a blog.

Fully write that one narrow feature, with its GUI, database, and tests, and don't write anything else. Don't throw mud against the wall just to see what sticks. Then let the customer liaison use the feature, and (if possible) put it online so end-users can use it. This usage will quickly reveal what the next feature should be.

, to have feedback from the customer and the rest of the team to see
if it's what the customer really wants whereas writing a
perfect-tests-passing-with-all-functionalities blog and a semi-generator
pdf? And he will use the second month to proprify the code, write tests,
correct the functionalities among with the objections of the customer
wheras writing the second part of the pdf creator and the entire form?

Write the tests at the same time as you write the tested code. Work in iterations of one week, not three months. Seek any excuse to strike any line-item from the feature list. Then make sure all remaining features are bug-free.