Tag: Communication

Why Not Use Social Media on Your Project Teams?

Written by Michael Klynstra on October 24, 2012. Posted in Articles. 2 Comments on Why Not Use Social Media on Your Project Teams?

Project Managers, change is in the air. Well, change has been in the air for quite a while, so you’ve probably been smelling it: Social Media is making its way into the workplace. It’s no longer just about tweeting what you’ve had for breakfast or seeing what your old high school friends look like. And in your company, it’s no longer just for marketing.

The principles and benefits of social media are yours for the taking when it comes to improving communications within the team and among your project stakeholders.

This presentation puts the various social media platforms under the microscope so you can learn exactly how each delivers value to its users. We’ll talk about how you can apply similar principles to your communication plans and help your project team collaborate better, build community, solve problems faster and have more fun.

A practical, inexpensive, fun way to improve team collaboration

For many of us, social networking has become second nature. Now mature, social media platforms are taken seriously as viable ways to communicate real-time news, political commentary, business connections, recommendations for good movies, suggestions for restaurants, and even alerts about heavy traffic on the tollway.

By looking beyond our timelines and tweets and understanding just how information is distributed, aggregated and used, we can learn a lot about how social networks are modeled. Then, if we apply these models to our project teams and client communications, we just may derive a whole new way of interacting that solves even the most dogged team communication traps.

Break through the irritations of email, shared folders and lists

Think about all the things that Project Managers need to collect and share. First, there are project specs, changes, and status. Then there’s diagnosing and solving problems that come up during the life of the project. And, of course, there’s always a need to communicate milestones and accomplishments. For all of the above, the principles of social media can be extremely useful in managing the inflow, interpretation, and outflow of project information.

If you’re new to social media, the benefits will become clearer to you as time passes. Think of it as an opportunity to break through the irritations of traditional methods like crowded email inboxes, hard-to-find shared folders, endless versions of attachments, and email groups where project members get inadvertently excluded and updates get missed.

For example, one of the most rewarding aspects of social media is the ability to create virtual communities where the team can share ideas and monitor all aspects of the project in real time. Communicating in this way builds community, trust and morale among team members (especially important when you have distributed teams collaborating across distances).

Most shared spaces can be easily updated and indexed for later searches. This is often done by the use of tags. Imagine, for example, the team uses the tag or label “#scope” every time there is a conversation about project scope. Then you could simply search for that tag and the entire history of scope-related conversations are brought to the forefront for review as needed.

What today’s popular platforms can teach us

Let’s take a look at some of the most popular social network platforms used today (and then some that are not so pervasive) and see how we can apply these models to our own projects:

Deliver Real-Time News (like Twitter)

Twitter is a strange bird (sorry). At six years old, it has at once remained the same (still 140 characters) yet evolved into so much more than what anyone would have imagined. Twitter has played an incredible array of roles from a few random chirps in the night and geeks talking to geeks to a place for following celebrities, political campaign platforms and even a global news outlet. It’s the last one I find most interesting and perhaps the most useful for our project teams.

More and more we’re hearing stories break on Twitter. Consider citizen-reporting during the uprisings in Iran and Egypt — stories reported via social media long before traditional media picked them up. It’s news reported by people IN the moment and reported real-time, not relying on a traditional news outlet that has planned to hopefully be at the right place at the right time.

For the same reasons why teams are often more productive when sitting in the same room, Twitter-like communications can serve a team’s need for quick, relevant information. Consider all those one-liner emails that clog your inbox and what it could mean to you if you could subscribe to just the ones of interest? KlynstraOct24th1

@projectmanager122: Impromptu demo today at 3pm #clients

@the_it_guy44: QA server getting a drive replacement; will be down 7pm-8pm #tech

@busy_BAgirl: time for a brain break. Foosball in the lounge in 5. #fun

@projectmanager122: AWESOME demo; congrats team #clients

Hashtags, keywords preceded by the # (i.e. #iterations), can be used to index and filter topics. Clicking on a hashtag in a tweet will collect tweets that use the same hashtag, allowing the reader to track conversations. Tools like TweetDeck help users manage multiple conversations at once, by serving as a real-time news dashboard.

