About Team Members Types/Personalities in Agile Projects

Printer Friendly Version

We have written about how the agile coach deals with the different types of team members observing and determining the right level of support and guidance to give.

Based on a few past projects, we could identify a few team member personalities and behaviors that have a positive and negative impact on the execution of the project.

The Team Members Types

1. The I-take-that or filling-the-gap type

Reliable and willing to learn, valuable as loyal supporter of the team, hates conflicts; takes on tasks enthusiastically no one else wants. Creative, solves problems: If something has to be done, he/she does it.

2. The flexible and dynamic type

Willing to try new things and a willing listener and observer. Accepts a dynamic and changing environment.

3. The positive and negative feedback-giver

Analyzes and understands every project detail and complexity to give valuable feedback. Supports the team with difficult decisions.

4. The understanding and good-vibe type

 Doesn’t complain when other team members cause problems or rework. Gets on and does the job with a positive outlook on how to succeed.

5. The why-should-I-collaborate or the LONE-RANGER type

Give me my task and I work on it. I don’t want to speak with any one, If I need something, I won’t ask. I will make a decision alone. He/she likes working alone or only with experts.

6. The I-don’t-care-and-I am-not-responsible or DIVA type

Doesn’t care about what other team members do, but wants them to prepare everything so that he/she can do his/her job. Tries to tell everyone else what to do. Slow to see new tasks or issues, but thinks he/she does his/her job perfectly and nobody else does.

7. The I-know-everything-and-better-than-you-all type

Specialist, single-minded, can put knowledge into context, but doesn’t always want to do it.  Provides support if he/she wants to, but doesn’t recognize the achievements of others.

8. Over communicator type

To every question or discussion, explains in a lot of detail including the history of human origins. Loses people in the discussion. No one is ever sure how the answer is related to the question or the situation so stop engaging altogether.

9.  Indecisive type

Indecisive, un-inspiring and slow-moving. Gets the job done in silence once someone else makes the decisions.

10. The tell-me-what-to-do type

With lack of initiative, he/she needs a plan and that somebody tells him/her what to do and he/she will do it. Does not take personal initiative.


In addition to the personality and behavior experience with the subject domain is also a factor. It is possible to work with all these types in agile projects; it is a matter of coaching, facilitating, and observing as posted in our past article.

We are sure there are more TYPES and would love to hear more about them from you.  What is your experience regarding team-personalities?

Going Agile – Coach and Empower the Team

Printer Friendly Version

Working in an agile project as a team can be like sharing an apartment: there is one team member who usually cleans up, while another one never sees the mess, another one never shares anything and yet another one borrows everything. Some people drain your energy and it takes determination to deal with them.

A similar situation occurs to agile projects. The whole team shares a working environment. You are supposed to be generalist and do any story required to deliver. You are supposed to accept change even late in process.    

Personalities – By V.Vaca

Based on a few past projects, we could identify different team member personalities and behaviors that have a positive and negative impact on the execution of the project:

A – A team member is able, but unwilling or insecure?

B – or is unable, but willing or confident?

C – or maybe able and willing?

Dealing with the different types of team members requires the Agile Coach to observe and determine the right level of support and guidance to give. The Hershey and Blanchard Situational Leadership frameworks based on the two dimensions of support and guidance suggests the following actions are useful in developing team leadership abilities depending upon the quadrant in which the person is located.

1.The Agile Coach offers training & guidance 

2.  The Agile Coach explains & clarifies

3. The Agile Coach shares ideas & facilitates   4. The Agile Coach observes & delegates

Coach & empower the team

Adapted from: Hersey, Paul, and Kenneth H. Blanchard -Management of organizational behavior (5th Ed). Englewood Cliffs, NJ: Prentice Hall, 2008

Different types of ‘team members’ can be placed in the Hershey and Blanchard quadrant based on their behavior, willingness, and abilities to participate within the team. Depending on the quadrant, an Agile Coach could provide details on agile values, principals, or practices to the team and use agile events and games to support the team develop development.



My Visualization Tips – Keys to Creative Visualization in all Project Management Phases

Printer Friendly Version

In the last months, we have been writing about Visualization in projects on our blog. We have shared a few tips and our experience in making projects v i s u a l. We covered not only project data in the form of charts and diagrams, but also project relevant information such as requirements, expectations, and budgeting. We focused on using visualization to help avoiding misunderstandings, inefficient meetings and a demotivated project team.

