The Quick Brown Fox

My week in Agile practice and learning: Abandoned Start with Why . Went back to The Coaching Habit . Scheduled a vision meeting for the teams with the chief product owner; this was a pain point raised in our most recent retrospective. The message was received by the teams, I think, with well-deserved caution given our organizational history. Now I must ask myself how I can help them achieve their goals.  Listened to the Agile for Humans 010 (great discussion of fast agile and extreme programming) and 011 (cross-over with Agile Coffee, so that's another one for me to check out, plus I was reminded about tastycupcakes.org. So many resources, only one me.). AND to meta-cast 121. Lot of podcasts this week. Attempting to focus on active listening .  Held a meeting with the product owners to discuss issues raised by the teams at last week's retrospectives. Not entirely pleased with how it went; too much agreement in principle, too few action items, too few voices in the conver

Individuals and interactions over processes and tools. What a simple and profoundly revolutionary statement! Away with standardization, and with the idea that people are fungible "resources." Processes and tools are static things; individuals are alive, ever-changing, and their interactions cannot be predicted. We are told moreover that this focus leads to better outcomes, that people produce better things than things can produce other things. There is still a place for process and tools, but those things work best if they can be made to imitate the state of life, of constant adaptation.

I put this one on my to-read list as it seems to be hyper-popular in the Agile community. This one fits into that idea space easily, with its premise that people are far more effectively motivated by internal and intrinsic forces vs external ones -- that once the basic needs are met, people start wanting more intangible rewards. This plays very well with the idea of self-organization and devolving decision-making power to lowest possible level in your company.  Autonomy, mastery, purpose -- simple enough to fit on an envelope, and like so many simple things, a stone bitch to make work in a concrete setting. It's an optimistic book, and I want to like it, but I did find it frustratingly short on implementation ideas. Sure, if I ever go out and start my own company, I'll be sure to keep this in mind, but for those of us toiling in traditionally structured companies, what are the options? Other than buying our CEO a copy to leave on their desk, I suppose. If we long for purpose

One reason I started this blog was in order to make sure that my own work is visible to me . I recently explained to one of our coaches that I find it difficult to feel like I'm getting anything done in this job. I come from a role in which I could at the end of the day point to milestones met and deliverables done -- could print out my day's work on actual paper. Scrum Mastering is not amenable to that, and it's one reason I have hesitated to leap into the role full-time. Will I be able to cope with the lack of concrete achievement? He suggested that a blog would make a useful record, so I am going to experiment with this. Sprint retrospectives - turned up a ton of impassioned feedback Raised awareness with dev manager - teams feel a lack of strategic information (he came through, and I filled out a thank-you card) Raised awareness with release coordinator - current deadline is not feasible (or fair)  Encouraged team members to prioritize their health over unrealis

Today is my Scrum Master anniversary! I got my certification back in May of last year, but it was on this day in 2016 that I was voluntold into the role (which I jumped at, although not before telling the manager in question that he was never to do that again). It has been quite a year. I have often entertained the thought that the CSM certification is basically your entrance point into apprenticeship. The mechanics are one thing, but you're not going to learn how they work except by doing it, and that's going to be a multi-year process. It has been a rewarding year in a lot of ways. I've balanced being a Scrum Master with my existing role in the company (do not recommend that as a practice) and only lost my temper about it a few times. I've led what feels like a million meetings -- standups, retrospectives, backlog refinement sessions.... I've done a lot of new things -- went to the Agile Games, did some impov there, read a lot of books, met some cool people, l

We are uncovering better ways of developing software by doing it and helping others do it. What is a manifesto? Literally, it is a list, in this case a list of guidelines. What does the first line of the manifesto communicate? That the subject is not abstract, but is based in lived experience (doing it). It is pragmatic rather than hypothetical (better as opposed to best, perfect, etc.). Being rooted in experience and individual context, it will not look exactly alike to any two people.  Agile practice is subject to change and growth (uncovering is an unbounded process). I am confident that 20 other people would not have reached the same conclusions as these did, and that even if those same people were to meet again now, they might easily reach a different place.  It is rooted in the exercise of creating software. Application to other environments should be approached with caution, and should be guided by empiricism rather than attempting to fit one solution as-is to all p

This is a generally great podcast, and when I have time I try to go back and listen to some of the older episodes. This particular one was rough -- it was still finding its feet, and the conversation was of a kind that sort of frustrates me in the agile community. There's a lot of discussions where it seems like people are asking for a definitive when the answer is always going to be contextual, or else they're arguing with a practice that doesn't actually exist. I generally find myself on the side of if something isn't useful, then stop doing it, or experiment with doing without it; if it's valuable to you, keep doing it. There's no sense in getting upset about how other people are doing it either way. Outside of the podcast, the estimate discussion is interesting to me because at my company, we have still not really hit our stride with the backlog grooming/refinement process, and estimation tends to be bound up in that. Our meetings tend to be a bit single-m

This is a new blog I'm starting in order to keep track of my thoughts about Agile practices and philosophy, and the Scrum Master work I'm doing at my own place of employment. I began this work approximately one year ago, and if I've learned anything since then, it's that there's always more to learn....