Tag Archives: skills

Pitfall of Scrum: Assigning Tasks

Learn more about transforming people, process and culture with the Real Agility Program

Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!!  It is better to wait for someone to step up than to “take over” and start assigning tasks.

Assigning tasks can be overt or subtle.  Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”

In the Scrum Guide, a partial definition of self-organizing is given:

Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

A more formal definition of the concept of “self-organizing” can be found here:

Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.

The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.

What If One Person Isn’t Working?

People who are managers are often worried about this.  What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing?  Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.

Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.

Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs.  Assigning tasks doesn’t make a person more productive.

What If There is One Task No One Wants to Do?

Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!

There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.

And, of course, there’s always the Sprint Retrospective!

Why Self-Organize – Why Is Assigning Tasks Bad?

Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.

Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees).  Even if this is true, it is still easy for a person to take offence.  However, most of the time it is not true.  People know themselves best.  People are best at assigning tasks to themselves.  And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.

The ScrumMaster and Assigning Tasks

The ScrumMaster plays an important role in Scrum.  Part of this role is to encourage self-organization on a team.  The ScrumMaster should never be assigning tasks to team members under any circumstances.  And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks.  If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening.  The ScrumMaster needs to be constantly aware of the activity on his or her team.

I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Please share!

Best Agile Advice Articles – Ten Year Anniversary!

Learn more about transforming people, process and culture with the Real Agility Program

Agile Advice was started in 2005.  In ten years, we have published over 850 articles (an average of just about 2 per week!).  Here are some collections of the ten “best” articles.  I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.

Ten Most Popular Agile Advice Articles

  1. How Two Hours Can Waste Two Weeks (75,000+ visits)
  2. The Seven Core Practices of Agile Work (25,000+ visits)
  3. Eight Barriers to Effective Listening (17,000+ visits)
  4. Seven Essential Teamwork Skills (17,000+ visits)
  5. 24 Common Scrum Pitfalls Summarized (15,000+ visits)
  6. Mentoring and Coaching: What is the Difference? (14,000+ visits)
  7. Wideband Delphi Estimation Technique (14,000+ visits)
  8. The Pros and Cons of Short Iterations (13,000+ visits)
  9. Three Concepts of Value Stream Mapping (13,000+ visits)
  10. Agile Work and the PMBoK Definition of Project (11,000+ visits)

Ten Most Commented Upon Agile Advice Articles

  1. 24 Common Scrum Pitfalls Summarized (19 comments)
  2. Agile Becomes Easier with Useful Tools (12 comments)
  3. Important Words about Scrum and Tools (9 comments)
  4. The Skills Matrix and Performance Evaluation on Agile Teams (9 comments)
  5. The Definition of Done is Badly Named (8 comments)
  6. How Two Hours Can Waste Two Weeks (7 comments)
  7. Agile is Not Communism (7 comments)
  8. Agile Tools vs. Agile Books (6 comments)
  9. The Decline and Fall of Agile and How Scrum Makes it Hurt More (5 comments)
  10. The Planning Game: an Estimation Method for Agile Teams (5 comments)

I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin).  These contributors are all experts, all have great experiences, and all are fantastic people to know.  I’m grateful for their contributions since they have all made Agile Advice a better place to browse!

Five Most Frequent Contributors (of Articles, besides Mishkin)

  1. Paul Heidema (34 articles)
  2. Travis Birch (24 articles)
  3. Christian Gruber (19 articles)
  4. Mike Caspar (16 articles)
  5. Shabnam Tashakour (13 articles)

Plans for the Future – Five Top Ideas for Series

  1. Essays on each of the Values and Principles of the Agile Manifesto
  2. Summary articles of several Agile methods including Scrum, OpenAgile, Kanban, Crystal, XP, and others
  3. Real Agility Program case studies
  4. Reviews of other scaling / enterprise Agile frameworks such as Disciplined Agile Delivery, Large Scale Scrum, Enterprise Scrum
  5. New guest articles from thought and practice leaders.

Please share!

Minor Update: Seven Essential Teamwork Skills

Learn more about transforming people, process and culture with the Real Agility Program

I was recently checking my Google Analytics for Agile Advice and the article I wrote quite a while back in 2009 about teamwork skills is even more popular than the front page of this blog!  I took a look at it and made some tweaks including providing some good references for more information about each of the teamwork skills.  Take a look: Seven Essential Teamwork Skills.  The only hard one was to find a good article about “sharing” as a teamwork skill.   If you know of one, please comment so that I can add it!  I’ll even be happy to take a link to an article you have written yourself.

Please share!

The Rules of Scrum: I am willing to learn any skill needed to help my team

Learn more about transforming people, process and culture with the Real Agility Program

Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills.  Skills can be technical, business, personal, tools-based, etc.  A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve.  A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn.  In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively.  This attitude is a key requirement for the formation of high performance teams.