In order to improve my visualization knowledge, I attended a workshop on this topic. I learned how to be creative and professional in team building meetings, project planning phase, or in holding a presentation.

The following visualization is the agenda for the workshop (Source: Visual Braindump): 

There are different ways to approach the different phases of a project – from a project initiation to project retrospective. For me it is important to keep it simple and yet informative.

Here are my personal learning on being or becoming visual.

1) Don’t be shy, be creative

Sometimes I don’t like to talk in front of other people or cannot explain in words what I expect on a project. Putting my ideas on paper writing and drawing my expectations during the project planning phase can help the project team to provoke a reaction and discuss the different topics. In the workshop, we did an exercise and learned that people remember what was discussed in a more effective way than the spoken words when it is associated with a visualization. We were also encouraged to make our own drawings and take our own pictures.

The comment “I cannot draw” is not applicable. The workshop also proved that everybody can draw.

The following picture is the result of drawing something based on our daily work/tasks using every letter of the alphabet:

2) Synthesize complex ideas and task by drawing them

As humans, we can transmit complex concepts using pictures. This is something robots cannot do. Those pictures can be interpreted by people with different cultures and backgrounds better than words. The capacity of synthetizing an idea, problem, task, or risk in form of an image using your own imagination, creativity and experience is endless. For sure, this will catch the attention of the whole team more than 1000s of words.

The following picture shows a roadmap for a beer brewery project:

3) Feel proud of what you do

It is not only the project manager and SCRUM master that leads the visualization process. Team members can contribute visualizations to the project to make themselves part of the decision-making process. I feel prouder of my work when I am part of the decision-making process, no matter how small or big my contribution is. In my experience, this contribution will increase the personal and professional involvement and the consequent success.

4) Be an active part of the Team – You are more than a role

Visual thinking is about communicating and expressing what I see, feel, think, and know, by drawing; like children do. Using visual thinking in every project phase – from team building to project retrospective makes the project alive. I learned that every task can be interpreted and thus visualized in a rational, emotional or practical way.

The following pictures show

  •  A ‘persona’ that shows a potential user

  • Different approaches -head (rational), heart (emotional), hand (practical) to different project aspects.

Free “Going Agile” ePub for PM / BigData /Analytic / BI survey input by 1-Oct http://bit.ly/2jRUhzx

Printer Friendly Version

I am doing some research to investigate success from a project perspective of the different types of decision support projects and their contribution to organizational performance. Join the effort and get a free “Going Agile Project Management Practices Second Edition” ePub or Kindle book (worth 32 USD on amazon).

Project managers, agile coaches, project team members, and sponsors that participated in a big data, business intelligence, or analytics project since 2002 can to take the survey. http://bit.ly/2jRUhzx

So far, people from 14 countries have contributed. Regards, Gloria

Building a Team with Collaborative Events

Printer Friendly Version

The agile coach has the responsibility to build the team into a self-organizing unit that can make its own decisions and resolve its own conflicts as well as collaborate as a team to deliver the product. Building a team is much more than building a working group. ‘Going Agile – Project Management Practices’ says the agile coach has to

  1. form the team and develop it through different stages,
  2. build collaboration amongst the team members,
  3. set the framework for group decision-making, and
  4. facilitate conflict resolution.

He or she has to take a newly formed group of individuals from individuals working together, which would be a ‘working group’, to a team. Teams go through stages of development and they tend to reach their best performance after having been established for a while. Bruce W. Tuckman identified four phases of development concerning interpersonal relationships and task performance:

To ensure the team members are clear about the project goals, the agile coach should use a collaborative event such as the chartering session, and create an environment that allows the team to collaborate in the creation of the product. Collaboration is two or more people or organizations working together to realize shared goals.

Collaboration event – Planning session

The diagram is for a project planning and estimation session. It was developed together with project team members and the client. It was used in the forming stage of the project. It supported alignment of team members towards the project goals and with one another, and a cross understanding of project tasks that needed to be completed. In the opinion of the project manager, it reduced the duration of the storming phase.

At the top of the diagram are hand drawn boxes that would represent phases in the project. Going from an initial deliverable in the first column and to building successive components until the final product on the right side. Wide-band estimation according to Fibonacci numbers suggested by Planning Poker ® were used.

