...
- get the gist of what I'm trying to do or let me know if its confusing (because I haven't done a decent job if the code change is confusing)
- let me know whether the approach I've taken seems reasonable or if there is a better way to do it
- give me a clue if the way I am testing it is missing major important cases
- point out any dependencies of which I might be unaware (e.g., if I change the REST API in a particular way, who might that change impactand is that okay?)
Meetings
Driving considerations
- Cost of a meeting is #min * #num people… adds up fast
- But… more efficient than N*(N-1) individual meetings
- Goal: minimize meeting time, but give us set times when we know we can address full team
- 2nd Goal: Give us check-in periods smaller than a sprint to help us plan realistically
Meeting Schedule
- Stand-up status meetings
- M, W 11:45 --In hallway / my office if phone needed
- Three questions:
- What have you done since last meeting?
- What are you going to do before next meeting?
- What are you stuck / blocked on?
- Identify issues and mechanism to solve them, DO NOT solve issues (unless can be done in ~3 min).
- I will time the meeting… am serious about the 15 min.
- Friday demo meeting
- 4:30, 30 mins
- Same general format, but a bit more time to actually demo progress
- Will time meeting, serious about sending you home for the weekend by 5
- Design / Code review meetings
- Engineers continue to call as needed
- Try to stack up (M,W?) to leave some long blocks of coding time