I was formally introduced to 'agile' process in 2008, when I found and read Agile Web Development with Rails. The notion of sitting next to user's of your software before, during, and after development begins made sense to me. I had been doing that for 5+ years at that point by talking with users in a county government, and building solutions that met those needs, and then having the luxurious ability to check with those users to see how effective a solution was. I became addicted to the continuous feedback.

Since then, I've been a part of many agile teams, and I've had the opportunity to work with a few organizations on "agile transformation" projects; which basically just means teaching an organization how to operate in a more focused and iterative fashion.

Information on agile is easy to find across the web, and I've seen many flavors of agile practice - some being more right than others, and some being more effective than others, and I encourage teams to focus on what works for them. What I've found is: what works for teams is more about feel than some logical notion of correct agile practice. So, I try not to be too prescriptive, but just share with teams what agile feels like.

• Monday
  • Planning (groom and point stories from the Backlog)
• Daily
  • Standup (what did you do since last standup? what will you do til the next one? any obstacles?)
  • New vs. Support Work?
  • Ensure all works exists in Tracker
    • Update stories often and with enough context to take action (think of your pair and/or your future self)
  • Schedule time and Focus on one item at a time (limit Work-in-progress)
  • Renegotiate your commitments (only one thing can be top priority)
  • Communicate outward in 360º (respond to those who might be waiting, contact those who need to prepare)
• Friday
  • Demo (demo working software openly for the team)
  • Retro (happy/okay/sad)

For me, an agile cadence should feel directed, but clear; potentially overwhelming (if your Backlog is growing), but with a sustained focus on high-value items as early as possible. Most importantly, a good agile cadence lets a team feel responsive and in control over an ever-changing priorities; rather than out-of-control and reactive. As with most organizations, there is always more work to do than time/resources available. Therefore, agile should provide a sense of effective filtering (focusing on what matters), and enough of an opinionated stance to focus on one thing at a time. Trust that small bits of focused user-centered work will provide value to said users, carving the shortest distance between ideation and implementation.