The components of the diagram are:

  • The sticky note (yellow and pink) represents the tasks that have to be completed.
  • The color represents if the tasks could be completed by the project team (yellow) or if it was sourced from a third-party.
  • The tabs represent the estimates for the task.
  • In the lower left is the legend for what colors represent what levels of effort.
  • Each post-it® received an estimate if possible.
  • If it was not possible to estimate the effort, the task was placed in the box in the lower right corner.

According to the visualization recommendations, the design of this visualization fits the recommendations.

  1. Make it action-oriented:  Created during the session; retained as reference during the project
  2. Make it messy: the order developed during the session and its ugliness was retained
  3. Make it specific to the situation — It was for a specific project.
  4. Use different dimensions — it uses different…
  • Position:  represents the evolution of the product over time
  • Colours: pink, yellow, green
  • Shapes: oblong post-its are tasks; tabs are estimates
  • Numbers: are used as estimates

5. Make it interesting – the team was motivated and engaged.


Visualization in Projects – User Roles and Personas

Printer Friendly Version

Agile methodologies suggest the use of user stories that are specific to a role. Personas are one way of representing these roles.

User Story

As Gloria J. Miller writes in “Going Agile – Project Management Practices” the format for user’s story should include a title and the information on the role of the user, the function they need, and the value they should derive from the function. The following is the type layout of the user stories.

As a <user persona> I want to <function; what they want to do>

so that I can <business value; why they want to do>.

A Role defines the characteristics of typical users for the system. It should be represented by a persona or an extreme character. A ‘persona’ is an imaginary representation of a specific user role or ideal customer, a sort of a “prototype”. Personas should be created based upon market and demographic research to ensure the persona represents the target audience or user. It is about focusing on the major needs of the most important user groups. One user can’t be everything to everyone.

A function describes the capability that the user requires. The function should finish with the completion of an activity and not an on-going activity. For example, “as a webmaster I want to manage a website” is something never ends. “As a webmaster, I want to add and delete web pages” is a task that can be checked as completed. Business value explains the importance of the function or the value it derives.

Persona Visualization

A persona visualization that can be used in projects is to create a poster or chart with the personas that are relevant for the system under discussion. The following visualization is an example used in a previous project.


Based on the article a few recommendations for visualization practices in projects, this visual aid fits the recommendations as follows:

  1. Specify your objective for visualization —
    • Deciding and scheduling who got what level/content of training;
    • Setting-up the role and security concept for the system;
    • Making design decisions about who could perform what tasks in the system.
  2. Make it action-oriented — used to facilitate discussions, meetings and design decisions
  3. Make it messy — N/A
  4. Make it specific to the situation — It was for a specific project.
  5. Use different dimensions — it uses different…
    • Position of the persona – was based on organization hierarchy and functional role
    • Role – system end-users’ role
    • Photos/Avatar – real people with whom details could be discussed
    • Text – describing activities that people would need to do with the system
  1. Make it interesting —

Overall, personas are crucial throughout the entire system or product development phase and should be real-life representation. They are vital to launching a useful and usable system or solution.

Project Visualization: Sankey Diagram of Project Effort – by Gloria J. Miller

Printer Friendly Version

Sankey diagram is a data visualization tool that can be used to visualize multidimensional data in different ways. Originally, they were used to visual the flow of resources such as energy or material. The important features of Sankey diagrams is that they represent the physical flow from a source to a target related of a unit of measure (e.g., functional unit or period of time) and that the magnitude of the flow is shown by the size of the link. (Lupton and Allwood, 2017)

For project management, Sankey diagrams can be used to show the flow of effort between such topics as companies, roles, and deliverables. The diagram is a Sankey diagram of actual effort for a technology implementation project. It shows how the total project effort is divided by different dimensions (i.e., company, role, deliverable, and capability) and how the effort flows between the different dimensions.

Based on the article a few recommendations for visualization practices in projects, this diagram fits the recommendations as follows:

    1. Specify your objective for visualization — Demonstrate how effort was spent within the project.
    2. Make it action-oriented  — Not action oriented in print; online each flow can be selected separately and the value of the flow is shown in a tool tip
    3. Make it messy — N/A
    4. Make it specific to the situation  this was the real history of the project.
    5. Use different dimensions — it uses different…
      1. colors, which show effort different sources and targets
      2. size, flow size is relative to amount of effort
      3. Dimensions: based on columns
        1. Company
        2. Project role
        3. Deliverable
        4. Capability
  • Make it interesting — visual way of evaluating project effort