Please share!

Leaving your title at the Scrum team room door and pick up new skills!

Learn more about transforming people, process and culture with the Real Agility Program
Each member of an organization has a title or designation that may reflect their responsibilities or profession.  These titles may include BA, Tester, Developer, QA, PM, and others.  It is normal to be proud of our accomplishments, achievements and titles.  Unfortunately in a Scrum team these titles can limit the individual and adversely effect the team.  These same titles can label the individual as that role (example – as a tester) and only that role.  Within a Scrum team we certainly need the skills, knowledge and abilities that come with that title/role, but we do not want to limit that person to being viewed as only that role.  Each of us is the sum total of our experience, education, values, upbringing and history.  All of this is of value to the team.  We should encourage every member to fully participate on the team, to willingly share their expertise, to contribute to non-traditional tasks and to feel they are valued as a complete person rather than a specifically titled individual.   So if the goal is to leave your title behind, then it is implied you can also pick up other skills.
So how can this be accomplished.  One way is a Skills Matrix.   This is a chart that can be posted in the room to identify the skills needed and the people on the team.   On the left column you list all the team members.  Along the top you list all the various skills you need on the team.  Then each person reviews their row, looking at each skill, and then identifies how many quadrants of each circle they can fill in, based on the range below the chart.  The range is from no skills through to teach all skills in a given column.  After filling the columns and rows, now the work begins.  By using pair programming (an extreme programming method) and other methods like self-study and taking additional courses, the team member can begin to learn other skills.  The objective is to have at least two persons on each team who possess each of the skills at the level of performing all the tasks of a specific skill.  The goal is not to have every one do everything but to have a least enough people with specific skills to cover sicknesses and vacations so that required tasks are performed.  This is a method to capture the full extend of each person’s current knowledge, skills and abilities and expand on it.
Skills Matrix
Since they are hard to see, here are the labels for the number of quadrants:
0: no skill
1: basic knowledge
2: perform basic tasks
3: perform all tasks (expert)
4: teach all tasks

Please share!

The Skills Matrix and Performance Evaluation on Agile Teams

Learn more about transforming people, process and culture with the Real Agility Program

For a few years now I have been working with managers and executives to help them do Agile-compatible performance evaluations of their staff.  The method that has been most successful is based on a tool that comes from the book Toyota Talent called the “Skills Matrix”.  The basic approach follows these steps:

  1. Baseline the skills within a team for each team member.
  2. Set development goals and action items.
  3. Regularly review performance in relation to the development goals.

Of course, the details matter.  The OpenAgile Center for Learning has published a brief overview of how to use the Skills Matrix and a convenient A0-size pdf that can be used as a template for a team’s Skills Matrix.  I highly recommend using these to get started.  If you are a manager, ask your ScrumMaster or Process Facilitator to arrange and facilitate a team workshop to do the initial population of the Skills Matrix, rather than doing it yourself.  Once that is done you have a baseline and you should take regular digital photos of the team’s Skills Matrix for record-keeping and as a backup in case of disputes.  You should also let the team know that you will be basing performance reviews on how they improve their skills.

The development goals that team members set then should be made such that every team member understands that they have a responsibility to diversify their own skill set and assist other team members in doing this.  As a manager, you should review each team members’ goals for development and provide mentoring support when needed.  At the end of a fixed period of time (quarterly is a reasonable period), you will review each team member’s development relative to the baseline and the goals set.  Of course, normal guidance around performance (or lack thereof) can be given at these regular reviews.

I strongly recommend reading “Drive” by Daniel Pink as an important adjunct to understanding how to do performance reviews for individuals in an Agile environment.  In particular, individual performance reviews should not be tied to bonuses.  If bonuses are used at all, they should be measured and delivered purely at the team level or organization level without measuring individual contribution.

Of course, Agile team performance can’t simply be measured in terms of skills alone.  Performance must also be related to bottom-line results.  This part of performance measurement is separate from the development of the team.  Another aspect of Agile team performance is how well they are doing Agile itself.  Depending on the Agile method you use, there may be various tools to help with this (I would recommend our new product the Scrum Team Assessment as one possible consideration).

Please share!

Seven Essential Teamwork Skills

Learn more about transforming people, process and culture with the Real Agility Program

I’ve been researching teamwork lately.  I just finished reading “The Discipline of Teams” by Katzenbach and Smith which is an HBR summary of their much more substantial book “The Wisdom of Teams”.  I decided that it would be good to be able to describe the essential skills an individual needs to acquire in order to work effectively in a team.  First stop, Google and a search of “list of teamwork skills”.

Strangely, not much turned up on the first page.  The best result is found at “7 Essential Skills for Teamwork” which is a page on a public elementary school web site.  So, here’s my adaptation of their list:

Active Listening

