>"Another issue is that, with Agile, a product's development is broken
>down into smaller parts that are completed one at a time. Such an
>approach risks undermining the concept of an integrated total user
>experience, where the different features work consistently and help
>users build a coherent conceptual model of the system."


In this section, Nielsen frames the problem of long-term coherence of
a large piece (or even a suite) of software that Agile techniques
don't deal with directly. I agree with others who have posted that
iterations allow for increased interactions with UX designers and can
actually result in the better UX execution of the feature at hand, but
this says nothing of the risks of long-term serial production of
features.

Nielsen's suggestion that companies store "basic knowledge about user
work flows, personas, and usability guidelines outside individual
projects so it can be reused for years across many projects" seems
sensible, but also requires maintenance, so how do you fit it into the
Agile process? Long-term architectural and UX consistency are concerns
that have been raised by CTOs and technical advisors I've worked with
- how do you embrace change while ensuring you're not producing an
inconsistent patchwork of features?

Refactoring code is different than refactoring user interfaces.  The
impact of changes in existing UI needs to be carefully considered once
a product goes to market.

It's certainly doable.  See the documentation on Yahoo's slow
evolution of the homepage etc, where a rate limiter was applied to the
degree of outwardly visible change.

Specific concern needs to be given to the potential for old learning
to cause errors and for the efficiency of adoption in application
changes.  In the case of a highly used consumer UI, the issues are
more complex.

I'm in general agreement that refactoring UI is required in an agile
process but there's value in grokking a bit of that evolution up front
in order to choose an extensible design and even more value in
managing the nature of that change at a holistic level per release.

--- In agile-usability@yahoogroups.com, John Schrag <john@...> wrote:
>
> Bonnie wrote:
>  > Long-term architectural and UX consistency are concerns
>  > that have been raised by CTOs and technical advisors I've worked
with
>  > - how do you embrace change while ensuring you're not producing
an
>  > inconsistent patchwork of features?
>
>
> I think you do it by embracing the Agile idea of "refactoring".  The
> problem has an exact engineering equivalent:  how do you build a
> software app incrementally without the architecture ending up as an
> inconsistent patchwork of modules?  (And, as a former programmer, I
> can tell you a lot of software ends up that way.)
...

Any new insights into using Enterprise Architect for UI design patterns,
CSS, and capturing constraints (using a set-based approach)? Currently
using Borland StarTeam as a repository for lots of hard to maintain word
docs.

-Dean


--- In agile-usability@yahoogroups.com, "Kirsten Powers"
<kirsten.powers@...> wrote:
>
> For traceability and change impact analysis, Enterprise Architect (
> http://www.sparxsystems.com.au/) can be a great tool. It may be
overkill,
> but I've personally had very good experiences using it in the past. I
> believe you can add your own UI models, and possibly create a custom
UI
> library for reuse in your organization. Good luck... We use Sharepoint
here,
> and I feel your pain.
>
> On 5/17/07, Lacroix, Éric Eric.Lacroix@... wrote:
> >
> > Hi,
> >
> >
> >
> > I'm wondering if anyone could suggest me some tool to maintain UI
> > documentation in regard of traceability and reusability of visual
and Text
> > UI pattern for Developer and Q/A team and of course for designer. So
far we
> > are using Microsoft Word and Microsoft SharePoint to store our UI
documents.
> > We avec more then 100 documents and some have more then 200 pages.
At some
> > point it is a really painful process when we need to make change to
some UI
> > components that are use elsewhere. I was wondering if any kind of
tools
> > available to achieve some kind of visual inheritance and some of
> > traceability graph to evaluate the impact the change requirement.
> >
> >
> >
> > Perhaps, I may be able to build something nice by hosting the Visual
> > Studio designer but this solution will require me some hard work.
> >
> >
> >
> > Cheers,
> >
> > Eric
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

GOOGLE QUERY 1
When a user enters a search term in the Google search field and hits
the search button then some results are returned. To conduct a new
search a user may overtype what's in the search field or they may use
the browser back button to get back to the original Google screen or
they may retype the Google address in the address bar to get back to
the original screen.

Would the inclusion of a reset / clear button be more beneficial than
overtyping / deleting the text in the field / constantly selecting
the browser back button /retyping the Google address?

GOOGLE QUERY 2
When a user first visits Google, the Language tool is positioned to
the right of the search button. When a user conducts a search and
hits the search button they get a display of results. However, above
the display of results (top part of the screen) is the Google search
field + search button but this time no Language tool. For some
reason, it has moved to the bottom of the screen? Would anyone know
why it has been designed like this?

Lee

On Tue, Dec 2, 2008 at 9:29 AM, James Page <jamespage@...> wrote:
> Would be interesting here peoples views on the article.
> http://www.alistapart.com/articles/gettingrealaboutagiledesign

..along with David Malouf's, um, energetic, response:
   <http://alistapart.com/comments/gettingrealaboutagiledesign/>

--
Hassan Schroeder ------------------------ hassan.schroeder@...

Fundamentally, Agile is about delivering business value. The inherent
assumption is that the most important thing a software team can do is
deliver working software. Those of us who believe this have taken up
with the Agile movement and not looked back.

However, from a macro-economic viewpoint the value in software
development isn't always delivering working software. Despite all the
dire predictions about the economy, the US government is still
spending at unprecedented levels. Hundreds of billions of dollars go
into government sponsored software projects every year. Yet, more than
half of those will never deliver working software to an actual user.

So, what is the value of those projects? Why wouldn't they just become
Agile and deliver something useful. The reason is that the real value
of those projects is in their ability to infuse large sums of money
into a large bureaucracy to fuel it's continued existence. Even if
they produce nothing they still keep people in jobs and money flowing
through the economy. If every project had to produce value we would
soon find that there wasn't enough value to be had to justify all of
these jobs.

So, when will Agile arrive? I believe that it already has. So why
aren't we all doing it? Because the economy overvalues software
development. Eventually there will come a day when the market will
value software development services according to the value that they
produce. Once that is true we will have to produce something valuable
or find a new line of work. When will this happen? I don't know, but
it happens in every new market and our day will come.

On Tue, Dec 2, 2008 at 9:29 AM, James Page <jamespage@...> wrote:
> Would be interesting here peoples views on the article.
> http://www.alistapart.com/articles/gettingrealaboutagiledesign
>
> James
>

Adam Sroka wrote:
> However, from a macro-economic viewpoint the value in software
> development isn't always delivering working software. Despite all the
> dire predictions about the economy, the US government is still
> spending at unprecedented levels. Hundreds of billions of dollars go
> into government sponsored software projects every year. Yet, more than
> half of those will never deliver working software to an actual user.
>
> So, what is the value of those projects? Why wouldn't they just become
> Agile and deliver something useful. The reason is that the real value
> of those projects is in their ability to infuse large sums of money
> into a large bureaucracy to fuel it's continued existence. Even if
> they produce nothing they still keep people in jobs and money flowing
> through the economy. If every project had to produce value we would
> soon find that there wasn't enough value to be had to justify all of
> these jobs.

I couldn't disagree more strongly. As long as governments don't just use
the savings from Agile methods to cut spending, then a switch to
delivering actual value would be macroeconomically positive, not negative.

Part of your analysis seems reasonable to me: sometimes the value of a
project to a bureaucracy is in perpetuating the bureaucracy and
advancing the career of its leaders by seeming big and important.

Macroeconomically, though, there's no reason to waste money. Your take
is a common one, but among economists it's known as the "broken window
fallacy":

     http://en.wikipedia.org/wiki/Parable_of_the_broken_window

It's true that during a recession the government shouldn't cut spending,
as a counter-cyclical fiscal policy can lessen the length and severity
of a recession. But the only reason to do a low-value project is if
government is already spending all it can on higher-value projects. I
guess that's theoretically possible, but off the top of my head I could
name project after project that would be more beneficial to the public
than the typical large-project development failure.

Your analysis also neglects the human cost. If we employ a lot of people
in jobs that are essentially valueless, then we've in effect trained an
entire time-wasting army. So not only do we lose the resources spent on
the individual project, but we severely impair the future productivity
of the workers involved.


Despite having advocated XP since 2000, I have never seen a company that
used the efficiency gains to cut staff. Instead, they find other things
for people to do, and better ways to spend their excess money. There's
no reason governments couldn't do the same thing.

William

On Tue, Dec 2, 2008 at 12:54 PM, William Pietri <william@...> wrote:
> Adam Sroka wrote:
>> However, from a macro-economic viewpoint the value in software
>> development isn't always delivering working software. Despite all the
>> dire predictions about the economy, the US government is still
>> spending at unprecedented levels. Hundreds of billions of dollars go
>> into government sponsored software projects every year. Yet, more than
>> half of those will never deliver working software to an actual user.
>>
>> So, what is the value of those projects? Why wouldn't they just become
>> Agile and deliver something useful. The reason is that the real value
>> of those projects is in their ability to infuse large sums of money
>> into a large bureaucracy to fuel it's continued existence. Even if
>> they produce nothing they still keep people in jobs and money flowing
>> through the economy. If every project had to produce value we would
>> soon find that there wasn't enough value to be had to justify all of
>> these jobs.
>
> I couldn't disagree more strongly. As long as governments don't just use
> the savings from Agile methods to cut spending, then a switch to
> delivering actual value would be macroeconomically positive, not negative.
>
> Part of your analysis seems reasonable to me: sometimes the value of a
> project to a bureaucracy is in perpetuating the bureaucracy and
> advancing the career of its leaders by seeming big and important.
>
> Macroeconomically, though, there's no reason to waste money. Your take
> is a common one, but among economists it's known as the "broken window
> fallacy":
>
> http://en.wikipedia.org/wiki/Parable_of_the_broken_window
>
> It's true that during a recession the government shouldn't cut spending,
> as a counter-cyclical fiscal policy can lessen the length and severity
> of a recession. But the only reason to do a low-value project is if
> government is already spending all it can on higher-value projects. I
> guess that's theoretically possible, but off the top of my head I could
> name project after project that would be more beneficial to the public
> than the typical large-project development failure.
>
> Your analysis also neglects the human cost. If we employ a lot of people
> in jobs that are essentially valueless, then we've in effect trained an
> entire time-wasting army. So not only do we lose the resources spent on
> the individual project, but we severely impair the future productivity
> of the workers involved.
>
> Despite having advocated XP since 2000, I have never seen a company that
> used the efficiency gains to cut staff. Instead, they find other things
> for people to do, and better ways to spend their excess money. There's
> no reason governments couldn't do the same thing.
>
> William
>

I think you misunderstood my intentions. I was attempting to describe
the current situation and why I think Agile has not been more widely
adopted. I was also trying to discount the premise of TFA that current
economic conditions compel us to be more Agile. I was not arguing that
the current situation was reasonable or valid.

It is possible that government projects could adopt Agile and produce
more value. It is also possible that government projects that don't
produce value could cease and that those people could find productive
jobs elsewhere. I was merely making the case that there is currently
no economic force compelling them to do either. (I also made the point
that software development is overvalued and that when its valuation
becomes more realistic other factors may be more compelling.)

BTW, there are a lot of government projects that do produce value and
many that have adopted Agile. However, these are not the majority by
any stretch. Also, the same situation can and does exist outside of
the government. I think that government tends to be a refuge for these
projects, however, because their oversight is not motivated by
profitability.

Hello, Adam.  On Tuesday, December 2, 2008, at 3:37:25 PM, you
wrote:

> So, what is the value of those projects? Why wouldn't they just become
> Agile and deliver something useful. The reason is that the real value
> of those projects is in their ability to infuse large sums of money
> into a large bureaucracy to fuel it's continued existence. Even if
> they produce nothing they still keep people in jobs and money flowing
> through the economy. If every project had to produce value we would
> soon find that there wasn't enough value to be had to justify all of
> these jobs.

Huh? Value isn't a finite quantity that projects draw down. Projects
[can] /create/ value.

Any project whose sole value is that it is causing people to be paid
would be of more value if it also built something useful.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The fact that we know more today, and are more capable today,
is good news about today, not bad news about yesterday.

On Tue, Dec 2, 2008 at 1:35 PM, Ron Jeffries
<ronjeffries@...> wrote:
> Hello, Adam. On Tuesday, December 2, 2008, at 3:37:25 PM, you
> wrote:
>
>> So, what is the value of those projects? Why wouldn't they just become
>> Agile and deliver something useful. The reason is that the real value
>> of those projects is in their ability to infuse large sums of money
>> into a large bureaucracy to fuel it's continued existence. Even if
>> they produce nothing they still keep people in jobs and money flowing
>> through the economy. If every project had to produce value we would
>> soon find that there wasn't enough value to be had to justify all of
>> these jobs.
>
> Huh? Value isn't a finite quantity that projects draw down. Projects
> [can] /create/ value.
>

Yes, but what compels them to do so?

> Any project whose sole value is that it is causing people to be paid
> would be of more value if it also built something useful.
>

Can it be that some projects create /sufficient/ value to justify
their own existence but not as much value as is /possible/? And, what
if a project provides sufficient value (to someone) without providing
value in the form of working software?

P.S. More to the point: much of the value in working software is that
is satisfies some business need. What happens if my business has more
budget for software than it has need?

On Tue, Dec 2, 2008 at 1:53 PM, Adam Sroka <adam.sroka@...> wrote:
> On Tue, Dec 2, 2008 at 1:35 PM, Ron Jeffries
> <ronjeffries@...> wrote:
>> Hello, Adam. On Tuesday, December 2, 2008, at 3:37:25 PM, you
>> wrote:
>>
>>> So, what is the value of those projects? Why wouldn't they just become
>>> Agile and deliver something useful. The reason is that the real value
>>> of those projects is in their ability to infuse large sums of money
>>> into a large bureaucracy to fuel it's continued existence. Even if
>>> they produce nothing they still keep people in jobs and money flowing
>>> through the economy. If every project had to produce value we would
>>> soon find that there wasn't enough value to be had to justify all of
>>> these jobs.
>>
>> Huh? Value isn't a finite quantity that projects draw down. Projects
>> [can] /create/ value.
>>
>
> Yes, but what compels them to do so?
>
>> Any project whose sole value is that it is causing people to be paid
>> would be of more value if it also built something useful.
>>
>
> Can it be that some projects create /sufficient/ value to justify
> their own existence but not as much value as is /possible/? And, what
> if a project provides sufficient value (to someone) without providing
> value in the form of working software?
>

Hello, Adam.  On Tuesday, December 2, 2008, at 4:57:10 PM, you
wrote:

> P.S. More to the point: much of the value in working software is that
> is satisfies some business need. What happens if my business has more
> budget for software than it has need?

Never seen it happen but if that were true you could spend less or
contract to do software for someone else.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Accroche toi a ton reve.  --ELO

On Tue, Dec 2, 2008 at 2:36 PM, Ron Jeffries
<ronjeffries@...> wrote:
> Hello, Adam. On Tuesday, December 2, 2008, at 4:57:10 PM, you
> wrote:
>
>> P.S. More to the point: much of the value in working software is that
>> is satisfies some business need. What happens if my business has more
>> budget for software than it has need?
>
> Never seen it happen but if that were true you could spend less or
> contract to do software for someone else.
>

Where I have seen it, in the context of government, it looks like
this: The process of Undulation is very expensive. It costs the
taxpayer millions of dollars every quarter. We would like to develop
the Super-new Obfuscated Undulator (SOU) so that we can increase the
speed and reduce the amount of error in typical Undulations thus
reducing costs. Congress has allotted umpteen million to this project
and we have contracted Gratuitous Spending Corporation (GSC) to come
up with a design. GSC has told us that they will spend the next two
years designing the project after which we will return to Congress to
ask for more money.

A couple of things about this hypothetical project:

1) The agency is quite capable of continuing to do "Undulation" the
way they have always done it. It is expensive, but they have the money
and will continue to get the money as long as they ask for it.

