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.
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!
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.
- Think big, define small. Minimum viable product.
- Getting Real from 37signals, a fun free book in PDF.
- Tell a story.
- Storytelling by Design by Kim Goodwin: Scenarios are the big stories that demonstrate value and determine what's important.
- The four-panel scenario storyboard
- User stories, by Mike Cohn: User stories are the units of functionality that developers implement.
- Managing the backlog: How scenarios and user stories connect
- Build, measure, learn.
- Build for rapid evolution.
If you're interested, here's what your developers are reading.