If you want fast, short (140 characters max) team interactions with easy indexing of topics, Twitter is a good option. This is a great alternative to group emails in which people can get trapped in an endless chain of irrelevant “Reply to All” responses.

Build a Community (Like Facebook, Yammer or Google+)

Many professionals don’t want Facebook anywhere near their professional life – or vice-versa. Whether you have 10 or 1000 friends, there could be a lot going on with your Facebook timeline, so discerning work-related posts would be tough. However, there is something to be said about that unified space like Facebook’s timeline. Where Twitter is designed more for messages in-the-moment, a Facebook-like timeline brings together the activities of many in a persistent stream. Yammer, Facebook’s sibling in the corporate world, provides a similar space while staying focused on the company.

With Yammer, you can share announcements, create a team calendar of milestones, create pages for different interests, and upload documents. Also consider posting your team norms, latest screenshots of the app for team members to comment on, and sharing video updates or team photos.

Consider capturing project moments in a timeline. Someone out for a day? They can browse the timeline when they get back to see what they’ve missed. Looking to provide real transparency to your stakeholders? Let them see the project timeline to better understand the nature of the work being done. Over the course of an iteration, the timeline can reveal interesting patterns of communication and events, a good reference during a retrospective.

Yammer allows for more in-depth updates as its characters are not as limited as Twitter. Comments can also be grouped into a “thread” beneath each post, allowing for a more conversational tone. If sharing longer messages, conversations, videos or pictures is preferred, Yammer may be a better option.

Create a Free-Form and Flexible Space (like a Wiki)

At around 17 years-old, the Wiki is likely the oldest platform discussed here. It’s original intent, according to its inventor Ward Cunningham, was to be “the simplest online database that could possibly work.” It is a space in which users can add, modify and delete pages and content using a simple markup language. One of the more compelling features of a wiki is that its structure and content is created and maintained by the users themselves as it is grows and is being used. Therefore, there is no “build it and hope they come,” rather it gets built only if someone feels it’s necessary.

Wikis are flexible and can serve as the backbone for a small team’s shared notebook or an entire corporate intranet. You can host a wiki on your own server or use a service company that offers hosted solutions that allow you to sign up and get started immediately. If you want to create a space for your team, but don’t want to dictate how it’s organized or actively manage it as an administrator, a wiki is a good option.

Deliver Material in an Engaging Way (like Vimeo, YouTube and Podcasts)

Studies show that more and more people prefer video to text with certain types of information. Video also creates more of a personal connection which could be particularly useful for distributed teams.

Depending on how polished you want your final product to be, video can introduce quite a bit of work and technical challenges. How do you record your video? Cell phone, laptop camera, video camera? How do you get it from that device online? Is it a big video? Do you have storage? Do people have the right technology to watch it? A newer smartphone combined with YouTube or an Apple computer with the iCloud service are good combinations to keep things simple. Let your audience know your videos are intended to get them better information, sooner and in a more compelling way – and you’re not looking to create the next summer blockbuster. Keep this in mind and you can introduce something fun to your communication mix.

If you have distributed teams, set each group up with the means to create video updates and encourage them to do so on a regular schedule. Not only will your status reports be more engaging, but putting faces to names creates a closer, more respectful team which is invaluable when you hit the inevitable bumps in the road.

Crowdsource Intelligence (like Escort Live Nation)

When thinking about this article, I spent time thinking of all the social networks I’ve participated in. One not-so-well-known network made me realize how much more we can still benefit from social concepts in our working world.

Have you heard of Escort Radar’s Escort Live Nation? If you drive a fast car – or drive a slow car fast – you may want to check it out. Via Bluetooth connected equipment and GPS technology, drivers can report stoplight cameras and speed traps on the road. Those reports are then stored in the cloud. In real-time, other drivers are notified of these reported locations as they approach them. Members of this community are “helping” each other out, gaining more insight and more value the more they participate.

What can our project teams gain from a similar model? What if our team members created alerts when they come upon something worth noting. Maybe they drop a label on a file or part of a document. Perhaps it’s a feature, process or metric that needs to be addressed. As others “approach” this area, they can be made aware that someone else on their team thought something should be looked at. If we could do this in code or documents and aggregate the alerts, would we see patterns that we might otherwise overlook? Every project could use extra help with an early warning system.

Where to next?

