Teams Archive

Social Norms at Work

– April 29, 2011Posted in: Agile, Project Management

I recently gave a talk in Michigan on the topic of servant-leadership. Unfortunately, servant-leadership is something that is painfully absent in so many organizations. Just a few years ago, it (servant-leadership) was not something I had even heard of. Going back and reviewing the PMBOK made me realize two glaring omissions. There is a lack of content on stakeholder or team engagement and there is a lack of content on leadership. Fortunately, in the last few years, I have enjoyed books by authors like Clay Shirky, Seth Godin, Dan Pink, and Dan Ariely. I’ve also met and interacted with some amazing people in the Agile community. I now interact differently with my peers, as a result of these experiences. I now apply my social norms at work. What are social norms? They are patterns of behavior in a particular group, community, or culture, accepted as normal and to which an individual is accepted to conform.

We all go to work and we all get paid to do it. Too many times, we take things for granted. We don’t question the things we do or the things that happen to us. I’m pretty sure this is based on conditioning over a long period of time. Perhaps we need to start treating those we work with more like those we socialize with. Next time you interact with a fellow employee, ask yourself if your behavior is socially acceptable.

Social Norms

Within an organization, where we are working with other people, things can get twisted. Some exhibit bad behavior and believe it’s somehow forgivable because we’re all getting paid. Well, I don’t think that’s acceptable. It’s very interesting to see the same people behave differently, when not in the office environment. Why is it some people forget basic manners or common courtesy, when in an office environment?

Case in point, I hold the door open for people, regardless if I know them or not. I see this as socially expected behavior. Socially, I expect a thank you. To say I expect it is a slight embellishment. Outside of the office, I still expect a thank you. Unfortunately, at the office, I’ve started to accept not getting any reciprocation. There are a few people in my building that I don’t personally know but I still hold the door for them. They won’t make eye contact with me and they won’t say thank you. When the situation is reversed, these same people do not hold the door for anyone. But, I refuse to accept their behavior.

We all need to strive to understand and empathize with others. People need to be accepted and recognized for their special and unique qualities. Assume the good intentions of your coworkers and don’t reject them as people, even while refusing to accept their behavior or performance.

Drawing: Pictofigo

HT: Business Dictionary

Manipulate or Communicate

Derek Huether

– January 24, 2011Posted in: Agile, Project Management

I’m always looking for ways to communicate with team members, vendors, and customers. When trying to understand the range of communications, I recently reassessed what I thought the opposite of communications was. I no longer believe it is silence. Rather, I believe it is manipulation.

2 Examples:

[1] Buying a Vehicle

You go into an auto dealership. You want to purchase a new vehicle. You want to pay the lowest price as possible and the dealer wants to make the highest profit possible. Rather than coming to the table and negotiate based on this mutual understanding, both sides try to remain as silent as possible. Both sides are trying to manipulate the other, in order maximize the outcome in their favor.

[2] Getting a New Job

You apply for a position with a new company. You are interviewed and the company believes you are a good fit. As soon as salary is discussed, the manipulation traditionally begins. Both sides are trying to manipulate the other, in order maximize the outcome to their respective favor.

How it should be

In the case of the auto dealer, they should be honest about their cost of the vehicle. They should explain how the dealership and sales person will be paid. They should ask the buyer what their needs and wants are. Is it cost or is it the make/model (scope)? The key here is everyone needs to be honest! I’m not a pessimistic person, but with a (sales) relationship like this, I feel there will always be manipulation involved.

When negotiating salary with a new company, the relationship is different. Hopefully, both parties want a long term relationship built on honesty. I propose the applicant tell the potential employer exactly what they are currently being compensated, including benefits and bonuses. The applicant should explain their motivation for seeking new employment. Were they being paid too little; Were their benefits too expensive; Was their work/life balance all out of sorts? Was the previous job just unfulfilling? The new company should take this into account before making an offer. They should explain the range of compensation to be offered. Both sides need to be frank and honest. I recognize this is one of the most uncomfortable conversations you ever have. That’s why I believe both sides should be honest and over-communicate.

How it applies to a project or program

In the previous two examples, both involved negotiations and communications. From my perspective, these can all be win-win scenarios if we are honest and over-communicate. Over the weekend, I participated in a live web interview with Peter Saddington from AgileScout. I stressed the need for over-communications on projects and gave 3 examples on how to do it. You can over-communicate by using information radiators, daily stand-up meetings, or by having an open-door policy (with rules) with other meetings.

Information Radiators

Use burn-up, burn-down, kanban, or task boards in both executive work areas and team work areas. I would recommend displaying enterprise (program) level information where all of the executives can see it. I would recommend displaying team (project) level information where all the teams can see it.

Short Feedback Loops

Have daily stand-up meetings for each of your teams. Have daily “scrum-of-scrum” or “team-of-team” meetings to roll information up to an enterprise level. There is no excuse for anyone to NOT know what is going on every day.

Open Meeting Policy

For all of your meetings, have some simple rules. Understand that some people are allowed to talk and some are only allowed to listen. But, all should be informed. Now, I recognize not everyone should attend a Retrospective meeting or Executive Board meeting. But, everyone should know what the outcomes are.

Let’s face it, the enterprise wants to get as much productivity out of its employees as it can, in order to reach its tactical and strategic goals. In order to do that, you need empowered teams who trust each other. You need free-flowing communications. I’ll say it one more time. Be honest and over-communicate.

Popularity: 1%

Tags: Communications, Teams

Just One Agile Thing

Derek Huether

– January 10, 2011Posted in: Agile, Project Management

I met with the Agile Influencers of DC, on Friday night. The focus of the conversations for the evening was Agile Adoption. One of the questions asked (I’m paraphrasing here) was

If you were on a project, and you could leverage just ONE “Agile” THING, what would it be and why would you choose it?

This is a little like the first episode of Surviver but it is a good exercise to make you think about what you find valuable in Agile. Would you choose the use of information radiators? Perhaps you favor retrospective meetings? Or perhaps, you love the use of cross-functional co-located teams?

When I was asked, I chose empowered teams. Look back at the Agile Manifesto and one of its principles. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I believe if you build a team of professional and empowered people, you increase the probability of project success. Give your people some general rules to follow and have the faith they will make the right decisions. It beats the hell out of trying to control them! Empowering them also gives you more time to help them when they really need you, rather than making trivial decisions.

So, what would be the one thing you would choose? Why?

Like the image? Find it at Pictofigo

Team Building Techniques – 5 Stages

Derek Huether

– June 2, 2010Posted in: Project Management

When I think of team building techniques, the one place I didn’t think to look was the PMBOK®. In chapter 9, specifically 9.3.2, the PMBOK details Tools and Techniques of Developing Project Teams. For those out there studying for the PMP®, this might be a good time to write this down or print the blog post.

The PMBOK lists 5 stages of development that teams may go through, usually occurring in order. What PMBOK lists is relatively academic. It won’t actually help you with team building.

Those stages, with the exception of the last are based on the Tuckman ladder[1]. Forming – Storming – Norming – Performing. It’s a model of group development, first proposed by Bruce Tuckman in 1965, who maintained that these phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.

Why PMI found it necessary to add the last one, I can’t tell you. But, in the event you think it may appear on the PMP exam, here is what PMI thinks you should know.

Forming. This phase is where the team meets and learns about the project and what their formal roles and responsibilities are. Team members tend to be independent and not open in this phase.

Storming. During this phase, the team begins to address the project work, technical decisions, and the project management approach. If team members are not collaborative and open to differing ideas and perspectives the environment can be destructive.

Norming. In the norming phase, team members begin to work together and adjust work habits and behaviors that support the team. The team begins to trust each other.

Performing. Teams that reach the performing stage function as a well-organized unit. They are interdependent and work through issues smoothly and effectively.

Adjourning. In the adjourning phase, the team completes the work and moves on from the project.

The PMBOK concludes by saying a Project Manager should have a good understanding of team dynamics in order to move their team members through all stages in an effective manner.

Two stages I think they missed include Empowering and Supporting. If PMI can insert Adjourning into this list, with the sounds of One of these things is not like the others in my head, I think I can add my two stages. Still, if you want to pass the PMP, perhaps you should just stick to their list.

[1] Tuckman, Bruce, 1965. Developmental Sequence in Small Groups. Psychological Bulletin No. 63. Bethesda, MD: Naval Medical Research Institute.

Image source: Orange Country Register

Passion + Commitment + Skill = Success

Derek Huether

– September 17, 2009Posted in: Application Development

I just read an intriguing post on Dan Schawbel’s blog. It was titled The Excellence Equation: Passion and Commitment.

For several years, I’ve been promoting a similar “success” equation. The only component not listed in his blog post was skill. I think ANYTHING is possible if you have passion, commitment, and skill. If you’re short in one area, you can make up for it in another. I’ve worked with people that lacked a specific skill, but were so passionate and so committed, there was no way they were not going to succeed. When building teams for a project, I like to find individuals who excel in each area. I don’t want an overly-skilled team as much as I don’t want an overly-passionate team. But, when there is balance in all three areas, I’ve seen magic happen.