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
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
“Getting lost is just another way of saying ‘going exploring.”
― Justina Chen, North of Beautiful
Today, I finished the 25th lesson from Bob Taber’s “Core C# Fundamentals” course. A total of 22 hours of video instruction on the most basic, beginner-level concepts of the .NET framework.
As I mentioned in an earlier post, my novice background in programming, coupled with zero prior experience to object-oriented design, has made this journey of self-study somewhat daunting. The obvious lack of technical knowledge aside, I feel like my questions and observations will be in the realm of irrelevance: that the entire programming world is light-years ahead. Who has time for a novice? I don’t like feeling useless and alone.
Armed with 22 hours of knowledge in writing simple console applications in C#, I have a request: would you be my peer reviewer? Continue reading
I am a terrible programmer.
Or, at least, that’s what I tell people is the reason I gravitated away from code and towards organizational behavior, dysfunction, and systems thinking. I’ve decided not to be a “doer”, but rather, someone who doesn’t actually do anything: an Agile coach. When I think about programming, I feel envious of those that create and master the art of coding. When I think about programming with Agile–and the organizational environment to cultivate amazing people–I sense that I can contribute to others’ realization of success. While that feeling is joyful, I admire those “doers” every day as they build software that delights customers.
(At a recent employer, after my hire, a programmer casually quipped that the company “hired someone who doesn’t do anything to help do something.”) Continue reading