Active listening is a skill that allows a person to completely focus on the communication of another person including both verbal and non-verbal aspects.  Active listening requires the ability to delay thinking of your own responses until after a person has finished speaking.  One simple way of doing this is to echo what a person is saying in your silent internal voice.  When someone says “I think we should build a new gimbal on the widget”, you are saying exactly the same thing in your own mind.  Active listening also requires that you request clarification, often by rephrasing what a person has said and asking if you have understood correctly.  See Active Listening on Wikipedia for more information.


Being able to frame and express questions effectively helps us understand and integrate knowledge into our own mental model of the world, or even to modify our mental model.  Asking questions is easy.  Asking good questions is much harder.  We need to use an appropriate set of words and tone of voice so that we do not alienate or offend the recipient of the question.  For example, asking “why did you do that?” will often put people on the defensive since they will assume that you mean you disagree with their actions.  Instead, saying “I do not understand the reason you did that.  Could you please explain it to me?” can be a much more gentle way of getting to the same information.  Here is a great article about Questioning Skills on MindTools.com.

Logical Argument

When presenting an idea or position, being able to logically support it is important to exploring the truth of it.  This includes being able to share your assumptions or axioms, the data you are basing your argument upon, and the logical sequence of reasoning to reach your conclusion.  Being able to avoid fallacious logical methods is also important.  Some great videos about good and bad logical argument forms on Critical Thinker Academy.


Showing respect includes acknowledging the fundamental human value of the existence of your teammates, and being able to step back from your own understanding of the world to acknowledge the legitimate nature of the perspective that other people have.  This does not mean that you have to let teammates get away with inappropriate behavior.  In fact, respect for your teammates will allow you to support them in behaving in ways that are in alignment with their fundamental nobility as human beings.  Although somewhat simplistic, I really like this little set of rules about being respectful on wikiHow.


Offering help and actually following through with real assistance are aspects of helping.  When you suspect that a team member is struggling with something, you offer to help both verbally and with your actions.  This can take the form of offering information, offering emotional support, offering to assist with problem-solving, or actually taking action to do an activity together.  When we help someone, we share their burden.  Although phrased in a rather self-serving way, this article on forbes.com has a great list of ideas for how you can help others.


Sharing our knowledge, time, skills or physical resources are all aspects of sharing.  Sharing among team members is focused on those things which will help a team reach its goals.  This is similar to helping except that it tends to be more of a transaction than an ongoing activity.  The transaction is that you give a gift and then the other person uses that gift to meet their needs.  Sharing does not require reciprocity.  If you share something with another person, you should not expect that that person will return the gift at any time in the future.  Strangely, there is very little written about this out there on the internet; a Google search found nothing in over ten pages of search results on multiple search terms with the word “sharing” in them.  If you know of some good reference to go into this in more detail, please, please let me know in the comments!


It’s probably obvious, but in order to effectively be on a team, you need to participate!  Participation itself is mostly obvious: do work with the other team members.  However, there are also some less obvious aspects of it.  You are not participating when the team is having a discussion, you find it boring, so you check your email.  You are not participating when the team makes a decision and you abstain from helping to execute the decision because you disagree.  You are not participating in a work team when you are mentally checked out because of a crisis at home.  There is some interesting stuff here on wikipedia about Participation.

All of these skills are critical teamwork skills… but there may be others.  Do you think there are other skills missing from this list that are critical for effective teamwork?

Please share!

The Importance of Questions

Learn more about transforming people, process and culture with the Real Agility Program

I’m currently doing some coaching work with Regina, a new project manager working with a small team of web developers at a community development organization in Toronto.  We had our first session last week. Regina was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.

Regina seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me.  It had to do with an email she received from Peter, a developer working on one of the websites she’s managing. Regina shared a concern that she didn’t know some of the technical terms Peter was using.  So I had her read through the email and form questions around the points she wasn’t clear about – i.e., “what are buttons?” and I wrote them down as she was speaking.

I then suggested that she compose a reply email containing the same set of questions.  Regina’s eyes opened wide and she exclaimed, “Oh yeah – that’s so obvious!”  I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered.  Here are a few:

First, it’s a way forRegina to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo.  Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively.  Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team.  Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.

(Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)

Asking questions in the interest of learning makes it visible to others that you don’t know everything.  For some people, this presents a dilemma.  What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well.  The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage.  Such capabilities – let’s call them moral capabilities – can themselves be developed through conscious, focused effort.

Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness.  But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway.  Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.

Or maybe you’re the kind of person (like Regina) who just doesn’t want to bother anyone.  In this case, humility is not necessarily lacking, but truthfulness – and perhaps most of all courage – may need some attention.  Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.

To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end.  Moreover, it can have a transformative effect on the environment of the team.  When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities.  Not to mention that most people feel good when they are able to help others.  When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.

Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.

Please share!