BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

The Role of Project Managers in Agile

Posted by Vinay Aggarwal on Sep 02, 2009 |

Agile, as per books does not talk of role of manager but talks of a coach/facilitator. This article first explains the role of project manager in general in any industry and then tries to map it with the role of coach/facilitator in Agile. During this discussion, the article also tries to widen the scope of being a coach/facilitator.

Before we discuss the role of project manager in Agile, let's first see why managers are required at all in any industry.

  1. People are not perfect

    Working with human minds is very complex. No two brains in the world can think alike. Like two fingerprints can never match, style of work of two individuals can never match even 90%. Let's appreciate the beauty of nature who created so many individuals but all different. But business goals remain “one and same” for all stakeholders. People here mean all the stakeholders involved in the project in various capacities like (a) project team members (b) business users (c) management and financiers. People are required to be managed everywhere in every project to:

    1. Keep them aligned with project goals and fine tune their style of work.
    2. Bring best out of them.
    3. Help them stay focused and motivated.

    If everyone in the project is perfect - no project in any industry would ever fail, no need of any software development methodology be it Waterfall or Agile, perfect people would anyway make it a perfect project.

  2. Controlling the change

    Change is the only constant in life. Everything can change be it tangible (e.g. requirements) or intangible (e.g. people).

    1. Requirements are like wind that always blows (means change).
    2. People's experience and exposure is changing every day [e.g. my experience tomorrow will be +1 day as compared to today]. This can bring change to my:
      1. Aspirations
      2. Skills
      3. Commitment
      4. Attitude
      5. Any other soft or hard skill
    3. Business is dynamic and market is changing every minute. With this, customer expectations may change.
    4. With change and innovation happening in technology every minute – software project environment, architecture and design and development processes may change.
    5. Resource movement is inevitable in long projects.
    6. In terms of mathematics, planning is a function of time. Howsoever perfect planning you do be it at program level, project level or sprint level – it may lose its validity tomorrow. Every attribute in planning (any sort of planning at any level) has an expiry date which can be as close as tomorrow. When everything is changing constantly and unexpectedly, how can yesterday's planning be valid tomorrow.

      In this context, role of manager is:

      • To keep the people continuously motivated and engaged with the project.
      • Working out resource movement with a realistic transition plan with minimum impact on business.
      • Keep an eye on the plan, let the plan evolve with time and accordingly take extra steps to manage the impact and change.
      • Since team members and plan – both are dynamic, keep communicating to stakeholders about impact and mitigation.
  3. Communication causes gaps and conflicts

    1. Communication is root cause of all happiness and also of all conflicts.
    2. It's an ART that always requires diligence and must be thought through to think ahead how the message will be perceived by the audience, does it offend anyone, does it has necessary weight to communicate the message well and strongly. Very few people in the world possess this ART.
    3. People in development are generally too focused in technology thereby ignoring (knowingly or unknowingly) this fine art.

      A project manager controls the communication to large extent. S/he should also delegate some responsibilities to other team members as and when they are comfortable to pick it up.

  4. Processes are not perfect

    1. No process is ideal (e.g. software development methodology be it Agile or waterfall has gaps, no ideal process to define customer-supplier relation piously and if there is, it's almost impossible to carry it in true spirits)
    2. Even if a process works absolutely fine with one person or in one situation, it may terribly fail with another person in different context

      Manager is expected to let the team focus on results and not too much worry about process. “Processes are for us, we are not for processes” – which means following process is not the end goal but it is just a tool to achieve certain results. See manager along with the team to decide what part of the process is the best for this project and apply only that one.

  5. Processes not implemented properly

    1. Process implementation always means more work, more diligence, more tracking which any development team in general tends to avoid. Process overhead is considered an evil by many people.
    2. It's rare to know that a particular process in a project has been implemented 100% in true spirits for the entire duration of the project.

      Any process violation which may lead to indiscipline and impacting the project adversely, manager should intervene and ensure high degree of compliance for all of the good practices.

If all of the above 5 reasons are false than no industry would ever need managers. But unfortunately, all of the above 5 exists in every industry, every company, every project and every sprint. The investors and shareholders must get good returns on their investment (RoI) in any project. Hence there needs to be someone who can balance out these things and still help achieve business objectives of the project. All of the above mentioned five attributes are non-technical in nature which can be best addressed by applying management practices. And the person who performs this role and brings management practices into a project is called ‘manager' in corporate world. But it does not mean managers have any magic pill to make the above PERFECT but they help the people and processes to fine tune, to monitor and apply lateral thinking management concepts to come up with creative solutions so that above five does not impact the business goals to large extent. A subset of this role is described as coach/facilitator in Agile terminology.

Agile coined a new term called ‘self-organizing team'. I am personally a big fan of self-organizing team. It works fine many times especially in those cultures where people display very high standards of responsibilities and duties in public life. This is because people carry forward these high standards to office also and become a perfect match for ‘self-organizing' team. To have every employee working in a self-organizing mode is the dream of all corporate. But like all human beings are different and unique hence not everyone can be eligible to be fit into ‘self-organizing' team. e.g. every doctor cannot become surgeon or dentist or orthopedic but still every doctor is useful to the society. Similarly it's impossible to expect from everyone to work in a ‘self-organizing manner'. Though same individuals (who does not fit into definition of self-organizing) can still be great contributor provided handled differently. This is where role of project manager becomes very useful who with little or more (depending upon individual) supervision can extract the best work from a team member. Agile uses the term ‘coach/facilitator' for this kind of role. Again, this role would work fine when people deviate a little from being self-organizing. In following 3 scenarios, coach/facilitator may have to widen his scope.

  1. People who deviate too much from being self-organizing (e.g. highly unstructured, highly unfocused, emotional etc.)
  2. People's soft skills are not aligned to business needs (e.g. inability of being proactive, afraid of speaking, poor communication, poor time management etc.). Lack of these soft skills would never allow true potential to translate into performance.
  3. People infected with corporate evils (e.g. back-biting, jealousy, showing off work with shouting, holding the knowledge, sycophancy etc.). Technically these people can still be made productive provided a strong manager (not coach) controls these people with constant monitoring and nips these evils even before they start impacting the team dynamics.

My intention here is that we should have high degree of acceptance for all professionals. But the way to handle and bring best out of an individual is different for everyone. There is no one rule of thumb that can be applied to everyone by default. This is something organizations need to introspect. There are very good techies in all countries who can be very good contributor but may not be self-organizing. This is where coach/facilitator would move more towards being project manager. These people may make mistakes, may need guidance and supervision, and may be missing on soft-skills and so on. Within the limited scope of coach/facilitator, it will become nightmare to align these kinds of people with Agile and get the work done. I have full respect for all kind of people and strongly believe these people can also be great contributor but you need to widen the scope of coach and give him some kind of authority to tell strongly ‘dos and don'ts'. This is where role of project manager becomes useful. The following table demonstrates a few other areas where need of project manager is felt.

Sr.No.

Fact

How Agile helps

Where Agile does not help

(here manager can help!)

Remarks

1

People are not perfect

Having daily status keeps them focused and product owner (PO) keeps the requirements aligned with business.

1. If focus is in right direction?
2. If product owner (PO) changing goals in every sprint?
3. If accountability is really being shared? What if everybody thinks other person is more accountable because he has more experience or more knowledge?
4. Are people hiding incompetency on the name of Agile?
5. Is team really self-organizing?
6. Are people finding outward reasons as an excuse or really improving?
7. If one individual in the team is trying to take all the credit thereby disturbing team dynamics?
8. If someone is holding all the knowledge and not sharing with team?

A manager with lateral thinking can devise innovative ways to manage imperfections.

Coach can tell how to do things in right manner but what if people don't follow? E.g. what if team does not take feedback from product owner after the demo? Is it acceptable or to be enforced?

2

Controlling change

Agile welcomes new requirement at the beginning of each sprint and scrum master prevents scope creep during the sprint.

1. If Scrum master playing its role properly?
2. If tester is doing its job at right time? 3. If people's soft skills and commitment is changing? 4. If customer suddenly starts disbelieving in Agile? 5. If customer suddenly starts expecting unrealistic things?

Agile takes care of change in priority of requirement which is only one part.

Product Owner (PO) using his influence can add the story even in the middle of the sprint and team does not know how to handle it?

Intangible changes cannot be addressed by any methodology.

3

Communication is not proper

Agile provides opportunity to communicate every day in stand ups. Also creates a platform to speak his/her mind during retrospectives.

1. If team really raising impediments?
2. If team is proactive to communicate everything?
3. If communication is well understood by audience?
4. If there is language or cultural barriers in our communication?
5. If distributed communication is a bottleneck? If user experience is good?
6. If all emails are replied and replied as per expectation and with good quality?

Corporate communication is a very different subject then knowing programming and also very tough one.

Management studies explain fine art of communication.

Soft skills cannot be addressed by any process.

4

Processes are not perfect

Agile helps in software development.

Every methodology has its limitations and at the end of the day, it's people who have to make the project success.

Bad Agile is worse than no Agile.

5

Processes not implemented properly

Agile is a process whose implementation is dependent on people.

1. Are people following processes?
2. Can processes be improved?
3. What subset of processes is appropriate for my project?
4. Where are exceptions and when it is ok to deviate from process?

A small example - in Agile, is team doing excess pair-programming?
When a best practice is really the best practice for my project?

A project manager can extend his/her role beyond being a coach/facilitator if things are going wrong. S/he can control those team members who are not Agile by nature or by intentions. I would like to address 3 common myths prevalent in the industry. These myths are more prominent in the context of Agile.

Myth#1: Managers have magic pills.

Reality: Dealing with human minds is very complex and most challenging. There is no science, it's a pure ART. Whatever you do, there will still be people who are unmanageable and there will be changes uncontrollable. In my humble opinion, a good manager can:

  1. solve 50% of problems completely,
  2. partially solve 15% of problems,
  3. can make 15% of problems looks like no impact problem or out of scope by making them explicit with the help of communication,
  4. 20% problems are such that they always remain (some people in a certain context and some changes can never be managed). We must accept this.

Please note that above figures is only an expression of my experience and not based on any scientific study or research.

Managers are also human beings who are as imperfect as anyone else. Management is a different concept with holistic approach. It's a different profession all together that is designed to manage people and processes with imperfections. People with a good experience and study of this subject can bring a lot of value.

Myth#2: Managers always curb freedom.

Reality: May be true for some bully managers. But in reality, a good manager creates an environment that enhances performance thereby bringing BEST out of people. A manager with experience and vision may curb team's freedom temporary but it has an objective that eventually helps people only. Sometimes people are not able to visualize that far ahead because of (a) lack of experience (b) working in extreme comfort zone (c) arrogance that always has side effect of shortening the vision (d) any other unquoted reason.

It may also be the case that incompetent people have fear of being exposed and hence, they feel managers curb freedom. People who have zest to perform should raise their bars, use manager's experience to plug gaps and work closely with him/her thereby taking more responsibility and let the manager rest in peace.

Myth#3: Manager should not have authority.

Reality: Some countries and cultures by default inculcate responsibilities and duties in public life. The authority is not required in these cases, a coach/facilitator would work perfectly fine in these kinds of environments. But concept of authority is more relevant in those societies which are still evolving and yet to reach a maturity level. In order to control any of the above 5 reasons (mentioned at the beginning of this article), any manager has to have authority in those environments. A manager without authority would be like a car without fuel. Studies have revealed that human mind by psychology (especially in adulthood) is like a hard iron bar which is very difficult to bend. In order to shape the iron into a beautiful vessel, authority is required. The moment, whole world becomes so diligent, responsible, mature and high performance in a self organizing manner – all management institutes would be closed globally.

Conclusion

Agile is a very good software development methodology that helps iron out some of the wrinkles of the traditional waterfall process. But Agile is not a trump card for the success of the project. It's the same people who have to work and perform. When it comes to people, it's always a challenge to deal with. This world (hence people) is full of problems and imperfections. Scientist tries to help the society by innovating technology. Similarly, management is a profession that helps people succeeds in business goals or professional goals despite working within constraints. No methodology can make a manager redundant until unless executed by perfect people. A process is a set of guidelines. When there is a process there is deviation; when there are people – there are problems. To manage people and problems and control deviation or changes – every project has to take help of management profession. At the same time, managers are also human beings. They belong to the same world made of imperfections. Certain management decisions may also fail. Stakeholders must accept this. In certain environments, managers may need authority to apply certain measures in the best interest of the project. These measures may find resistance among team members and hence in order to apply them – sometimes a coach/facilitator works fine and in some other context, a manager with authority would work fine.

About the Author

Vinay Aggarwal is a delivery manager with Xebia IT Architects, India. He has 11 years of experience in IT industry. He holds bachelor's degree in Engineering. He is a PMI certified project manager (PMP) and Certified Scrum Master (SCM) also. He has worked in companies like IBM and Accenture in the past. He has a very good experience in both waterfall as well as Agile (Scrum) methodologies. He believes in lateral thinking and applies management concepts to handle various delivery challenges.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Emergence vs Managing by Udayan Banerjee

Most of the points you have raised is valid - but the standard management practice does not handle the phenomenon of emergence very well - and agile is about emergence - setandbma.wordpress.com/2009/04/25/agile-method...

Authority vs Leadership by Ian Ribas

I tend to agree with the remarks, and think that there is nothing in the Agile methods that contradict the use of management knowledge to aid the well conducting of a project. In scrum, as far as I know, it is even explicitly indicated that scrum master is a management role.

One comment is that, in my point of view, it is better to use leadership than authority whenever possible. And that good example and peer pressure may do wonders.

blind leading the blind by Michael James

If I've yet to master the skills of getting an airplane off the ground, it would be unhelpful for me to advise other beginner pilots they'd better stick to driving because "flying is only a myth." (Or worse: "Flying doesn't work in India.")

The author's misconception that self organization is about individuals -- rather than teams -- probably has something to do with his inability to create the environment for effective team self organization at Xebia. Being an effective ScrumMaster involves a way of being that often doesn't come easily to project managers raised on Taylorism. A manager who sees people as "hard iron bars" to be bent has a lot to learn about human motivation (apparently much more than a two-day CSM class can provide).

Using psychology to excuse Taylorism reveals even deeper misconceptions. Please see _Group Genius_, _Flow_, and _Punished by Rewards_ to see what other psychologists have discovered about the relationship between autonomy and productivity/ingenuity.

The fact this author hasn't managed to create team self organization in this situation (yet) doesn't imply it is impossible for him to learn to do so. And it especially doesn't imply others shouldn't try.

--mj
.
. An example checklist for serious ScrumMasters: tinyurl.com/cvdwor
. 5-page illustrated summary of Scrum: refcardz.dzone.com/refcardz/scrum
.

Re: blind leading the blind by Vinay Aggarwal

Hi MJ,

Blogs and article are there to share opinion and experiences. It is absolutely fine if you disagree. I respect every opinion. But I am disappointed to see your personal attack and using sarcastic language. I think you should know how to express yourself in public space in a polite manner. Looking at your communication, it makes me feel happy that what I am saying really makes sense for the people like you. I take it as an endorsement of my opinion.

Thanks!

Taylorism and Self Organizing Teams (was Re: blind leading the blind) by Amr Elssamadisy

Rather than turn to "my company is better than yours" or "my country is better than yours", let's focus on the REAL question:

Are self organizing teams the be-all and end-all of teamwork? Does management - traditional management - no longer have a place? Is all hierarchy bad and to be labeled the software equivalent of terrorism by calling it Taylorism?

Although I disagree with the author on many points, I recognize that there still is a need for hierarchy working alongside self-org teams.

Re: blind leading the blind by Michael James

Sir, you seem unaware of why your article comes across as a disservice to Scrum team members of other nationalities (presumably Indians, as you are based there).

You wrote "Some countries and cultures by default inculcate responsibilities and duties in public life. The authority is not required in these cases, a coach/facilitator would work perfectly fine in these kinds of environments. But concept of authority is more relevant in those societies which are still evolving and yet to reach a maturity level."

It turns out team self organization is challenging in *every* country, not just the ones you consider to be evolving and immature. I'll assume again you mean India. We've seen Indian teams self organize when they have effective ScrumMasters creating the circumstances encouraging it. (I'm told this is the case at Xebia also.) The misconception Indians are culturally incapable of it is offensive.

The fact individuals are imperfect, and managers cannot supervise them every minute, is exactly why Scrum replaces manager authority with teammembers' authority to manage each other. The focus is self organizing *teams*, not individuals. And a small percent of individuals in every country are not suited for Scrum teams. Believe me -- I've also seen American teams eject team members.

You wrote "In order to shape the iron into a beautiful vessel, authority is required."

So it's up to you, the manager, to judge whether the individual is "a beautiful vessel" and what "shaping" is necessary? Can you see how this concept would be offensive to a ScrumMaster, or any other humanist? This is not a new idea -- Frederick Taylor wrote the same thing 100 years ago. Taylorism worked OK for simple mechanical work.

When the ScrumMaster creates the circumstances for team self management, it becomes a more powerful force for influencing individual behavior than any manager playing the boss/worker game.

I really do encourage you to read the books I listed (perhaps start with _Group Genius_, an enjoyable book describing empirical teamwork studies). Once you have seen the power of team self organization, I think you will reconsider the 100-year-old reflex to use the style advocated in this article.

--mj
.
. An example checklist for serious ScrumMasters: tinyurl.com/cvdwor
. 5-page illustrated summary of Scrum: refcardz.dzone.com/refcardz/scrum
.

Re: Taylorism and Self Organizing Teams (was Re: blind leading the blind) by Michael James

Um, neither Mr. Aggarwal nor I have claimed my company/country is better than yours. In any case, I work with many companies and come from more than one country so this claim wouldn't make any sense.

During Sprint execution, effective Scrum teams have a natural, flowing, hierarchy that shifts from moment to moment. How they relate to the outside organization (and other teams) is an interesting question, but the general observation has been manager authority will dilute the team's self management authority, *institutionalizing* what ever impediment we were trying to solve with this quick fix.

Re: blind leading the blind by Vinay Aggarwal

Dear MJ,

Let me explain you my points again with an analogy. A heart patient has a goal to get well. He goes to a doctor who gives various solution. I am considering myself a doctor in this analogy. The doctor suggests:

1. Take 1 hour walk daily and don’t eat oily food, it will strengthen your heart. No medicine is required. (equivalent to perfect self-organizing)

Many patients follow the above and get recover well.

2. Patient didn’t follow the advice and condition worsens. The doctor says you need to take tablets/medicines, may be even injections. But still you need to walk and avoid fatty food. (equivalent to Agile coach/facilitator who is trying to fine tune the patient’s heart because patient didn’t follow 1st advise and was not self-organizing at first place)

Many patients recover after this step.

3. Now, patient did take some medicines but not properly and still didn’t follow the 1st advice (walk and good food). Condition deteriorates further. Now to save the patient, every doctor in the world would recommend heart bypass surgery or any kind of surgery otherwise patient would die. (this is equivalent to authority)

Although the above example is self-explanatory but still I would like to elaborate.

Now, how long you continue to teach the patient the benefits of walk and food when he is not following and he is on the verge of dying? Would you throw him out of family, out of society? In my opinion, if you are a well wisher of the patient, you will ask the doctor - whatever it takes – please save the patient. This is exactly my whole point is all about.

I would like to share a true story – outside India, outside Xebia. One of my friend is a CTO in a company. He is a strong believer in Agile just like any of you. He told me the following.

1. His team didn’t call the product owner (PO) after the sprint demo. The PO said in retro – sprint failed. The CTO explained the benefits of collaborating with PO and inspired team to take PO’s feedback after demo.
2. Team didn’t listen, didn’t take the feedback of PO after demo. Again, sprint failed and PO escalated. The CTO again tried to inspire the team.
3. Team on the name of freedom, arrogance, trust – still didn’t listen. Sprint failed, 3 times in a row. PO was about to scrap the project.
4. Now CTO said – better you following my instructions. If next sprint fails – I will fire you. Now, team came out of their comfort zone. Till date, project is doing great! Now the team has also become self-organizing to large extent. But someone had to show authority at least once to set the things back on track. This is exactly my whole point is all about.


My thoughts are not based on experience in Xebia but the article is based on my 11 years of experience working in various countries. So I don’t appreciate if someone relates everything written in my article with Xebia or even to India. Then I must say someone has completely misinterpreted me.

I used the word authority only at very few places which you captured. In rest of my article, I am full praise of self-organizing teams which I guess you missed completely. I suggest one should try to understand the concept in a holistic way with bigger picture in mind instead of getting offended by a few words from the article. I am open to further discussions provided you see it in a holistic way.

Methodology depends on the nature of the project by vivek raman

Having a controlling figure within the team would be beneficial if the type of work being done was high volume and low value and members of the team were mostly in-experienced.
In my opinion, Software projects that demand innovation and creativity would be stifled by an environment that the author suggests.

OK, point taken by Michael James

The story gives me a better view of your motivations for this article, and I apologize for "blind leading the blind."

For a team we're not sure about, I can see value in using a more forceful approach in the beginning, to disrupt previous habits and establish initial conditions more likely to lead to effective self organization. It's true many teams never leave their comfort zone, or they may be slow to realize their coach is actually their lifeline to a more satisfying career in the future.

When I chatted with Jeff Sutherland on this topic, he suggested this article:
jeffsutherland.com/scrum/SutherlandShockTherapy...

--mj

Re: Methodology depends on the nature of the project by Vinay Aggarwal

Hi Vivek,

I agree 100% with your first statement. In fact, if I have to summarize my whole article in one sentence - your statement would be very close to describe it.

At the same time, I wonder how did you deduce your second statement. I am not suggesting any environment by the way. I am suggesting that being Agile does not rule out the need of being manager. And in some extreme situation depending upon nature of either the project or team or individual - sometimes (only sometimes, may be 10% times) authority becomes necessary. Please read my analogy of heart patient again.

I am open to further healthy discussions to help clarify my message and your understanding.

Re: Methodology depends on the nature of the project by Bhardwaj Velamakanni

The author says: " But concept of authority is more relevant in those societies which are still evolving and yet to reach a maturity level"
_________________________________________________________________

The question here is "What is easier? Introducing the role of a Project Manager by diluting Scrum a little, or working on the team to halp it reach the required maturity leves as fast as possible?"

IMHO, there is no straight answer for this - it varies from team to team. In an environment where every member of the team understands the concepts of "Focus, Openness, Commitment, Courage and Respect", I would rather go with the latter approach.

However, in a typical case of a service oriented organization based out of India, where the Project/Delivery Managers more often than not are forced into a situation of having 1 experienced member and 3 fresh college grads in a team of 4, the second approach will be a big challenge and what Vinay says is more relevant in that sort of situation.

(PS: I dont mean to sound racist here - being an Indian myself and having worked with the Indian companies for quite sometime, I do understand the difficulties the Project Managers face out there)

Re: blind leading the blind by Bhardwaj Velamakanni

Hmm, I have a slightly different take in the above CTO example. Was the CTO acting as a Scrum Master for the team? If so, then I would like to share this:

* The team had not been coached/trained well

* I assume that they conducted retrospectives immediately after the Demo. So how would that matter whether they had feedback immediately after the demo or not? The PO was to give the feedback in the Retro in any case.

The root cause of the problem seems to be the PO not being kept in loop throughout the Sprint and the feedback had been solicited only after the demo. Ideally, I would have the Demo as an activity to display the Sprint's end result to the entire company. At my organization, the Product Owner leads the Sprint demo and presents the work to rest of the company.

These things are bound to happen if the PO is not well integrated with the team. Otherwise s/he wouldnt have said that the Demo failed (Since the Demo could have happened only after s/he had accepted the stories as complete)

In this case, the correct approach would have been bringing the Product Owner and the team together on Day 1 of the sprint and keeping them together until the Demo. The Scrum Master didnt do it, but chose to use the authority to threaten the team!!!!!!!

Re: blind leading the blind by Kent Dorsey

Your story quoted below does not mention a Scrum Master role. That role would have held the agile team to the demo and inspect-adapt part of the agile lifecycle. In that absence, I do not understand how the team could be characterized as practicing agile, at all, as they did not follow the basic manifesto to emphasize communication with the client. In fact, I suggest that your characterization of the team as agile will lead many to dismiss your understanding of the agile process.

Self-organizing does not equate to no supervision and no coaching, yet that is the subtext that emerges from your article based upon my reading of those who have posted replies. There is no self-organization step without a Scrum Master.

Your analogy with a doctor characterizes agile to be self-help instead of joining a team and adopting and following the team principles. There is no step 1 separate from step 2. The team should provide feedback to hold members accountable to principles, while the Scrum Master does the same for the entire team. A Scrum Master does in fact have "authority". Without authority from management, the role will be ineffective and would not actually qualify as a Scrum Master role, at all.

You appear to be dismissing the substantial amount of negative feedback and criticism being provided. Based upon the repeated need to clarify the intent of the article, I would suggest that your attempt to communicate your findings and principles has substantially failed. Isn't that obvious based upon the reply threads?

You appear to be reluctant to come to accept responsibility and to arrive at that conclusion. Instead, I see you shift the burden again and again back to the reader. I suggest that InfoQ has failed to provide robust editing of your article, and should be taken to task for that failing. That appears to have become a trend here.

Others have touched upon your wording in regard to cultural behavior. I must agree that the non-technical wording used to characterize cultures and behavior is highly inappropriate and only servers to distract the reader from your true intent.


Let me explain you my points again with an analogy. A heart patient has a goal to get well. He goes to a doctor who gives various solution. I am considering myself a doctor in this analogy. The doctor suggests:

1. Take 1 hour walk daily and don’t eat oily food, it will strengthen your heart. No medicine is required. (equivalent to perfect self-organizing)

Many patients follow the above and get recover well.

2. Patient didn’t follow the advice and condition worsens. The doctor says you need to take tablets/medicines, may be even injections. But still you need to walk and avoid fatty food. (equivalent to Agile coach/facilitator who is trying to fine tune the patient’s heart because patient didn’t follow 1st advise and was not self-organizing at first place)

Many patients recover after this step.

3. Now, patient did take some medicines but not properly and still didn’t follow the 1st advice (walk and good food). Condition deteriorates further. Now to save the patient, every doctor in the world would recommend heart bypass surgery or any kind of surgery otherwise patient would die. (this is equivalent to authority)



I would like to share a true story – outside India, outside Xebia. One of my friend is a CTO in a company. He is a strong believer in Agile just like any of you. He told me the following.

1. His team didn’t call the product owner (PO) after the sprint demo. The PO said in retro – sprint failed. The CTO explained the benefits of collaborating with PO and inspired team to take PO’s feedback after demo.
2. Team didn’t listen, didn’t take the feedback of PO after demo. Again, sprint failed and PO escalated. The CTO again tried to inspire the team.
3. Team on the name of freedom, arrogance, trust – still didn’t listen. Sprint failed, 3 times in a row. PO was about to scrap the project.
4. Now CTO said – better you following my instructions. If next sprint fails – I will fire you. Now, team came out of their comfort zone. Till date, project is doing great! Now the team has also become self-organizing to large extent. But someone had to show authority at least once to set the things back on track. This is exactly my whole point is all about.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

14 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT