When

Where

Who

Resources

Being an Agile Client

Clients, not developers, are the key to the success
or failure of projects in this course.
The developers build, as best they can, what the client defines.
This can only work when clients and developers communicate frequently,
intensely, and effectively.

More specifically a client needs to

communicate clearly and effectively an initial product vision

slice that vision into high-value weekly deliverables, consistent
with the constraints of technology and development resource

test the weekly deliverables with real users to gain critical
insights for the product's evolution

constantly reprioritize and rescope the product to ensure
the maximum
minimum viable product
(MVP) is reached with the minimum risk

What Do I Need to Start?

Less than you think, but probably more than you have. You don't need
detailed multipage storyboards and screen designs. You don't need months of
contextual inquiry or market analysis. It's fine to have such things, especially
the user knowledge, but not required.

What you do need to have before you meet your team,
is a very clear specific example that
demonstrates the payoff your envisoned app will provide.

For this reason, my prerequisite for access to an EECS 394 team is
a four-panel storyboard.
This is not the kind of storyboard designers use
to work out the details of user interactions with a set of wireframes.
The four-panel storyboard is a concise at-a-glance concrete example
of your app providing a payoff to a user.

Panel 3 is bigger, because it is the most critical. It's where you demonstrate
that you've gone from
then a miracle occurs
to knowing what the miracle might look like. With a clear Panel 3,
the developers will know what to implement first. With a clear Panel 3, you will know
what you need to user test first.

How Does the Project Work?

You and your developers have five weeks to get from 4-panel storyboard to working
prototype. The heart of the process is
the Build-Measure-Learn loop
.

You meet twice a week with your developers:

A weekly hour-long face-to-face session to review progress and planning the
deliverables for the coming week

These are absolutely critical.

Time and place worked out by you and your developers.

A weekly half-hour midpoint check-in

Videoconferencing is sufficient for this meeting.

After 2 or 3 days of development time, 2 or 3 days before the next face-to-face

These 5 weeks are the last half of the Northwestern quarter, i.e.,

Spring: the month of May plus the first week of June

Fall: the month of November and first week of December

You maintain an up-to-date backlog of user stories. If it's on top, it's the next things
developers will do.

You test your app, as it evolves week by week, collecting and sharing insights
with the developers as quickly as possible.

What Gets Built?

Starting in week one, and continuing for the next four weeks, the developer team
will be delivering to you working prototypes. These are not a mockups of screens,
but working product, albeit using the simplest technologies.

The goal is user-testable deliverables each week. No week should
pass with just back-end infrastructure development.

To get this kind of rapid turnaround, your team will be building either
a mobile web app or a mobile hybrid app. They will not be building native apps.
Mobile web and hybrid have several advantages for rapid testing of app ideas:

Changes can be deployed in minutes. No waiting uploading and downloading to some app store.

Apps can be deployed to both iOS and Android with little or no change.

All the developers in 394 can help each other out when problems arise.

Requirements

You must be able to meet with your team face to face each week for the 5-week period.
Remote meeting via Skype or Hangout is possible but far inferior to being in the same room,
with tables and whiteboard.

The team must be able to describe and discuss the project with me and the rest of the class.
By default, their code is kept in a public
github repository, but you can set up a private
repository at little cost,
as long as I'm given access.

Readings

Being an successful agile client does not require knowing about programming or technology.
It does some thought, a lot of attention, and avoiding some common pitfalls. Fortunately, a
handful of core principles and simple practices have been found to be very effective.
Here are some great easy to read resources.