One of the things that I see when dealing with agile teams and new challenges is people being either unwilling or incapable of accepting the challenge. Of the two, unwilling is a lot worse than incapable. Dealing with teams that are unwilling to undertake a project, or are incapable to doing the project present special challenges. Part of the problem identifying what’s going in is that on the surface, unwilling presents itself as incapable.


Incapable means lacking the capacity, ability or qualifications to get it done. ( Capability can be enhanced fairly easily; removing barriers, adding people, re-prioritizing, etc.  Capability is a completely fixable problem in the realm of being a scrum master.  Being incapable pretty much breaks down into two categories: either lacking the time to do the project or lacking the skills to do the project.  Both of these general classes of problem can be fixed in a pretty straightforward manner.

Lacking the time really comes down to two things as well; either there is too much other stuff going on or the deadlines for the project are too tight. Both of these are solvable problems and pretty much have the same solution: scope management.

Lacking the ability to do it is reasonably simple to deal with as well.  After all, it’s a chance to learn new skills and make things happen. I’ve never encountered a developer who doesn’t want to do learn something new, well there have been a few but certainly not the ones I want to work with long term. The biggest barrier tends to be a confidence problem.  Saying “I know I just learned about it, I’m not sure I can guarantee results though” is a common way that this manifests.

The important thing to remember is that when you make a dramatic change, like changing technology or team members that the velocity that the team won’t be relevant.  That seems to be the biggest leap of faith that scrum masters make – everything changed except for velocity.


Unwilling means to be reluctant or offering opposition to perform the challenge. ( Willingness, the desire to make it happen is harder to create. In theory you can motivate people to get the job done.  Finding out what motivates someone is a much harder skill to learn than dealing with the somewhat mechanical problems of capacity, or training.

Telling the Two Apart

The typical way that being unwilling manifests itself is masquerading as incapable.  There’s always a reason that it can’t be done. Sometimes, those reasons are legitimate – “I don’t even know how to pronounce C#, I’m a ruby developer.” Sometimes, not so much – “C# is too corporate, we should be doing this in ruby.” The first is incapable, the second is unwilling.

My usual approach to this is to say “what do we need to be able to do to deliver?” When the problem is an incapable one, a plan of what needs to happen tends to emerge fairly quickly. the conversation quickly turns into “We need to learn A” and “Oh, and we need to know B or find an expert on B that can help”. Once that discussion gets started, the scrum master’s job gets back to being a facilitator for the meeting and helping to remove blocks.

When the problem is an unwilling, the problems tend to be insurmountable. That’s not to say that there aren’t impossible challenges, just that seemingly reasonable challenges get identified as impossible. I will admit to being extremely undiplomatic when it comes to dealing with unwilling participants; I like to hear about how to solve the problem, not that it can’t be done. When it’s put out there as impossible, my usual attitude is “the door is over there, don’t let it hit you on the way out.”

In the end, being unwilling usually comes down to “it can’t be done”. Being incapable generally means that you can come up with a plan to solve the problem. The plan may take longer than expected to deliver, it might require new things or team members; but there’s  a plan that seems workable.