2) The project is justified by the perception that it could reduce the
cost of existing processes. Lower costs are good. Thus, it fills a
real need and it is easy to justify the additional expense in terms of
future value.

3) The process is a black box. GSC walks away with the money and has
very little to account for in terms of what happens to it. At most,
they need to have a plan outlining how the money will be spent and
they need to deliver some documents showing that someone spent some
time thinking about a solution.

4) The agency's continued funding depends on it's continued spending.
It too is not very accountable for what happens to the money so long
as it can outline a plan and deliver some documents saying what
happened.

5) All that anyone really cares is that the "Undulation" gets done
regardless of how it gets done or how much money is wasted in the
process. Thus, there is no force /compelling/ success. Regardless of
the success or failure of the software project business will continue
as usual. In fact, in the long run occasional failures produce greater
revenues for the agency. So long as "Undulation" continues this is
good for business.

I won't get into specifics, but this is something I have seen first
hand at more than one government office. It is also part of the reason
that I used to live in DC and now live in Los Angeles :-)

--- In agile-usability@yahoogroups.com, "Adam Sroka" <adam.sroka@...>
wrote:
>
> P.S. More to the point: much of the value in working software is that
> is satisfies some business need. What happens if my business has more
> budget for software than it has need?
>

Then your business needs to learn to better budget ;)

