People Are Not Resources

I spend a lot of time working with Executives and Senior Managers.  Generally, in my very first meetings I ask about the company’s Products vs Project focus.  We then quickly transition to review team structure and stability.  During this process, we dive into current leadership structure, how work is organized and assigned, which roles are present on each team, and how project status and risks are reported.

I am often struck by the use of the word ‘Resources‘ to define people. Resources describe something that can be purchased, such as: servers, computers, photocopy machines and office supplies

People are not resources.  

Teams are living, breathing organisms comprised of people with varying personalities.  Teams must be approached in unique ways to ensure growth and survival.  By defining a team (or individual contributor) as a resource we are saying that the same homogeneous approach can be applied in each case.

Finding resources is not difficult.  We look in a catalog, we choose a product and we place an order.  Several days later, that resource shows up at the door. Ask any manager who has hired a new employee and they will tell you that finding someone to join a team is never that easy.  Retaining qualified people is also not easy.

We have all seen the meme: “5 ways to find and retain good employees”

  1. Create an open and honest work environment.
  2. Provide opportunities to grow and learn, and let your employees know there is room for advancement in your company
  3. Recognize and reward good work
  4. Encourage Innovation and Growth
  5. Allow people to do the job you hired them to do

These five points enphasis valuable insight into how to engage employees.  When managers ask me about switching to Agile and making a transition towards Servant Leadership, I always tell them that the easiest way to make this shift is to remove the mentality that people are Resources. Begin to think of your teams as unique personalities and tailor your approach to them respectfully.


Would you like to hear more about building and encouraging your teams?

Check out our Agile Leadership courses



Scrum Does Not Tell You How to Build Stuff

There have been some respected leaders in the industry that evidently just don’t get what Scrum is meant to provide and, more importantly, what it’s not.

Scrum does not tell you that you have to use TDD, BDD, Continuous Integration, Continuous Deployment, OOP, etc. Scrum also does not tell you that you have to use User Stories that are estimated with the Fibonacci-ish scale. It doesn’t tell you how and if to do exploratory testing, load testing, performance testing, acceptance testing, or anything else.

Why? Because it wasn’t meant to. Are all of the things I mentioned above good things? Absolutely! Is every team ready to adopt them? NO.

100% of the teams that I’ve coached were not ready to take on the additional stress of learning these practices that Scrum does not require. The FIRST thing they had to work through was how to be a team. How to understand what commitment means. How to respect and trust each other. How to feel and be empowered. How to build trust with the customer that had been long lost or most likely never existed. How to better predict what will be delivered. What it means to deliver VALUE.

Focusing on these things is many times almost more than a team can handle. I’m surprised that anyone would think it would be a good idea to right away add on top of this the pressure of learning new technical practices. The fact of life is that most enterprises do not have the processes, infrastructure, or culture that allows quick adoption of modern development practices. Change takes time. Take a deep breath and embrace it. Only then will you be able to make real change.

Talk to Us Today

Your Scrum Team Might Be Too Big

According to the ways of Scrum, the optimal Scrum team size is between five and nine people. Interestingly, I’ve seen this as a point of concern (sometimes contention) when I’ve coached people on Scrum. Please note that this is not a rule that must be followed at all costs. God gave us a brain, so we should feel free to use it.

While I know it’s rare, I personally have seen successful teams that consisted of 10-15 people. I believe that if a team consists of any more than 15 (or so) people, you are reducing your velocity.

Now you have a bloated team.  What should you do?  Well, first thing you should consider is to take some ideas from Kanban. Visualize the work, make the process and policies explicit, limit work in progress, measure/minimize cycle time, etc. (read more on Kanban here)   The purpose of all of this is to gain clarity on what kind of work is actually taking place.  In addition, you will gain insight into the quality of the deliverables and where the bottlenecks are.

Once you have this information in hand, you then have three choices.

1.  Split the team into multiple teams.I have seen large teams have several very distinct types of work occurring. If there are distinct types of work, i.e. completely different categories of stories/requirements with different goals, and the team is forced to act as one, then there is waste. For example, during the standup, there will be members of the team that have to endure hearing the updates about requirements that they have no interest in, nor can they contribute to the delivery of those items (usually). This is likely the optimal choice.

2.  Reduce the number of people on the team.This is the tricky one. You may find that there are people that don’t have the necessary skills, or you may find that there are too many people with one very distinct skill set. If one (or both) of these scenarios holds true, and you are sure that these folks can’t contribute in other areas, then make haste and remove the people from the team. Everyone (including those let go from the team) will end up happier and more productive.

3.  Keep everything the way it is. This is a very, very unlikely choice. I have never personally experienced a time when it was a good idea to keep one team larger than 15 people. I would love to hear from others where this has worked well.

If you are a Scrum Master, and you are experiencing team bloat, then it is your responsibility to recognize it, determine if it’s an impediment towards improvement, then handle it.

Talk to Us Today
post =