5. Quick development work is driven not by speculation
but by features which emerge from user behavior and
requests.
6. Quick development work is driven not by speculation
but by features which emerge from user behavior and
requests.
Easily responding only to real needs and present
energy (passion) means there isn’t as much to think,
plan or worry about.
7. Agile practice radically closes the gap between
the product and the customer, the build and the
idea, the developer and the business.
The nature of the internet demands this
new approach.
8. TCP/IP, HTML, HTTP, XML, SMTP, etc...
The internet technologies create an agile platform
completely eliminating the traditional barriers of
software deployment allowing massive and instant
distribution of an application.
9. TCP/IP, HTML, HTTP, XML, SMTP, etc...
The internet technologies create an agile platform
completely eliminating the traditional barriers of
software deployment allowing massive and instant
distribution of an application.
The internet infrastructure itself facilitates the
unprecedented connection and self-organization
of otherwise disconnected groups of people.
10. Let’s build in HTML!
• Agile but WAY too limited
• ASP, PHP? nice try...
• ASP.NET? Microsoft, agile? (sorry Mark D.)
• Java? oh what could have been.
11. Ruby on Rails?
Quick easy, enculturated in agility. A high level
language and a pragmatic framework which
allows developers to stop worrying.
12. Developers thinking about
value,
usability,
accessibility,
managability,
communication
stop worrying about
memory management,
garbage collection,
state machines,
db management,
virtual machines,
what they know,
etc.
14. Developers are the
medium experts
• •
Inspired by user input Medium experts like a
along with the rest of the potter to clay, skilled web
team in regular review devs should know what
sessions. makes sense as a web site
and what doesn’t. If they
• don’t they’re of very
People people. Even the
limited value.
most “anti-social” of the
Rails community (i.e. Zed
Shaw) are still pretty
sociable guys.
16. Stories
• •
Pragmatic, human Coorespond closely to
articulations of specific actual user requests
features
• Describe something that
• A hybrid between use can be achieved in less
cases, scenarios and than 2 weeks by 2
straight requirements developers working full-
statements time.
• •
An low loss interface The first, not only
between users and specification tool.
developers
17. Frequent Releases
• Should probably happen in under a month but no less than a week.
• Several things to consider when determining the length between
releases and may vary from release to release
• “Feature Complete”
• Bug free
18. Release Meeting
• •
Assemble full team to Discuss developer
review new features at challenges faced in this
each release. release.
• •
The primary forum for Run format usability
development of the testing if such a process is
product and business. implemented.
• •
Discuss and document Create a new set of
what has emerged stories for the next
through the use of the release.
new release.
19. Recommendations
• •
Set target date for first Create a brief wireframe
release and release mock-up which covers
meeting. only this first release
• •
Craft a list of stories Assemble and engage
which fit cleanly into this team
first release.
21. How do you build for an
audience when you don’t have
one yet?
22. Focus on finding one first.
• The good news: the internet makes finding
the right people easier than ever
• Finding your audience will make it much
easier to spread the word about your
product
24. Seduction...
• leads to “oh sh*t!” the morning after
• is “push”
• seldom leads to marraige
• requires too much lip gloss, too much
peripheral effort
25. Attraction...
• takes more time
• is “pull”
• is enjoyable too, but lasts longer
• is the best path to a long-lasting relationship
• requires transparency
26. The need for an audience is
why agile practice begins with
marketing (of a new kind).
28. Let the “trusted network”
build the trusted network.
• Be a good listener; create a safe place for
your customers to communicate with each
other and with you
• Let the public create their own solutions,
draw their own conclusions
• Build a platform that’s flexible over one that
appears finished and complete
29. Allow new users to both
discover and co-create value.
• Communicate value and let the public
discover it for themselves
• Don’t over-define the site’s purpose. Leave
some room for resourcefulness
• Know when to get out of the way
31. Some of the current themes
are informative (at best).
• “make your problems go away”
• “we take the pain and expense out of...”
• “...tired of useless ratings and questionable
advice?”
• “frustrated by businesses who don’t call you
back?”
32. Language should attract those
who will jump into action
• “Discover great local service”
• “Share your experience”
• “Recommend providers to friends or
colleagues”
• “Set up your own shop in 5 easy steps!”
33. Avoid US versus THEM
• Don’t rely on past negative experiences in
order to inspire
• Don’t be a bandaid for an old wound, be an
opportunity to co-create a new
organization, a new market
34. Connect your audience
through common interest
instead of by definition
• Open channels for users to find their own
ways to connect. (favorites, user
recommendations, etc.)
• Don’t pre-define the future
• Blur the lines between commercial and
consumer. (Downplay the “professional”
aspect. Don’t discourage quality sellers,
students or free-lancers)
38. Recap and Recommend
• Start talking today about how to attract an
engage an audience from day one
• Assemble and define team
• Define a first release target date
• Sideline the existing PDF mock-up
• Sideline the existing code base
• Define a release