When choosing which social concepts to try with your team, first consider the types of problems your team needs to solve and how you like to communicate. If you’re looking to adopt a platform, this information will help you determine your best bets for adoption.

While I know of no tried and true road map for what works best for most teams, agreeing on what to use and developing standards and general guidelines should be the first steps. Use what’s comfortable for your team. Get a sense of what they use outside of work to get a sense of HOW they are communicating.

Use this checklist to gather information from your team as you develop your plan:

How sensitive is the content that would be shared?
Twitter is an example of a platform that offers capabilities to secure tweets and send direct messages away from the public. However, there remains some risk that someone may inadvertently send a message to their public stream. If this is a concern, look toward a closed ecosystem in which you know the content will remain safer. Yammer and a self-hosted Wiki are examples of such private spaces.

Is your communication unidirectional or bidirectional?
If you are looking for a new way to communicate status, Vimeo allows for password-protected videos or setting access to other specific Vimeo accounts. But, if you are looking for a new way to get your entire team talking together, Vimeo’s commenting area isn’t the best fully-interactive community space. Look for a platform with a forum-style area such as a LinkedIn group or Wiki if you want your team to post updates, comment and converse in a free-form way.

Do you have a social platform budget?
While most platforms have versions with basic functionality, tiered pricing can get you more. Gather your list of platforms and tiered pricing structures to get a sense of what it will cost you to get what you need. The pricing alone may dictate where you start.

What platforms do your team members use today?
Sure, there are statistics that tell which demographic is using any given platform, but my experience says “you never know.” Take a poll – not only on what people use, but gage levels of interest in trying something out. Introducing tools always introduces the challenge of adoption, so you may need to think about how to get people engaged once you’ve got the pieces in place.

Keep it Personal or Make it Professional?
Work with your team to determine what information will be shared and whether team members should use their personal accounts or create professional accounts.

While there’s no right or wrong answer, some professionals choose to use one account while others may have several, each serving a different purpose. Again, the key is to determine which route to take and make the rules of engagement clear.

Take the Plunge

Many of the project managers I meet are excited about the prospect of using social concepts to improve team communication. Because most of your team is probably already comfortable with social media, it shouldn’t take too much effort to get everyone on board.

As a former developer, project manager, and client partner, I’ve been around software teams long enough to know that most problems result from communication issues on some level. Social media is an extraordinary opportunity to improve team collaboration at all levels.

Collaboration should be fun and the space should be open for ideas and support. The human predisposition to be social works in your favor since only one person posting updates or commenting on blogs can quickly dampen the collaborative spirit you’re trying to create.

Bottom line: For teams across the organization, from marketing to customer support to IT, social media has already erased the line between personal and professional interactions. Now that the landscape of tools currently available can get you up and going quickly, it’s no longer a matter of when social media will fully integrate itself but how.

Learn more about this topic at Project Summit in Chicago on Nov. 12

http://www.projectsummit.com/chicago/program-sessions.html

Don’t forget to leave your comments below.

Annual Project Planning is an Anachronism!

Written by Kiron Bondale on October 17, 2012. Posted in Articles. 6 Comments on Annual Project Planning is an Anachronism!

Although its justification is usually tied to the budgeting cycle, it’s safe to say that an annual project planning cycle presents some serious flaws.

Significant effort is expended to have each functional area come up with its wish-list of projects. This process will usually include some quantitative and qualitative analysis to help support decision making. After this information has been gathered, the real “horse trading” begins to identify the short list that will proceed right away as well as those projects that are still important but won’t start until resources become available. It’s even possible that objective priorities are set for the project lists at both a corporate and functional area level.

Unfortunately, this prioritized list which is produced at great cost and elapsed time is just a model and like any model, if it is not kept current, it rapidly diminishes in value. It is very rare to find a leadership team that when reviewing their annual project list months after its creation would feel confident that the relative priorities and completeness of the list is accurate.

Changes in the external and internal environment drive the need for new projects, and those initiatives that had seemed worth funding earlier in the year are forgotten as new information emerges. To make matters worse, if work allocation and tracking practices are not consistent, it’s entirely possible that stealth work on divisional “pet projects” may be taking place which would further impact the quality of the annual project list.

While it would be ideal to mature planning practices in an organization to a more dynamic approach, this type of evolution can’t happen overnight. However, there are some incremental changes that could help to start the ball rolling.