aacockburn wrote:
> I thought Nielsen's article was notable enough to comment on point
> by point. Not much to disagree with, but I hope a few things of
> note for both programmers and UX/UI specialists.
>
> http://alistair.cockburn.us/Nielsen+on+agile+and+usability

OK, I'm just catching up with this thread.  I just got around to reading
http://www.useit.com/alertbox/agile-methods.html and the statement "For
a project to take interaction design and usability seriously, it must
assign them 'story points' (i.e., resources) on an equal footing with
the coding" jumped out at me.  I see that Alistair has also touched on
this.  I like Alistair's response, but I'd like to approach this from a
different direction.

First of all, story points do not represent resources applied.  They're
an estimate of the work required to accomplish a small but measurable
increment of functionality.  This work has never been just "coding."  At
the very least it includes testing and acceptance by the Customer.  If
the functionality includes a change to the UI, then figuring out what
that UI change should be is also part of it.

Many shops don't have UI experts, so figuring out that UI change falls
to the developer and the Customer having a discussion and making a
decision.  Yes, this sometimes results in a terrible UI from a usability
point of view.  The good news is that, if you're working in small
increments in an iterative fashion, you can always revisit this and
change it.  If it's bad enough, this usually happens.

When there is a UX/UI designer, their work is too-often treated as an
up-front requirements definition phase, handed to the development
process as a /fait accompli/ to be developed without any further
discussion.  The problem with this is not that it's not "Agile," it's
that it sabotages the benefits that people seek when they adopt Agile.
The Customer might have made some subtle adjustments to the
functionality of the story, and the pre-designed UI might no longer be
so appropriate.  The precisely-defined UI might be really expensive to
develop, and a much cheaper approach might be approximately as good.
And, if the story is never scheduled for development, this up-front
design is completely wasted.

