My exploration of “Starter Agile” practices through the lens of Joshua Kerievsky’s “Modern Agile” concludes with this final group of three practices: standup meetings, task decomposition, and cadence-driven retrospective!
Disclaimer: this is my favorite set of practices to critique! Let’s dive in! Continue reading
An exploration of “Starter Agile” practices through the lens of Joshua Kerievsky’s “Modern Agile” continues with: burndown charts, product backlogs, and user stories. Continue reading
After sharing my thoughts on the insights Josh Kerievsky offers us through the lens of “Modern Agile,” I had a few readers request some insight into why I selected certain practices as “Starter Agile.” The comments walked the line between curiosity and concern, the latter being something I want to help alleviate.
Over the next three days, I’ll discuss nine practices and concepts that could be considered outdated as people continue to learn and experiment with Agile. I argue these topics have transitory value for brave folk learning Agile; a good place to get started… but others have discovered better ways exist.
Today’s first set of practices: timeboxes, story points, and velocity. Continue reading
From the point I first discovered Agile in 2005, Joshua Kerievsky has been one of my “self-invited remote mentors”. In other words, Josh provided guidance and mentoring from afar through his writing and speaking – and without the slightest idea of who I am.
A few weeks ago, I finally had the opportunity to meet Josh at Agile Open San Diego. In the confines of open space, Josh convened a session that invited participants to explore his recent “Modern Agile” paper, which formulates a new lens of thought into the evolution of Agile over the years. (If you haven’t read “Modern Agile”, you’re missing out – do that first!)
On the second day of open space, Josh convened an additional session to explore a juxtaposition of “modern” versus “antiquated” Agile. This got me thinking: is it harmful for us to label some practices “antique”? Continue reading
About two years ago, I met a marketing professional at an Agile conference and we had a lengthy conversation about creativity and ways to encourage innovation. After sharing with him the Cognitive Network Model taught to me by Dr. Robert Briggs, he responded that his firm was using “a drinking game“–sans drinking–before every major client presentation. In his opinion, the mechanisms of the game seemed to align perfectly with Dr. Briggs’ theory: as images are called forth in working memory, particularly in new combinations, people generate thoughts they didn’t have prior – leading to new ideas.
A drinking game for creativity? I had to know more! As he explained the game, I realized this short, twenty-minute activity had all the elements of a good Agile activity: fun, collaboration, and useful lessons. Continue reading
Practice C# program number two is progressing. If you feel brave and opt to inspect the Github link provided, you’ll probably feel the same awkward sense of confusion at the use of “progressing”, however.
This post is a call–or plea–for help. My console-calculator program is an attempt to discover how I might use object-oriented design and expand my technical knowledge. At this point, I feel as though I’m regressing into the same patterns that limited me ten years ago. In addition, I’ll share my thoughts and feelings as a novice trying to learn programming on my own – and what lessons I’m extracting for Agile coaches. Continue reading
I recently hosted a learning event for Agile in the San Diego area and had an interesting conversation with an energetic young woman looking to find a ScrumMaster job. During our chat, among other concerns, she lamented on the number of companies that have asked her to justify the role as a full time position.
She’s certainly not the first person to run into this question: many popular Scrum practitioners have posted their thoughts and insights to this query. A common sense line of thought points to the prescribed role defined in the Scrum guide, while further highlighting the need to be economically pragmatic. These seem like safe, surface level thoughts to me. I’d like to try something different: a ScrumMaster is a team coach, and like all coaches (in an Agile work system, not just Scrum), no — the role must not be a permanent position. Continue reading