About 9 months ago, I transitioned out of IT Recruiting and into my current role as an Agile Project Manager. I was full of textbook knowledge and eager to start on my Agile journey, but mostly still uncertain of exactly what to expect or what the job entailed.
The past 9 months have flown by as I day by day begin to fully understand my job; mostly through trying things out, messing up, and hopefully learning from my mistakes. One thing I can tell you for certain is that at a minimum, the dev teams I support see that I try on a daily basis to help them out and to drive us towards continual improvement. I refuse to be the APM that merely facilitates meetings and enforces the “Agile process”; I want to be seen as a valuable member of the team, and what that requires to be seen as valuable means two different things to the two teams I support.
So back to the point of this topic. When I started out, I kind of assumed there was a “right way to do Agile” and the lens that I viewed my teams through was basically, is that the proper way to do things or are we doing it wrong? Nine months in and I can now tell you that it’s the wrong way to approach coaching an Agile team.
Through my self-studies (I’m prepping for the PMI-ACP and typically have 2-3 books I'm reading all at the same time) and even presentations from Agile Day Atlanta, I’m learning that it’s really more important to “Be Agile” rather than “Doing Agile”. What do I mean by that? I’m glad you asked. It's about developing an Agile Mindset rather than following a specific set of processes.
I started out wanting to make sure we were “Doing Agile” and following all of the ceremonies correctly and doing things a certain prescribed way. Certainly if we followed the recipe we would build better software right? Something funny happened though; it didn’t always work out that way and the team didn’t always respond to textbook Agile.
I attended Agile Day Atlanta this past Friday, and our keynote speaker was Doc Norton. He gave his talk on the “Experimentation Mindset” and the more I’ve learned about Agile, I’m starting to realize that it really comes down to two things: Experimentation & Learnings.
Why do we retro? To learn from our prior successes and failures. If your team hates to retro, it means one of two things. Either your ScrumMaster does a horrible job of facilitating meaningful discussions, or the team is approaching it with the wrong mindset and does not really come prepared to observe and learn.
Why do we work in iterations? To run quick experiments that we can put in front of users and learn from. Jeff Patton’s book on User Story Mapping had a great passage, which to summarize basically says, for every story you want in the backlog you should write three stories. The first has the story, the second says fix the first card, and the third says fix the second card. His point is that we should be going through iterative learning cycles and we will rarely build the feature “right” the first time. If you aren’t following this cycle, you likely aren’t learning from the software you build.
User Story Mapping is actually what kind of inspired this topic. As I’ve worked to coach my teams through writing better stories, we’ve struggled with trying to do it “the right way”. We’ve basically taken the old school documentation process from waterfall and just tried to repeat it with our Agile process. What I’ve learned from this is that I need to teach this in a way that isn’t so prescriptive, but rather focuses on the mindset of telling stories and gets the whole team to a shared understanding of WHAT we’re building. What gets written on the card is largely irrelevant after that as long as it helps trigger our memories to the meaningful conversations we are having around the card.
So what does Agile mean to me in my day to day for coaching Agile teams? It’s becoming more about fostering a safe environment where we are free to experiment and learn. I think if those two things happen, then we can say we are “Being Agile”
What do you think? Please leave any questions or comments you might have as this is a work in progress for me and I fully expect to get some things wrong and hopefully learn as I go along!
No comments:
Post a Comment