It appears to me that the only way to get the Agile benefits of
balancing needs and costs to get the best bang for the buck, is to move
this UX/UI design work into the incremental, iterative development
cycle.  That doesn't mean to create a separate story card for UI design,
and then another for implementation.  The completion of the story
includes the UI design, the implementation, the testing, and the
acceptance by the Customer.

"But," some designers protest, "we need to do usability testing with
mockups to know which is the best design."  Well, perhaps.  On the one
hand, with enough experience you might be able to design a "good enough"
UI without this step, particularly if you know it can be changed in the
future.  Doing the usability testing with live code, rather than a
mockup, might provide better feedback because it tests the concept
as-implemented, rather than as-conceived.

Sometimes, of course, we just won't know enough to jump right to code.
This happens with coders, too, and we have a tool to deal with this
situation.  That tool is a "spike."  This is a time-boxed exploration to
learn what we know we don't know.  For a coder, it may be coding up an
alternative implementation to see if it will work, or if it will provide
advantages.  For a UI/UX designer, it may be creating and testing a
low-fidelity prototype.   It's time-boxed because it's not directly
producing value--it's producing knowledge that we must then leverage to
produce value.  Our goal is to answer some questions, not produce the
best possible prototype.

Hmmm... This is getting a bit long for an email.  I'll finish it on my
blog: http://blog.gdinwiddie.com/2008/11/28/agile-usability/

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

A colleague and I published an article in better software magazine
last month about integrating agile and UCD. We are both keen followers
of this group and would love some feedback on the article.

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&ac=384

Thanks,

Jon Dickinson
Accolade Consulting Ltd

www.accolade-consulting.co.uk

Jon Dickinson wrote:
> A colleague and I published an article in better software magazine
> last month about integrating agile and UCD. We are both keen followers
> of this group and would love some feedback on the article.
>
> http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&ac=384
>

Hi, Jon. I think that's a great article. I especially like the point
that they are both philosophies, not methods.

One minor comment: it's not just agile developers who are prone to just
delivering software without regard to whether it's really valuable. I
think that's a universal problem for developers, whose main unifying
characteristic is knowing how to write code. If I had to guess, I'd say
that agile developers are less prone to that than the population in
general, but my sample may be skewed.

Overall, though, I think you've done a great job of expressing the value
of both approaches in a way that people familiar with just one (or
perhaps none) could see why they matter.

William

Hello, Adam.  On Tuesday, December 2, 2008, at 4:53:02 PM, you
wrote:

> Can it be that some projects create /sufficient/ value to justify
> their own existence but not as much value as is /possible/?

Of course. All projects create less value than is possible. Many
create sufficient value.

> And, what
> if a project provides sufficient value (to someone) without providing
> value in the form of working software?

Then it wouldn't make much sense to have a software project would
it?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The practices are not the knowing: they are a path to the knowing.

On Wed, Dec 3, 2008 at 8:25 PM, Ron Jeffries
<ronjeffries@...> wrote:
> Hello, Adam. On Tuesday, December 2, 2008, at 4:53:02 PM, you
> wrote:
>
>> Can it be that some projects create /sufficient/ value to justify
>> their own existence but not as much value as is /possible/?
>
> Of course. All projects create less value than is possible. Many
> create sufficient value.
>
>> And, what
>> if a project provides sufficient value (to someone) without providing
>> value in the form of working software?
>
> Then it wouldn't make much sense to have a software project would
> it?
>

