Not sure how many people do or don't get into a good flow at work. I wonder how many do versus how many don't. Currently I imagine that not many places have a good development flow. Instead they have more of the wait, talk, wait, wait, wait, now develop really fast type flows.
I was just brainstorming and attempting to think of a good flow. So far this is what I've come up with. Starting in the morning, going through the day of a normal week long or maybe 2 week long iteration.
An agreed arrival time is met, let's say 9:00am is promised by the team. A quick stand up begins at this time.
Stand up should consist of NOTHING more than this is what I did yesterday (that the group needs to know), what I'm doing today (regardless of what one might think affects someone else), and what I'll plan to get to tomorrow. Then, after those three quick items, mention the road blocks & concern for roadblocks that are anticipated for the day.
9:15 am IF needed, otherwise don't do this step. Review burn down chart, priorities, and what other elements of the project will need reviewed for the day. Identify members external to the development teams and break off for those meetings.
9:20 am Begin individual dev efforts. I'd prefer TDD style with a pair partner, maybe not to sit side by side, but each do respective work and either swap or mix up each others assignments on a frequent basis.
During the course of this morning work session if user stories are needed, clarification is needed, or any questions come up they should be asked immediately to whoever the primary stakeholder of that information is.
…contextual notes:
In no way should user story meetings need to go over 10-15 minutes. Long design sessions just mean that information will be lost and these elements will need returned to. It is better to have working code and product in hand of users than it is to have some fancy design. At the same time however, in stark contrast to this is the need to keep in mind the architecture. Depending on were, and in what way, the working code touches other parts of the architecture the design might need to be discussed separately than a user story design session. Either which way, the overall meeting should NOT go over for extended periods of time. Design sessions and user story clarification should be quick, and foster communication that is to the point, fact finding, and then production of working code for that user story should ensue.
sarcasm alert: unless of course you DON'T want a fast moving development effort.
…end of contextual notes:
Noonish – lunch – foodz – sustain life – etc.
Last minute events should be:
30 minutes before departure for the day one wraps up by making sure there are no incomplete work stories in progress and commits all code. Anything that actually needs to continue the next day needs to be noted for the following day at stand up. If all tasks are completed the same should be done.
The first and last days of the iteration.
The only exception to the above work flow for the day should be on the first and last day of an iteration. The biggest difference is user story meetings, clarifications, discussions, architectural planning, and burn down chart maintenance should be done at the beginning of the iteration. This should be when bug fixes, architectural changes, and other big picture items should be discussed and planned for the ensuing iteration.
At the close of the iteration a clean, building, operable drop of the application needs to be made. A test deployment and initial regression test should be performed by end of day on iteration end. The quality assurance process then continues testing for x days and begins immediate bug and issue tracking that will feed back in to the next iteration.
This, is as I see a smooth flow for reaching fast, sustainable, and got morale based throughput. If anyone has any thoughts on this I'd love to hear were this breaks down. I've made a an effort to keep this description relatively simple, but would love more input. Anybody from the peanut gallery?
