XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML As Fall Guy

Hiya,

Yes, although I must point out that there's some differences between
agile approaches, SCRUM being just one of many options. SCRUM is a
methodology, and works best if you have a rough idea of what you're
doing (at the risk of your mentioned technology diversity; only
quality people at the helm can fix that, and they need to be part of
the process just like "normal" developers), but terrible to do any
sort of planning or requirements gathering through. User-centred
design is agile at its core, for example, and there's a bunch of
varieties over the theme.

A few years ago I worked as a consultant in a large government
organisation, and within the constraints of the contract in place we
did everything agile, and I think it went terribly well ... as long as
some thinking and planning had happened by smart people upstream from
where developers implemented and fixed integration. SCRUM, for
example, is supposed to make sure that the planning happens a few
iterations before, so that the architect swims a little ahead (which
is why it's called upstream :) ) *while* being part of the
implementation team. Not all architects can work like that, nor can
not all developers, either. You need the right kind of people. As
always.

And that brings up the skills of the people who's going to inherit the
system once the savvy consultants have left. Most places I've worked
(in Norway, mostly) have negotiated X amount of billable hours for
years after completion, to both fix problems and to train the regular
staff, but in financial dire times, this is the first that gets
chopped. "Don't worry, Barry will figure it out. Somehow. Before, you
know, the launch."

Anyway, the short point is; if you know how to be agile and if the
people involved knows how to be agile and if the customer knows what
it means to be agile (or are willing to learn and take it seriously),
it can work miracles. The weakness is that, just as in Waterfall or
any other model I've ever seen in place, people of various levels of
skill is involved. Some times lower-skilled people thrive once thrown
in the agile pit; other time it makes them even less productive. And
then, there's politics. And social skills. And ... aaaargh, now I
remember why I wanted out, to start over, to do it in smaller chunks.

Big government and enterprises have so far not overcome the problem of
people being people. We put constraints in place that drag lower
skilled people up to a medium of sorts, but it also pulls high-level
people down to a frustrating non-productive level. And what happens
for skills, happens for projects.


Cheers,

Alex


On Thu, Nov 28, 2013 at 11:35 AM, Michael Kay <mike@saxonica.com> wrote:
>>
>> I would be interested if yourself or others have anecdotes of Agile
>> applied to large, complex development projects for tailored software
>> solutions. We may be going a bit off-piste for xml-dev here so please keep
>> it relevant to the list if you do have feedback.
>>
>
> I had some slight involvement a couple of years ago with a successful system developed for online scientific publishing (with MarkLogic at the back end). I don't know the project budget but I would guess over 10m. TDD and Agile played an important part. Although successful, it made me aware of some of the weaknesses: for example it was the only project I have ever seen that was over-tested. In the final stages we were doing performance tuning and it was seriously difficult because (a) internal changes that didn't break any external functionality caused dozens of tests to fail (because they were testing non-visible behaviour), and (b) running a commit took well over an hour.
>
> The other problem with the project was unnecessary proliferation of technologies: the XML pipeline took data through XQuery, JDOM, XSLT, DOM4J, freemarker, ... inhibiting reuse of code and causing much serialization and reparsing. Basic cause was that when software components are free, it's quite difficult to stop each developer choosing their own favourites.
>
> Michael Kay
> Saxonica
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



-- 
 Project Wrangler, SOA, Info Alchemist, UX, RESTafarian, Topic Maps
 http://shelter.nu/blog  |  google.com/+AlexanderJohannesen
 http://xsiteable.org  |  http://www.linkedin.com/in/shelterit


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS