This is the fourth part of my series explaining how Don’t Panic Labs approaches project management through the lens of a software release cycle.
At this point we have our items identified, estimated, and ordered for the release. It’s now time to schedule our iterations.
We generally use one week iterations, which we’ve found to be long enough to get tangible work completed but short enough to allow us to quickly pivot or react to things that inevitably come up.
Weekly iteration pre-planning meetings are held one day prior to our iteration planning meetings. The product owner, project manager, lead architect, and QA lead meet to discuss progress on the currently scheduled items, triage any new items that have come up over the last week, and plan for the next iteration. We determine if we can continue down the path originally planned or if we need to adjust current plans.
Our iteration planning meetings with the team are used to communicate the work items scheduled for the iteration and to make sure they understand the scope of work assigned.
If the path to implementing a work item is unclear to the engineer, the first task we’ll have them do is create a whitepaper that describes the problem, offers options to solve it, identifies the possible risks and mitigations, provides their recommendation for solution(s), and lists a task breakdown of the work required to implement the recommended solution along with estimates for the tasks. The whitepaper is then reviewed by the lead architect and possibly other members of the team. When the direction is decided upon, any tasks resulting from the decision are created and assigned, and the engineer begins work. We’ve found that this exercise not only helps in finding clarity with the problem, it’s also a great learning opportunity for the engineer to develop their critical thinking skills to solve complex problems. To keep this process manageable, we ask the engineer to time-box their work on this to one day or less.
Throughout the iterations, we hold daily standup meetings. We schedule these in the mornings and keep them to 10 minutes or less. Engineers and QA leads give an update on yesterday’s progress, today’s plans, and any issues they have run into. We also ask the product owner if they have any updates for the team. This meeting gets us all on the same page for the current day’s project activities. It’s amazing to me how people who sit next to each other don’t talk. Almost daily, something comes that leads to a clarification across the team or to a conversation after the standup. We find these meetings invaluable.
There’s a lot more I could say about the benefits of daily standups over other types of team meetings, but instead I’ll refer to a post that Doug Durham wrote last year about what standups are and how we use them.
After all the required tasks are completed and we’ve released the latest version of our software, it’s time to reflect. But I’ll save that for my last post in the series.