Except that it is the Emperor's New Clothing. They have to believe
we're selling something or we don't get paid. Software is the perfect
thing to be selling, because no one is quite sure what it is (The
magical stuff that the internet is made from.) And, everyone already
expects us to fail (After all it's /really hard/.)

I'm being cynical, and you don't have to join me. On the other hand,
cynics are people who have seen how screwed up the world can be.

Hello, Adam.  On Thursday, December 4, 2008, at 12:02:31 AM, you
wrote:

> Except that it is the Emperor's New Clothing. They have to believe
> we're selling something or we don't get paid. Software is the perfect
> thing to be selling, because no one is quite sure what it is (The
> magical stuff that the internet is made from.) And, everyone already
> expects us to fail (After all it's /really hard/.)

Well, to operate that way, wouldn't one have to be living a lie?

> I'm being cynical, and you don't have to join me. On the other hand,
> cynics are people who have seen how screwed up the world can be.

Everyone with their eyes open sees how screwed up the world can be.
The question is what do you do next.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Find the simple path to what works and follow it,
always looking for a simpler path. -- Patrick D. Smith

On Thu, Dec 4, 2008 at 6:15 AM, Ron Jeffries
<ronjeffries@...> wrote:
> Hello, Adam. On Thursday, December 4, 2008, at 12:02:31 AM, you
> wrote:
>
>> Except that it is the Emperor's New Clothing. They have to believe
>> we're selling something or we don't get paid. Software is the perfect
>> thing to be selling, because no one is quite sure what it is (The
>> magical stuff that the internet is made from.) And, everyone already
>> expects us to fail (After all it's /really hard/.)
>
> Well, to operate that way, wouldn't one have to be living a lie?
>

More or less.

It is a mob mentality. The more people you have working on something
the less stake they have individually. Add deep hierarchies and long,
slow feedback loops and you have an environment where no one has any
personal responsibility.

I think a lot of software people just want to build things. If the
"architect" comes and says, "I need a component that takes these
inputs and produces these outputs, and I need it in six weeks," they
are content to do that with little stake in how that relates to the
business and the success of the overall project.

I think the blame for mismanagement generally lies with such
"architects" and whoever is pulling their strings. Sometimes it is
malicious. Sometimes it is incompetence. Sometimes you have True
Believers who are sure that what they are doing is the Right Way to
develop software even though they've never personally seen it succeed.

>> I'm being cynical, and you don't have to join me. On the other hand,
>> cynics are people who have seen how screwed up the world can be.
>
> Everyone with their eyes open sees how screwed up the world can be.
> The question is what do you do next.
>

Personally, I make as much noise as I can and then try to get the next
gig lined up. At some point I'd like to settle down and take some
responsibility, but that hasn't been in the cards yet.

Let me make clear: I am no way arguing for exhaustive, up front documentation.  I recognize the value of the Agile mindset and processes (that’s why I am starting this thread).  However -- for many knowledge work applications -- I believe that “iteration zero” (or -1, or whatever a team chooses to call their earliest phase) should be an extensive, elaborative time for design research, exploration, and analysis in order to arrive at a shared “big picture” vision that is much more expressive and comprehensible than a product’s high level, initiating charter.

1. What do you see as the right length for an iteration zero?
2. How is an extensive iteration zero different from the research and design segments of a phased process?
   
3. Why isn't the whole project a time for design research, exploration, and analysis in pursuit of a big picture?

Hi:

I've recently started a new position for a small company that is beginning
to take on web development projects which is outside its core business.

I was amazed at the lack of planning, design and processes that were in
place for the first project I was on so I have proposed many improvements so
that future projects work better.

One of these was the adoption of an agile based approach as I have used
SCRUM before on larger projects and have seen how well it can work.

The issue I have is that the projects that we will undertake are small (1 -
2 developers over a month or so) and so don't really require the full Agile
approach (pair programming, dedicated business user). I have proposed
therefore, a lightweight alternative which picks out the parts of Agile that
I think can be used to good effect (rapid development, welcoming changing
requirements, less documentation etc).

My first question is, do people this this is a good idea?

Secondly, my boss is concerned about managing these changing requirements
and the commercial side of things. I have proposed that we generate a high
level design document, price against that and then allow for business
feedback to be fed back into the development cycle.

He is concerned about scope creep, change requests etc. and I would like
some other views on this if possible?

-Merlin The Happy Pig
--
View this message in context:
http://www.nabble.com/Agile-suitability-query-for-small-projects-tp20888171p2088\
8171.html
Sent from the Agile Usability mailing list archive at Nabble.com.