Assuming the senior leadership team receives monthly or quarterly updates on the status of active projects, ask the following four questions once the active project status review has been completed:

Are all of the pending (i.e. not active or completed) projects on the annual planning list still valid, and are there any on this list that we don’t intend to start this year?
When are you intending to launch the remaining pending projects?
Are there any other projects that your staff are actively working on that are not on this list?
Are there any other projects that you intend to kick off this year, and if so, in what month/quarter?

The answers to these questions should enable the creation of a rolling one year planned project portfolio which would become a key input into project intake. When a new project request is submitted for consideration, if it is not on the planned project portfolio, the governance committee should be reminded of the priorities they would have been (re)set recently. While unexpected environment changes (e.g. “Black Swans”) might still cause disruption to the portfolio, this approach might help to make this situation an exception.

Annual project planning has been the norm for a very long time so one might feel that change is not feasible. However, organizations that won’t evolve are likely to appreciate Arthur C. Clarke’s quotation about the risks of complacency: “The dinosaurs disappeared because they could not adapt to their changing environment.”

Don’t forget to leave your comments below.

Lesson Learned: Asking Questions isn’t Enough!

Written by Lisa Anderson on October 10, 2012. Posted in Articles. 5 Comments on Lesson Learned: Asking Questions isn’t Enough!

FEATUREOct10th As a global business consultant, entrepreneur and operations strategist, I’ve seen countless business strategies, plans and projects succeed or fail based solely on what might be considered a nonessential question. On one hand, I’ve promoted that leaders and project managers ask questions; however, I’ve seen that approach fail as well. Instead, it boils down to whether you’re asking the right questions at the right time.

This situation arose recently in a client project. After following what seemed to be all the right processes – implementing improved internal communication processes, working closely with the supplier to resolve tooling issues and keeping the customer in the loop with progress to ensure improved delivery performance, a failure occurred.

When I started to ask questions to determine the recovery plan (as it related to a project I was focused on), it became obvious that although we spent significant time with the supplier and asked all sorts of questions, we didn’t have the planning expertise involved to ask the right question at the right time to fully address the issue. We were “all over” resolving the technical issues and had made substantial progress yet the customer was negatively impacted – again!

So, what did we learn from this experience (other than hiding under the table when the customer arrived)?

Start with the objective: When asking questions as to the status of a project or in resolving an issue, it is critical to understand the objective. In our example, we had 2 objectives: 1) Resolve the technical issues so that our supplier was better able to support our customer requirements long term. 2) Understand what could be achieved in the interim so that we could confidently communicate to our customer. We didn’t ask all the right questions to fully address #2.
Involve the right expertise: I’ve learned that you don’t know what you don’t know. Seems obvious; however, it is essential to determine what gaps might exist so that you address them proactively. In our case, we had an abundance of technical and procurement expertise; however, we didn’t have the planning expertise. Thus, we asked when the material would be available; however, we didn’t ask further questions and dig into the answers in enough depth to get to a reasonable delivery date projection.
Develop critical path timelines: I’d be remiss if I didn’t mention the importance of developing critical path timelines. Which tasks are dependent on other tasks? Is there a way to shorten the timeframe in between tasks? Certainly, when you are in a past due situation, it is even more essential to fully understand the options with your critical path. In our case, the same skills could be used on part A or part B (both required to satisfy the customer). We were behind on part A and so focused significant efforts on A; however, we shouldn’t have lost sight of part B. Instead, we should have asked more questions to account for and optimize for both part A and part B.
Track progress & follow-up: This equates to motherhood and apple pie of resolving business issues, implementing organizational change etc.; however, it is worth emphasizing. Although it seems obvious, it’s easy to forget as fires arise. Instead, set up reminders, meetings, calls, follow-up vehicles etc. In our case, we had good follow-up in place; however, if you aren’t following up on the right tasks (based on the right questions) at the right time, it doesn’t fully achieve the benefits.

Asking questions is important to everyday business success; however, asking the right questions at the right time is vital to thriving in today’s new normal business environment. Who can afford to spend the time and effort to focus on doing all the right things yet be in the wrong game?

Don’t forget to leave your comments below.

Let’s End the Debate Over Scrum Master versus Project Manager

Written by Steven Starke on October 3, 2012. Posted in Articles. 3 Comments on Let’s End the Debate Over Scrum Master versus Project Manager

FEATUREOct3rd Over the past several years, there has been much debate and confusion over the role of a project manager as the majority of organizations undergo Agile transformations. In fact, industry data suggests that approximately 53% of organizations are blending Agile methods with Waterfall.[1]

The result of this seismic change has been that project managers have left organizations; PMO’s have been dissolved, – all because of the introduction of Agile development methodologies. And project managers are not alone. The introduction of Agile has also significantly impacted the product manager role as well; as organizations concurrently struggle to make sense of the product owner role.

I can’t tell you how many articles I’ve read and LinkedIn postings I’ve seen on these subjects. The best material recognizes that a project manager is NOT a Scrum Master and vice versa. And although the description of the Scrum Master role is usually pretty clear in these discussions, nobody has done a really good job of explaining how the two roles (Scrum Master and Project Manager) co-exist or how this role confusion started in the first place.

To be honest, I really never understood the debate. I started executing projects back in 2001 using XP (Extreme Programming) and I never had any issues with team members regarding role confusion during project execution. Agile wasn’t evil – Agile worked. Well, fast forward to 2012 and the debate continues to rage on. I finally got sick of watching the continuous debate and decided to take action. I took the classes, passed the test, and became a Certified Scrum Master. And after all that money and time spent, I can honestly say with certainty, I’m not a scrum master – I AM a project manager!

Fundamentally, I think the root cause of the debate is not based on scrum master versus project manager responsibilities but based on our fundamental definition of a project. In the Agile world of minimum marketable features (MMF’s), product backlogs, and continuous integration, the lines of the traditional project have now been blurred. I find that the Scrum team has no issues with their responsibilities back to the product owner and scrum master, but for some reason, the entire project team doesn’t feel accountable to the project manager.

My goal in writing this article is to end the confusion and the debate once and for all. To do that, I need to remind you of what a project manager is and how the two roles should co-exist. Let me get some quick definitions on the table to help structure our conversation:

The Scrum Master – The Scrum Master focuses on the development process and mentors the Scrum team. The key responsibilities of the scrum master are:

Maintains and removes impediments
Manages the Scrum process, making the process work
Plans the release
Plans the Sprints
Shields the team from external interfaces
Facilitates Scrum meetings as requested
Ensures crystal clear communication among everyone involved in the project

A Scrum Master is usually the team leader. A Scrum Master should ideally have a good balance of the following skills:

Technical expertise
Understands the Product Owner’s Intent
A good team player and mentor
Understands the teams capabilities
A good motivator
Problem solver

Now let’s take a closer look at the program and project management roles and responsibilities by defining a project and a program…

Project: A temporary endeavor undertaken to create a unique product, service, or result. At most organizations, the boundaries of our “temporary endeavors” are defined through our business cases.

Program: A series of related projects designed to achieve a specific outcome(s).

To state it concisely, the role of the project manager is to manage all (Ideation to post-Launch Support) aspects of the project to achieve the expected outcomes identified within the established business case (investment) – not just the Scrum Team. The size, scope, and complexity of the business case will determine the size of the project. Achieving outcomes called out in the investment may take a series of related projects – called a program. At which point, the program manager is now accountable for managing all aspects of the program, with project managers and other accountable resources managing their smaller project portions.

Right now, there are three, possibly four basic categories of “temporary”:

Product line execution – Temporary relative to a 1 year planning cycle. Basically covering minor incremental enhancements to an already existing product line.
Big custom projects / new product development
Within the product line – Specific temporary initiative/projects. For example, a SQL server upgrade.
Cross organization initiatives – Examples that come to mind are rebranding, ICD-10 (healthcare), data center migrations, etc.

These projects / temporary endeavors at most organizations typically look like this:

starkeoct3rd1

And it looks like this…

starkeoct3rd2
And it looks like this…

starkeoct3rd3

If this is a project, then the project manager needs to be the one accountable person responsible for managing all of this work (or for understanding and managing HOW we’re going to get the answers to the questions above in each circle) – They are not responsible for answering the questions!

