Managing People in an Imperfect Agile Scrum Team

Managing people isn’t easy thing whatever process you use. With Agile processes putting explicit emphasis on people and interactions it is even more important.

Agile Scrum is a team empowerment framework. Scrum is an agile product management process that is based on the clear separation of what’s and how’s – Product Owner is responsible for what’s, the development team is responsible for how’s. This clear separation puts big bet on the team’s ability to self-organize and figure out what exactly process and practices are best for it.

In my practice I’ve seen teams that gelled successfully, communicated with their customers frequently and were indeed able to self organize to whatever was needed for the frequent delivery of good software wanted by the customers. However, I also experienced teams that are struggling despite the credit from management. Their Product Owner (or Product Owner teams) were able to fix the product priorities for a sprint, they did explicitly tell that they want less features and more quality, they did allow their teams to work on architecture as much as they needed and still the quality wasn’t on par with the expectations. The testers tested according to the scripts (and not according to what the user might want do), POs often were able to find obvious bugs during the sprint review demos, etc. Despite all the trust credit these teams just didn’t self-organize.

Self-organization rarely happens on its own. Self-organization requires a common goal, boundaries and knowledge of some simple rules. Learning the self-organized team behaviors takes time and determination. The whole team has to walk a path from novice to an expert and needs different styles of support from directing to delegating. A good Scrum Master or decent Agile coach rarely if ever tells the team to do whatever they want from the day one of the Agile adoption. Learning the new way of working takes time and in the very beginning the amount of guidance might be even bigger, than in the world of command & control. Coach just has to be clear that it is temporary and is needed only because the team is new to the process.

Scrum is an excellent process that suites many teams and by empowering them can lead to the truly amazing results even under the tough conditions. However, the ability to utilize high level of empowerment and self-organization isn’t something to be developed overnight. It is something to nurture and to care about.

May be some team will never ever be self-organized no matter how long they will work together and how many agile / lean coaches they will meet? Is it something like marriage. Isn’t is that some people work together pretty well and some other combination actually suck. It’s all about people, no training could change people’s characters and I think personally that finding a good agile team is difficult and if you find one you should treat it like a precious stone

Some people tell me that “you cannot motivate a person“. You can only “remove the impediments that prevent a person from being motivated”. Or, in other words, “you can only eliminate demotivation“.

Can you make a person happy?


can you only eliminate the things that make her unhappy?

Can you make a person laugh? Or can you only eliminate the things that make him cry?

These sound like silly questions. But I have been told a number of times now that trying to motivate people is a bad idea. Yet, I simply could not imagine this to be true, given the fact that it is quite possible to (try to) make people happy, or to (try to) make them laugh. You cannot motivate a person by “eliminating demotivation”. Only taking away the things that make people dissatisfied, will simply result in people having neutral feelings towards their jobs. But that’s not enough. You also have to introduce things that motivate them.

Feedback, communication, and motivation are key factors in three Agile Manifesto principles that lend themselves to successful project team collaboration


How does feedback work in a team environment? What is the most successful way to deliver it on an Agile project? Remember that feedback during the iterative development work of an Agile project must increase awareness and insight as well as foster innovation, yielding positive alternatives. Having the business as part of the core Agile project team creates the environment for continuous feedback and an opportunity to take positive risks in doing things differently, which is the very nature of why the project is being done in an Agile setting. Within the iteration work, it is essential to provide feedback that:

  • Contains a clear purpose
  • Is specific and descriptive
  • Offers positive alternatives

For all members of the Agile project team, it is important to identify what to start, stop, and continue doing when it comes to iteration work. This is where effective feedback is most often used. You can easily integrate these practices into your daily stand up meetings to prepare for the day’s work.


What makes effective communication? When it comes to communication, it is important to deliver information in a manner that is understood by the receiver, which means that we need to get past the receiver’s filters and ensure that the individual understood the intended message. To get past those filters, we, as the sender of this message, have a responsibility to understand how our receiver takes in information. Does he communicate in a direct manner? Is she considerate in her messaging? Understanding your receiver’s communication style will help you provide feedback that enables effective dialogue.


When you combine productive feedback with effective communication, the foundation for motivation has been established. Motivation is built on encouragement, partnership, and compromise without making concessions that damage trust. Working together to ensure that barriers, impediments, and unrealistic expectations do not derail the creative impulses of the team brings about team unity. When the Agile PM delegates to team members the authority and responsibility to complete features to which they’ve committed, the Agile PM has created an environment of trust, partnership, and self-directedness. By creating this environment, the team can discover their patterns of working.

The soft side of Agile is just as important as the technical side of Agile. Both sets of skills are required and dependent upon each other for success in the Agile Scrum environment. Given what you just read, ask yourself, how soft is your Agile Scrum team?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s