How it was created

The diagram is based on the timecard entries for a specific project considering 1) the person, 2) the roles the people fulfilled, 3) their company. 4) hours worked, and 5) a comment associated with the time entry. The comments were analyzed and assigned to a deliverable and to a capability. The effort was summarized for a three-different source and target columns as follows.

List Source Target
1 Company Role
2 Role Deliverable
3 Deliverable Capability

All three summaries were put into one csv file and visualized using d3js Sankey java script. An example of the csv layout is as follows.The source code for java script at the following location.http://bl.ocks.org/d3noob/c9b90689c1438f57d649


Lupton, R. C. & Allwood, J. M. 2017. Hybrid Sankey diagrams: Visual analysis of multidimensional data for understanding resource use. Resources, Conservation and Recycling, 124, 141-151.

Project Visualization: Retrospective Review

Printer Friendly Version

Recently, we published a few recommendations for visualization practices in projects, so let us ‘visualize’ these recommendations through this board.

Any identifying objects for the project or the customer are removed from this version

The first time I saw this picture was in a project retrospective review meeting. I thought “are we playing a game?” It was actually a board in form of a snake, although not for playing, but rather for visualize what happened in the project we had just finished. It was used as a facilitation tool in a lessons-learned session with the core team members from the project. According to our recommendations from the last article:

  1. Specify your objective for visualization  This board was part of a retrospective review to discuss the project history, what happened, and what lessons we learned along the way.
  2. Make it action-oriented — In the review session, we used post-it’s to discuss what to change in the playing fields.
  3. Make it messy — Although it was printed, we were encouraged to change whatever we wanted.
  4. Make it specific to the situation — This was the real history of the project with the actual events that occurred.
  5. Use different dimensions — It uses different…
    • colours, which show effort estimates by week (e.g. black = less than 3 person/day in a week; green = 9-17 person/day in a week).
    • shapes, e.g. block is a week.
    • numbers, which are the weeks in the year (calendar)
    • symbols, which show activities when they occurred
      • inside the blocks = events (e.g. installed the server).
      • outside the blocks = risks (danger sign), holidays, collaboration.
  6. Make it interesting — this is obviously something subjective, but for me this board was catchy and it attracted attention.

The objective of the meeting was to discuss what went well, what went wrong (and why) and what could we have done better. The main idea here was still the act of discussing, communicating with each other as free as possible. This board was an efficient aid for visual communication that encouraged us to evaluate and measure in a comprehensive way.

You can find the template for the board at the following location: http://boardgames.lovetoknow.com/Blank_Board_Games_to_Print


Visualization in Projects – Recommendations

Printer Friendly Version

Data visualization can help project teams envision projects progress, success, failure, risks… It enables users to create, view and manipulate data in more instinctive and effective way than with traditional reporting of just two-dimensions of columns and rows. It can be a powerful tool but we need practices in order to succeed with delivering the right message.

Data visualization in planning is actually a topic that hasn’t gotten much attention on regular project management trainings, but it is a fact that visual information helps users become better communicators. However, not many people use visualization in controlling, steering the project.

One of the processes that is especially important to data visualization is perception. Perception is not only the way you see or understand something, but also according to Cambridge Dictionary the “quality of being aware of things through the physical senses, especially sight”. You see something and you become aware of something in the way something is “regarded, understood, or interpreted”, which usually is intuitive, according to Oxford living dictionaries.

Our top-six recommendations for visualization practices in projects:

  1. Specify your objective for visualization – What do you want to accomplish? Status reporting? Or rather motivation?
  2. Make it action-oriented. Any project team member shall be able and allowed to change the visualization easily. It should be ready to use. People should want to change it, update it. For example, move from a status of ‘doing’ to ‘done’ or ‘on hold’.
  3. Make it messy. People should feel comfortable touching. Is it printed and too pretty? People wouldn’t change anything.
  4. Make it specific to the situation. The categories ‘working on’, ‘in progress’ etc. should mean something.
  5. Use different dimensions – colours and shapes to communicate different things.
  6. Make it interesting. People should want to look at it, read it.

Share your experience using visualization in projects

We are also curious and would love to know: How do you visualize complex projects?
How do you use visualization to help the project team…

  • track project timeline?
  • track progress?
  • plan estimates?
  • prioritize tasks?

Project, business intelligence and analytic practices