To put it simply – the project manager is responsible for managing all the boxes together to achieve the desired outcome. They may or may not be responsible for managing the individual boxes. Individual box responsibility is typically done by the subject matter experts.

As you can see, Agile development and the Scrum team are only one box!

Specifically, the project manager is responsible for:

Understanding the intended outcomes of the project and ensuring the outcomes are realistic and measurable. They need to understand the outcomes expected from the business case!
Collaborating with the team to define the scope of work (e.g. under each colored box above, what’s in it, what is the expected outcome), who is responsible for delivering it, and when will it be delivered. Specifically:
- Deliverables required to complete all the project work
- Cross-functional resource assignments
- Estimates to complete the work and dependencies between work items
Understanding the point person from each functional team(s) associated to the work (each colored box) and how they have been allocated for managing their work. If allocation bandwidth issues exist, this person would be responsible for facilitation and ultimate resolution of the resourcing issue.
The job of the project manager is to remove ambiguity in roles and responsibilities by clearly mapping out activities against expected outcomes relative to time. Identifying the interdependencies between deliverables and functional teams up front will better determine what teams should be more integrated and when, relative to the overall product development process.

Important note: if the scope of work is large enough, another project manager/person may be assigned to specific items (smaller box). The relationship would be a dotted line from this other person to the project manager.

Said another way, if each one of the smaller boxes above is large enough in scope to be considered its own project, then the program would consist of several related smaller projects rolled up underneath the program.

E.g. Hardware or software procurement, installation, and configuration – Application Operation Project Manager
E.g. Agile product development – Product owner/scrum master

Understanding the process and tools required to manage the scope of work relative to the outcomes identified in the business case. Understanding the metrics and the process for achieving those metrics/goals.
- If an identified metric is that the project be completed within a certain capital budget, then the project manager is responsible for understanding the tools and processes required to forecast and track the work. They are NOT responsible for creating or establishing those processes – unless of course that creation has been identified as another project!
Project managers are responsible for the overall communication regarding the project (not just the development portion of the product). They’re the primary single authoritative source of information to ensure a shared understanding of all parameters:
- Scope
- Cost management
- Timing
- Assumptions / constraints
- Risks / issues
- Resources
- Quality
- Special considerations / exceptions
- Development methodology considerations
- Team members and associated roles and responsibilities
- Policies and procedures

So, if you agree with all of the above, is there really a debate between the two roles?

There’s no way, going through Scrum Master training that I could be responsible for all the responsibilities of a project manager. It’s just not fathomable and would lead to ultimate project failure. To set the record straight, project manager is NOT synonymous with Scrum Master. A Scrum Master is critical to the facilitation and execution of the Scrum team. But they’re not responsible for all the components of a product development project. If anything, a Scrum master should be a dotted line to a project manager as part of the reporting structure.

However, for all these relationships to work together, we also need to know what the responsibilities are of the team back to the project manager.

Essentially, the project manager has to know just about everything that’s going on during the course of a project in order to determine if the right action and the necessary progress is being made against the tasks and deliverables. It’s unrealistic for every meeting and every action to be in the project manager’s schedule. However, they still need to know what meetings are occurring and when communication and decisions are expected in order to ensure the team is working effectively and efficiently relative to the agreed upon scope and success criteria of the project.

This relationship between the project manager and the team is not meant to be based on command and control, but rather based on trust and optimizing collaboration. If the project manager has any chance in managing these responsibilities while not having authority over most, if not all, of the team resources, then they need to rely on those team leads for basic and fundamental information. The following are the characteristics of the entire product team including the project manager:

Openness regarding truthful task and deliverable progress
Frequent and constant communication

Commitment to achieving the success criteria
Courage to tell the truth
Respect for each other

Borrowing the page of Scrum team responsibilities to the product owner and scrum master, I’ve tailored the responsibilities so that they reflect the entire project team relative to the project manager:

Communication regarding the prioritization (and change) of requirements, MMF’s, sprint backlog items, and tasks
Commitments to results based on agreed upon milestones
Communication of estimates of effort to implement User Stories and tasks to complete all project deliverables
Communication of dependencies between tasks and team members
Identification of obstacles and informing the project manager when those obstacles may occur and when they have occurred.
Self-organizing – Individual teams within a project have to be self-organizing and can’t rely on a command and control style project manager. However, self organizing means informing the project manager on how the team is self- organized and how they intend to complete the work. Project manager’s need to have context for any of this to make sense.
The team has the right to do everything within the project guidelines boundaries to achieve the project goals.

In the product development world, project managers, more than ever, are critical in the successful execution and delivery of projects/products to market. Role clarity and collaboration is essential. The project manager and the scrum master are meant to work collaboratively with each other not against each other. If we can get our definition of a project correct and we can enforce the responsibilities of the team back to the project manager, then I can say confidently “Project managers, there is no need to worry about job security. You’re still a valuable member to your organization. If anything, your job just got easier by the introduction of the scrum master and product owner roles.” Happy delivery!

Don’t forget to leave your comments below.

[1] The Study of Product Team Performance, 2012, Actuation Consulting LLC and Enterprise Agility Inc.

What Encourages Team Members to Pull Together?

Written by Gil Broza on August 15, 2012. Posted in Articles. 7 Comments on What Encourages Team Members to Pull Together?

One defining characteristic of any team is their shared purpose. I always ask about it when I meet a new team. The answer is usually beige, something like, “We do the social media component.” Stronger teams have an identity, a vivid purpose, or an inspiring vision. Such teams ask themselves, “What must we do together that is larger than any of us, requires all of us, and for which none of us can claim individual victory until it is done?” [i] In some cases, a team will reflect their identity in a name. [ii]

Basic affinity between the members is necessary for them to want to be with each other. Some common background and shared interests are helpful, although shared values are much more powerful. Imagine you and I are on a team writing medical software. You were attracted to your job because it improves people’s lives, whereas I joined for the outstanding pay, which allows me new luxuries. We are both motivated and willing to work together, but would you care to work with me? Would you go the extra mile on my behalf, or have my back, when you know I’m really just in it for the money?
Another powerful catalyst to team growth is success. If a team follows through on a valuable commitment, they will grow stronger. As each member considers that, together, they have hit a significant target, their success becomes a reinforcing feedback loop. Agile coaches rely on this loop to get teams started on the right foot by helping them secure “quick wins.”

You don’t have to wait for big team commitments, since those can take several weeks to materialize. The same principle operates on a smaller scale. Every time a person makes and keeps a small promise to a coworker, the mutual trust level goes up.

If you and I are on a team, we are not joined at the hip. There will be situations in which I will have to make decisions and promises on our behalf. You cannot control what I say, but you will have to live with the consequences. How do you like that? This worry is the highest hurdle to teamwork — and to lower the hurdle, you need trust. Trust is the foundation of teamwork, and if I am a member of your team, it is my responsibility to demonstrate my trustworthiness to you. Here is what I would do:

Share relevant information promptly. I would share meaningful updates and new developments in a timely manner. In particular, if I no longer thought I could keep a promise, I would tell you as soon as possible.

Be authentic. Speaking the truth is only the beginning. I would not pretend to know what I don’t know, or say “yes” (or “maybe”) when I mean “no.” I would work with you, but I would not pretend to be your friend unless I meant it. I would treat you as I would want to be treated.

Pull you into conversations that affect you. If I am about to make a decision that determines your work or limits your choices, I would delay it to the last responsible moment to allow you to join the decision-making process. (Examples include iteration planning and defining our meaning of “done.”)

Strive to be a dependable colleague. If my job pulls me in different directions, one of which is our team, I would arrange my other obligations as best I can so you know when and to what extent you can depend on me. If my schedule causes me to disappear on you unpredictably, and that hurts you, I would rather leave the team.

Caution: extremely challenging advice ahead. Address issues directly. When something about our work together upsets me and impedes our progress, I would hope for the nerve to have the uncomfortable conversation with you. It would demonstrate how important our relationship is to me, and I hope you would take it in that spirit.

About the book and the author

The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

Establish yourself as a confident and capable leader who adds value
Build and lead an engaged team that can handle almost any challenge
Cultivate collaboration and a continuous improvement mind-set
Reap the full benefits of Agile in the real world with real people

Don’t forget to leave your comments below.

[i] I learned this powerful question from Christopher Avery.

[ii] A famous early example from the software industry is the Black Team, a testing team at IBM. The story is recounted in Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, 2nd ed. (New York: Dorset House, 1999).