Explore | Research | Apply | Report | Teach
So far, I haven't found the ideal iteration length, though I believe that a solid workflow is the key to setting up each iteration. The teams ability to self-organize around the workflow ends up dictating an appropriate sprint length. In terms of workflow, I've found it best to lock down requirements at least halfway through the prior sprint. If you do that, then it sets the workflow in motion way ahead of time, and limits any overlap within the workflow during sprint. This also limits the discovery during the sprint, which naturally reduces churn between product and the engineers, QA and product, and engineers and QA.
I believe in Kanban so much, that I taught my mom how to apply it to her everyday, non-programming tasks.
While I appreciate the efforts of Trello, or similar online kanban systems I prefer a system based on post-its. They tend to be portable enough to easily move through the stages of "not-ready", "ready", "in progress", and "done".
As an engineer, or a leader of an engineering team, its important to understand that engineers are inventors. Really good inventors need to concentrate and, therefore, distractions typical to an office create invention inefficiencies. Given that information, engineers should limit the number of meetings, and find creative ways to limit these inevitable workplace distractions. Identifying and measuring work-flow state is one way to do this; in the facebook movie they called this being "wired in", and in competitive running they call it "in the zone". Its all the same - ask yourself how many consecutive hours you're working without distraction. Don't add it up across the whole day, either. Chances are, unless you're already measuring this, you're under or around two hours. Part of that two hours is figuring out where you left off, and at the end of the two hours, maybe you're typing notes to yourself to remind what needs to be done next. Maybe, if you're good, you'll have another hour that day to pick it back up.
But, even so, what if you could push those hours together? You're automatically 33% more efficient. And, then if you can extend this time out from 3 hours, you have a legitimate chance of actually keeping up with your work. So, the key here is to really be honest with your time tracking for a few weeks and identify your own (or your team's) weaknesses and main distractors. Things like: e-mail, mid-day meetings, manager distractions, and TPS reports.
Data-driven analysis of team performance is essential for keeping iterations on track, and maintaining focus on the objective. Statistics and graphs are easily made from a list of tickets to provide up to the minute status and focus points within a technology project. For example, a redesign of this site in 2012 would look like the photos below. Click below to enlarge.
Communication within a team is a critical component to improving quality of the product. Today's teams are dynamic: even the best plans tend to get interrupted by influences outside of the project team. When a team member leaves, for instance, the ramp up of a new resource becomes very costly. The easy fix for this is to establish a high level of documentation and communication between the team members, and the communication outward to stakeholders from the beginning of the project.
Taking some time at the end of an iteration for documentation, or technical release notes, or a solid review of what impact changes have on customers and stakeholders sets the table for subsequent product changes. More to come....
Rather than quantify what it means to improve yourself by 1% each day, its more of an approach to life and work. Wake up and be better than yesterday. Be a better spouse, son, manager, employee, friend, brother. Just, do it.
Or just be lazy and do it once a week, so that after 50 years of doing it you're only 172 billion times better than yourself today. Never underestimate your ability to change.