Thoughts on technology and innovation
Ted Husted, Release Engineer
In the same way that every US citizen should read the constitution now and again, every Scrum developer should review the actual Scrum Guide from time to time.
Hallmarks of the framework are a prioritized backlog, timeboxed iterations (1-4 weeks), daily scrums, and a review and retrospective to close each iteration (or "sprint").
GTD Backlog Grooming
A great way to manage your time is to use a Getting Things Done workflow. The GTD workflow consists of five stages: capture, clarify, organize, plan, and engage.
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. f Product Backlog items have the attributes of a description, order, estimate and value.
To create and maintain the backlog, we capture every work item in the backlog, we clarify each Product Backlog Item with a definition of success and story point estimate, we organize (or rank) PBIs by business value, plan the next iteration, and ---"Engage, ensign!"
For more about GTD, see Getting Things Done in Wikipedia.
A great way to manage your time is to use SMART objectives, so you don't waste time spinning your wheels.
SMART objectives are Specific, Measurable, Attainable, Relevant, and Timeboxed -- which is literally the definition of a well-written Scrum story (or Product Backlog item).
We specify user stories and a definition of success for each story, to be sure it's attainable and relevant, and measure the effort for each story, as well as our overall velocity for a sprint. We timebox our work into a set increment, and only accept the amount of work that can fit into that box.
The acronym SMART has several slightly different variations: S - specific, significant, stretching. M - measurable, meaningful, motivational. A - agreed upon, attainable, achievable, acceptable, action-oriented. T - timely, time-based, timeboxed.
For more, see SMART Goals in Project Smart.
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. Brief, daily meetings help motivate team members to stay on point and short-circuit churning. If someone is impeded, the standup ensures we can take a beat and reach out for help.
Churning can be a real problem for developers. It's easy to go down a rabbit hole, and keep thinking one more code-build-test cycle will do it. Thirty builds later, you're still churning.
I've been known to set a two-hour timer on my phone, to force myself to take a break from whatever I'm doing, so I don't spend an entire day hitting compile like perpetual-motion drinking bird.
The classic Pomodoro Technique uses an even smaller increment of 30 minutes, but the principle is the same. Don't get lost in the weeds, you need to come up for air regularly.
For more, see Pomodoro Technique in Wikipedia.
Closing the Loop
To squelch the "tyranny of the urgent", Scrum teams take a step back and conclude each sprint with review and retrospective ceremonies.
For more about why Agile uses tight feedback loops, see the ever-popular Project Management Tree Swing Cartoon. (Really, you should!)
On the Other Hand
The inimitable Robert C. Martin presents an alternative view of Scrum and Agile in his entertaining and thought-provoking presentation, "The Land that Scrum Forgot". If you haven't seen it, it's well worth viewing and sharing.
At NimbleUser, we are fortunate to have a strong Scrum culture deeply interested in practicing the framework as intended. We have an experienced and talented Scrum Master guiding our core feature squad, and other Scrum squads focussed on subscriber upgrades and implementations.
Like most folks, we use two-week iterations (synced with payday!), and I'm continually impressed by the effort everyone puts into our blameless retrospectives. Beforehand, we setup a Confluence page with Start/Stop/Continue sections that fills up quickly with suggestions and counter-suggestions, which we discuss at the live meeting.
Following Spotify's lead, we also have several "guilds" where people on different squads can collaborate on shared concerns. The newest is the Developer Experience (DX) Guild, where we coordinate devops tech between feature, upgrade, and implementation squads. Other guilds include Data Management, Training, Technical Writing, Innovation, Software Standards -- and a Social Guild for enjoying the ride outside the office.
My personal tip would be to avoid "Scrum but" like the plague. First, use the framework as designed, and then go for "Scrum plus". A good practice is to set up a copy of the Scrum Guide on your company wiki, and annotate it with how you apply and extend the framework.
And, if you use Scrum, do fight hard for the infrastructure stories. As developers, it's on us to be sure product owners understand -- before the jalopy runs dry -- when we've been too busy driving to get gas.
Great infrastructure is the best way to enjoy the ride!
Does your team practice Scrum (or Scrum but)? Do you struggle with agile, or find that it helps you stay on task? If you could do anything differently on your own team, what would it be?
Ted Husted is a Kaizen Squad developer on the Nimble AMS product crew. "We make the good changes that create a great product." For more, follow @tedhusted on Twitter.