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
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!
No comments:
Post a Comment