Be Agile, Don’t Do Agile

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!

The Telephone Game and Agile

I'm trying to get my Blog up off the ground and this is a piece I wrote for the Agile Hub at CareerBuilder a few months back.

THE TELEPHONE GAME AND AGILE

March 25, 2016. Posted in Agile, Resources

BY: SHAUN AUSTIN

Remember when you were a kid and played the game Telephone? You know, the one where somebody starts off by coming up with a simple word like apple and they whisper that in the person’s ear to their left. One at a time, the next person in the circle then whispers what they heard to the next person to their left. It goes around the circle until it gets back to the original person, and many times the word has turned into something completely different like Xylophone. Even at a young age, it’s a game meant to teach you the power of communication and how easily things can get lost in translation when spreading person to person.   So what does that have to do with Agile? Fast forward to your career as a Software Engineer, and you now have a “User” that has a pain point and says, “I wish I had a piece of software that solves [insert pain point here]”. In traditional waterfall practices, this user pain point is discovered by a Business Analyst who then translates the pain point into business requirements. The business requirements are then turned into complex documentation and brought back to the development team, at which point it follows each stage of the waterfall process until at the end you hope to have something remotely similar to what the user actually asked for, and that hopefully solves their pain point. What tends to happen though is that after working on the project for 6-9 months, you discover you didn’t get it quite right.   As a first step, implementing Agile can help with the mistranslation as you will iteratively release to your user and show them in baby steps the product you will be delivering. This alone will at least tell you quicker when your word starts to morph from Apple to Xylophone and get you back on track. However, there is a greater point about Agile that I’d like to make, and it deals with the 12 Principles of Agile.   We’ve all heard of the four values; Individuals and Interactions Over Processes and Tools, Working Software Over Comprehensive Documentation, etc. but not everyone is as familiar with the 12 principles of Agile that build off of these core values. One principle in particular that I’d like to highlight is:  

• Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

  By nature, Software Engineers have historically been introverted and tend to shy away from face to face conversations or confrontations. Instead they prefer to email back and forth for clarification, and/or have as few of conversation as required, and then not talk again until they are stuck or the project is complete. Even in my 6 short months as an Agile Project Manager, I’ve witnessed countless times where this had led us astray and either the wrong thing gets built, or we find out a little too late that the wrong assumption was made and we are not on track like we thought we were.   Now, just “Doing Agile” (also known as just implementing Agile ceremonies and processes) will take you a step in the right direction because you will still find out quicker than in Waterfall when you’ve gone off course. If you want to be a part of a truly exceptional team though, then you have to embrace and “Be Agile”, instead of just “Doing Agile”. It’s an important point to understand because there is a big difference in having an Agile Mindset and fully embracing Agile versus just adopting Agile Processes but not changing your mindset or behavior. If we want to “Be Agile”, then the Principle I mentioned is critical to understand, believe in, and put into practice.   Let me elaborate a little on two of the scenarios I mentioned above and discuss where the issues can arise. The first example of when the game of Telephone constantly happens is Email. I don’t think I have to tell anyone twice that we are all overloaded with emails. Studies show that a large percentage of emails received are actually productivity killers and do not provide much in terms of business value. So why then do we insist on emailing back and forth to make business decisions? When you email back and forth, you lose context, body language, etc. and often times the person reading the email gets a completely different understanding of what was said than the sender actually intended. That’s the game of telephone right there. There is certainly a place for emails, but don’t let this replace actual face to face communication, especially when making important decisions. You can always send a recap email after the conversation so that both parties have a record of what was said, but ensure you first have a conversation and that both parties have a shared understanding of the outcome of this interaction.   The second scenario I’ve encountered is the situation where 2 or more teams are required to complete a project. The two teams get together and have a kickoff discussion, but then retreat to their own corners until “their part of the work is complete” at which point they check in with the other team(s). For very simplistic projects, this can sometimes work. Too often though, assumptions are made and we realize a little too late in the process that these teams are not synchronized in their efforts. Even with the best of kickoff discussions, things change daily and new wrinkles evolve with the problem you are trying to solve. You have to be in constant communication with all parties, because even new wrinkles you believe are limited to your team can affect the overall delivery and throw us out of step.   So what can we do at CareerBuilder? We are fortunate in that a large chunk of our development teams sit here in Norcross, but even for our colleagues in other countries, modern technology enables more face to face interaction via Skype or Google Hangouts or any other countless methods of communication. Before sending that email, see if you can walk over and talk with that individual first and if it still requires an email for the team distro list, send the recap email after. If you are working on a project that involves multiple teams (which you will often be doing) talk with that team regularly. Over communicating is far better than no communication and allows us to deliver working software at a faster pace than working in silos. Utilize your APM to help foster that conversation; part of our job is to facilitate this collaboration and ensure that all dependent teams have a shared understanding of the work to be done.   Let’s “Be Agile” and start communicating face to face on a daily basis so that we can all deliver working software to our customers faster!