Travis CI set up notes -- how to set up the Travis Continuous Integration server for building React apps and deploying to Firebase
Quick, React! -- my first draft at a modern React tutorial. Ready for review. Post questions, bugs, requests, on Piazza.
Learn React Task -- a personal activity to help everyone learn (or practice) building React apps the modern way
React: Old vs New -- a demonstration of how functional React is simpler to code than old React.
First Demo Task -- due Tuesday
Team React Setup Task and Four-Panel Storyboard Task -- What each team needs to have done before the second class!
Day One Task -- What each team needs to be ready to present on the first class!


TTh 11am - 12:20am


Tech A110


Chris Riesbeck


Retrospective Reports

Continuous improvement is an essential aspect of agile development. It doesn't happen automatically. It involves each team, no matter how smoothly things are running, taking time every week to identify the most important area for improvement, discussing and making some change, and tracking what happens to see if the change helped or hurt.

In agile, the meeting or portion of a meeting to do this is called a retrospective (The Agile Samurai, section 10.5). Retrospectives can be hard to do well.

Agile retrospectives are a good way to test how well you, as an individual understand and can apply agile thinking (values, principles, common practices) to real team and product development problems. Agile thinking means

Therefore, every week, every team member will submit a new retrospective, as described below. I will enter comments and scores before the meeting, if possible. These reports will be part of our coaching meetings.

Scores are from 0 (no entry) to 5 (really impressive insight). Expect terrible scores early on. Be happy if you get a 4, post on Facebook if you get a 5. The sum of your top 4 retrospective scores at the end of the quarter will be added to your team score.

You may think AngularJS coding or configuring push notifications is hard, but I have seen all students struggle far more with retrospective analysis than anything else. It's a form of critical reasoning that requires frank self-assessment and clear evidence-based analysis.

Retrospective Report Process

Every week the team submits an updated report, using the retrospective workbook described below.

An email with a link to the new sheet in the workbook is due the day before our weekly coaching meeting.

I try to review, comment on, and score your reports before we meet.

Setting Up Your Retrospective Workbook

Every team has a retrospective workbook on Google Drive. See Canvas for the link.

Put your names on the first row of the first page of the workbook. This will populate the column headings for the other pages in the workbook. This is the only editable section of the first page.

Weekly Report

Each week, the team fills in a new page in the workbook. Each team member, individually fills in his or her column, answering the questions posed for each row.

Do not delete or modify previous pages. I need those for review.

The Progress row is special. One entry here for the entire team.

When the report is ready, the team sends an email to my Northwestern address:

Due: 24 hours before our coaching meeting. Earlier is always fine. Just email when ready, but don't forget to email.

How to Do Well

The focus is on specific issues (metrics that matter), that have arisen for specific reasons, with a relevant, agile-friendly change to try, and specific ways to tell if the change has a positive net benefit.

Many process changes look good on paper but have very bad results, and are definitely not agile-friendly

Some advice:

An Example Analysis

People are late for meetings.

Attendance is the number one issue most teams raise in classes with team projects. And probably the most common fix I see teams propose is some kind of "shaming" for lateness, e.g., keeping a lateness board, making late-comers buy pizza, making late-comers where a "late" hat, etc.

The most important thing to realize is punctuality / attendance is not a problem in and of itself.

Not doing a process is not a problem. Problems are failures to achieve goals. A process per se should never be a goal.

Imagine a team whose members were always late to meetings, but that produced high quality code week after week and enjoyed doing it. What effect do you think those proposed process changes will have on such a team.

Further analysis is required.