[MUSIC] We covered anti-patterns related to how individual managers can negatively impact development teams through their own behavior. Now let's talk about a few anti-patterns that stem from individual developers. And how to address them. The first is the loose cannon. A loose cannon is a person who makes significant project decisions without consulting the rest of the team. They might also cause problems in their workplace by asserting their opinions on nearly any topic. Instead of helping to make progress, the loose cannon often impedes it. By raising small concerns and questioning every little thing. If the person makes their point often enough, others in the group will often concede just to avoid making a fuss. Slowly, productive and openly conversing teams can turn into a bitter mess. To make things worse, the loose canon can make everyone so apathetic to issues that groupthink sets in as well. When a loose canon makes decisions without consulting the group, they can create more work for other team members, and cause major headaches for everyone involved. This isn't heroics, like I discussed earlier in this lesson. It's recklessness. There isn't really a quick fix to the loose cannon. And the solution often depends on why the individual is acting the way they are. Sometimes the loose cannon just wants to cause trouble. And sometimes they want to prove their own worth. An ideal solution to the loose cannon is to try and get an individual to see their own behavior as destructive and make steps to change it. The personality of these individuals can often make change harder than it needs to be. In these cases sometimes organizational steps need to be taken in order to address the problem. A loose cannon can tear through a development team and quickly derail productivity. As difficult as it can be, it's important to deal with the behavior of a loose cannon as quickly as possible. Another destructive behavior exhibited by individuals, often on the development team, is Intellectual Violence. This is the final anti-pattern I'll talk about in this lesson. Intellectual violence is as much about the developer's inner world as any of the other anti-patterns I've described. Intellectual Violence can be used by loose cannons, making meetings unbearable. Intellectual Violence is a situation where a person uses their advanced knowledge in an area to intimidate others. This might manifest itself as a developer talking down to team members when they ask questions about a technology they aren't familiar with. As you might imagine, behaviors like this can cause team members to feel unappreciated and unimportant. Because of this, your team's morale can drop, and you can be missing out on some key ideas, or at least clarifications. To address an intellectual violence problem, try talking to the individual in private. Ask them to reflect on how their behavior affects others on the team. Like the loose cannon it's important to deal with this issue early so that it doesn't have a lasting impact on your team and your project. Another solution that works is encouraging a there is no stupid question policy at meetings. On top of that, try encouraging open communication in the work place. And discourage prejudging opinions or inexperience. Stewart has been sitting in his office all week without talking to the other developers on the team. As the team's manager, Poliana approaches Stewart to see what he has been up to. When she talks to Stewart he tells her that he has changed the team's user interface to better fit with proper practices. Poliana asked the rest of the team if they knew about this, and they tell her that they didn't. What sort of anti-pattern is Stewart exhibiting? A. Unproductive behavior, B. Intellectual violence, C. Loose cannon, or D. Expert behavior. The correct answer here is C. By making changes to the product without anyone else knowing, Stewart is being a loose cannon. To address this, Poliana should begin by encouraging Stewart to communicate more regularly with his team. And avoid making changes without talking to the rest of the team first. Let's see how anti-patterns are dealt with by industry professionals. [MUSIC] >> Email as a primary communication tool sounds like a pretty easy thing to do these days, everybody's using email and in fact I actually think it's used too much. I would never recommend email as a primary communication medium. And I would recommend two things. When considering a communication medium, I would think about, what are your stakeholders' preferred communication medium? How do they like to communicate? In the end, it's really not about your preferences and your communication mediums and preferences, it's really about the people receiving the project deliverables. So how do they want to be communicated with; whether it's by phone, by email, you know face to face. Whatever that looks like for them. So find out what their preferred communication medium is. In terms of email being a primary communication medium. I'd also recommend going to the old phone or the old face to face communication, I think too often we rely on email. And email as a tactic can often be misconstrued, or actually as a communication medium, can do the opposite. It can actually have miscommunication in terms of the tone or the voice that you're trying to create through an email may not be heard in the way that you want it to be heard. And so email can sometimes create new challenges for you. In that people may not take that communication the way that you meant it, and you've now created yourself some more work. So now, you have to go and manage different personalities, manage different situations, all because of the way an email was taken. So I would recommend primary communication is the preference of your stakeholders, as well as making sure you remember that there is a phone, and you can actually have a face-to-face conversation with people too. [MUSIC] Intellectual violence is something real within our projects. So intellectual violence can be defined as people using information or knowledge as power to intimidate others within their project. And so what you need to do as a product or a program manager is really understand different people's personalities. And understand how you can break through some of those silos and the trust of your team members so that they can understand that knowledge and information when shared is really when it's going to be most valued. So to lead to success and the results that you're trying to get out of your project, you need to find ways to do team building, to do confidence building. To allow your team and your resources to really trust each other and create that safe environment so they will share. And so what you want out of your team is to ensure and enhance sort of that understanding of each other's personalities so that they feel comfortable in a safe environment. Sharing whatever information that they have, realizing that really the true success of your project is dependent on this information sharing that they will do. >> Well, that's it. Those are all the anti-patterns I'm going to cover in this course. There are plenty more. As I said at the top of the lesson these are just a few from the project management side of things. However there are also anti-patterns related specifically to coding and software processes as well. If you are interested, there are links in the course resources to help you dive a little deeper. To quote Steve McConnell another writer in this field some mistakes have been made often enough to be considered classics. Others are unique to specific projects. So now that we've covered the classics let's talk for a little bit about what you can do to address these project specific mistakes. Join me in the next lesson to find out.
