News

December 5: Final project deliverable due
December 1: Client Demos, Team Advice in Ford ITW. Demo Times
November 30: In-class demos, client advice writing task.
November 18: Iteration planning with clients! Saturday 11:00am Ford ITW
November 10: Iteration planning with clients! Friday 10:30am Chambers Hall (Foster St), lower level
November 9: Ionic testing activity
November 4: Iteration planning with clients! Saturday 11:00am Ford ITW
November 2: Purple / Yellow team demos. Client project demos.
October 27: Meet your clients! 10:30am Ford ITW
October 26: New Team Meet and Prep
October 26: Final Team Project Demo: In-class app demos and wrap up discussion.
October 17: Google visit
October 9: Start of weekly coaching meetings and Retrospective reports
September 26: First demo!
September 21: Hybrid setup report and four-panel storyboard.
September 19 Day One -- What each team needs to prepare for the first day of class!

When

TTh 11am - 12:20am

Where

Tech M164

Who

Chris Riesbeck

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

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:

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:

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.

The app must be compatible with the limitations of mobile hybrid technology.

Interested? Questions? Contact me!

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.

If you're interested, here's what your developers are reading.