Jason,
There's not really a whole lot I can add to your
post. But to address a couple of your points:
> characteristics. I was curious if those
projects have resulted in
> production (released) software, and if the companies could be publicly
> cited?
> production (released) software, and if the companies could be publicly
> cited?
The very nature of projects of this size, is such
that their release schedules are not in the days or weeks ahead. Or in the
past. So I'm afraid, I can't cite client names, or describe their projects
in any degree of detail. I'd love to - and perhaps these companies will
step forth on the list and discuss their own implementations; but I don't
necessarily expect them to.
My apologies.
> I¹m very conflicted by your positioning in this response, and that¹s why I¹m
> asking you if you can remove the veil on these clients you reference. The
> terms ³agile practices² and 30+ developers are paradoxical, wouldn¹t you
> agree?
Agile, by definition, is about developing software in short
> iterations of 1 to 4 weeks. 9 women can¹t have a baby in 1 month, no matter
> what they try. Likewise, I can¹t imagine the project management nightmare
> of having 30 developers crank out iterations in 1 to 4 weeks.
I didn't say that 30 developers were all working on
the same iteration of development. Careful application architecture, a
well-defined framework for development, good coding standards, collective
ownership, a strong emphasis on unit-testing and continuous integration, all
enable the modularisation of a project of this size into a number of almost
concurrent mini-projects, each of which can be delivered by "agile
teams".
In a specific project we're engaged with right now,
the developers within the organisation are all engaged in parallel iterations of
development, on different modules of the same overall application.
Each teams' iterations are aligned, each team
continously integrates into the same code-base, yet the average team size
working on any given iteration is within the magic numbers that you rightly
specify - 4-6 people. I've personally worked on agile teams as big as 10
developers, with 4-week iterations, and would agree that this is getting to as
big a team-size as you'd be comfortable with.
> Agile
> development promotes face to face communication over written documents.
> That must be one helluva meeting room to have 30 developers ~LOL~.
> development promotes face to face communication over written documents.
> That must be one helluva meeting room to have 30 developers ~LOL~.
There is a pragmatic approach here; each
team (working on their own iteration)
has a morning standup meeting with their
4-6 developers. Meanwhile, a representative of each team engages in
a company-wide standup meeting with the business stakeholders. This ensures the necessary granularity of
team-wide discussion while ensuring that teams are aware of project-level issues
and opportunities.
This allows the agile approach to
scale.
And just to be
clear; I'm not suggesting ever that agile development is the only way to deliver
these projects. Other teams have their own methodologies, based on their
own experiences, and they'll work for them. But agile works for
us.
> Agile
> development contends that customers and engineers work together in a single
> workspace, some refer to it as the ³bullpen² though we always preferred the
> term Bat Cave! 30 engineers plus customers in one space doing 1 to 4 week
> iterations? Perhaps these folks are doing pair programming (!) so there are
> really only 15 engineers on the project ~LOL~.
> development contends that customers and engineers work together in a single
> workspace, some refer to it as the ³bullpen² though we always preferred the
> term Bat Cave! 30 engineers plus customers in one space doing 1 to 4 week
> iterations? Perhaps these folks are doing pair programming (!) so there are
> really only 15 engineers on the project ~LOL~.
The approach to pair-progamming is also pragmatic,
on a story by story basis. And yes, there is a customer on-site to whom
the development team have permanent access.
> I¹m not looking to pick a fight with this post, but merely inquiring about
> the feasibility for you and your team to publish white papers that back
> these positions up.
> I¹m not looking to pick a fight with this post, but merely inquiring about
> the feasibility for you and your team to publish white papers that back
> these positions up.
When I propose whitepapers, I'm proposing
technical whitepapers around unit-testing, continuous integration, architecture
of large Flex applications,
etc.
There are other books/whitepapers that cover agile
development in large teams; it's not high on my priority, nor do I feel
particularly compelled, to "back the position up".
With regards to the remainder of your email,
casting doubt on the existence of the projects that I'm mentioning here, I'm
afraid there's little more response I'm prepared to enter into here. I'm
not presenting my findings to a journal without citation here, I'm merely
sharing anecdotal experience in a mailing list.
I'll share as much experience as I can from
real-world engagements, but individuals will have to choose either to accept
that client confidentiality will always be a factor in ongoing developments, or
choose to discard the discussion until the projects are live (which may be
several months in many instances).
It's also worth noting that many of the projects on which we are engaged (as I'm
sure has been your experience) will never be client-facing, but will deliver
internally. We're building applications, not
websites.
I'd hope that having the discussion now without
citation, has value for the majority, who would rather have some discussion than
none at all.
Best wishes,
Steven
--
Steven
Webster
Practice Director (Rich
Internet Applications)
Macromedia Consulting
EMEA
Office: + 44 (0) 131 338
6108
Mobile: +44
(0) 7917 428 947
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
| Web site design development | Computer software development | Software design and development |
| Macromedia flex | Software development best practice |
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
