Forums

By posting to our forums you are agreeing to the Forum terms of use.
Scrum and traditional Project Managers
Last Post 03 Jan 2014 11:56 AM by michael. 35 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Page 2 of 2 << < 12
Author Messages
Michael
New Member
New Member
Posts:15
Michael

--
10 Sep 2013 09:32 AM
Hello guys,
It's been a long time since I posted for the last time.
Unfortunately things are not changing for better, but for worst.
I have discovered that it's not only one developer that is hiding knowledge, but almost 4 (the elder ones, from a total of 9).
From the other side, they are trying to "show" the CEO/Director of the company that if we have problems, it's because of Scrum and "obviously" because it's my fault as well.
I had some meetings with the CEO because he wanted to know what's going on. So since then I was inviting him to the different Scrum meetings, specially the Sprint Planning meeting, Scrum Review meeting and the Retrospective meeting. Finally he accepted to participate and finally he had the chance to see how Devs and PMOs are behaving. I really ("really") hope that anything changes for good this time, otherwise definitely I could not implement Scrum in the organization and it could be a real failure.
Ian Mitchell
Advanced Member
Advanced Member
Posts:570
Ian Mitchell

--
10 Sep 2013 10:02 AM
In my experience the first step in any agile transformation is transparency.When dealing with the CEO and others, make it clear that Scrum will firstly *expose* problems rather than create them. For example:

- information radiators (such as scrum boards) that may not be updated properly by the team
- visible Scrum events, where clear Scrum guidance may be being ignored
- missed opportunities to inspect and adapt (e.g. unclear outcomes of standups, retrospectives)
- metrics, which may be too shoddy to be usable
- dependencies and blockages

Even if you never accomplish anything else, or fix any of the exposed problems, getting this transparency is a major win. Use agile transparency as a window on organizational problems. When resistance to the agile transformation is encountered, ask "what else are you going to do to solve this"?

Transparency is in some ways the first and last resort of the Scrum Master. It's the first thing you try to build and it's the last thing you fall back on should things go pear-shaped.
Michael
New Member
New Member
Posts:15
Michael

--
10 Sep 2013 02:36 PM
Hi Ian,

Thank you for replying.
In fact, that was exactly what I told the CEO during the meeting, that Scrum is not creating the problems, but it is exposing them and "we" need to solve them as soon as we can.
I am not really sure on how to solve the problem related with "hiding knowledge". In fact, these developers are hiding knowledge, but the others are not doing anything to get the knowledge either, so I have no help from them.
Also I would like to know if anyone of you had to manage a situation when someone from the team ask other member of the team if it's possible for him to do some task and his direct answer is "I am not willing to do this or that, so I won't do it"?. Obviously there were frictions between them.
I tried to help them solving the problem talking face to face with the guy that rejected to do the task, but he just gave me the same answer and also told me that no one can push him to do something that he doesn't want to do. Any advice?
Iman
New Member
New Member
Posts:10
Iman

--
13 Sep 2013 09:16 PM
Michael,

I learn a lot from your experience. I, too, have faced impediments implementing scrum on my team. But I believe it's not as big as yours.

Your problem is similar to me when I faced it few years ago. Back then, we are yet to implement scrum formally. But we did have daily scrum, scrum review, and scrum retrospective.

At that time, I was the business analyst. But I'll try to advise you based on my experience.

I think it's time to point out to the boss if they really don't want to work. it's not the scrum problem. but it's the person who doesn't want to work!

My advise, you let the person's boss know. and suggest this person to be taken (kicked) out from the team because he/she doesn't want to work. If telling the person's boss doesn't work, tell the boss's boss (I really did this in my experience).

At that time, I was frustrated, but yet, I still want the project finished and I know something needs to be changed drastically. So I didn't really care what is my position.

What I did works on me 2 times on 2 different project.

But I'm not saying my suggestion is the best. And it's difficult and painful to get someone taken out from our team. But we got no other choice, since I don't want that person affecting other team member's morale. At least, the project moved on and finished.

I hope it works for you.

Cheers.
Michael
New Member
New Member
Posts:15
Michael

--
23 Sep 2013 12:35 AM
Hi Iman,

I am so glad to know that my (good and bad) experiences are helping others and also to see there is someone supporting me as well.
During this period I could manage to have a little more support from some of the most difficult developers and also from one of the most difficult PM in the PMOs team. He is "finally" creating User Stories (never did in the last months) and he is asking me for more help for doing it.
Now I have one more challenge, and I think is one of the hardest ones. I am dealkng with the PMO general manager, and he is one of the most difficult man I ever had to deal with. He is a kind of bulling and he is behaving like a silverback gorilla. He is happy yelling to the people, and he is most likely a dictator than a manager, he is the first one that want to break the rules and is the first one that receives you with a smile in hist face but as soon as you turn, he stabs you (and anyone else) in the back. He is one of the most difficult person I ever met.
Now the thing is I cannot behave the same way he does, but also I have to stop him in some way, but many times I run out of ideas on how to deal with him, as he is very unstable.
Here I am asking for your help again. Any advice could be really useful for me.
Thank you all of your for "hearing" and for your support.
Paul VII
New Member
New Member
Posts:7
Paul VII

--
30 Sep 2013 03:09 PM
The issue mentioned in your example all goes back to the values of a Scrum Master and why the Scrum values will end up helping the business anyway. If you can explain what's in it for the business then they often start to listen. This post may help: http://www.pashunconsulting.co.uk/s..._blog.html
adascalu
New Member
New Member
Posts:6
adascalu

--
10 Oct 2013 05:23 AM
Hi Michael,

After following the discussion I am starting to wonder whether we are working in the same company :). Probably not, but I am also facing a considerable subset of the same problems you are describing and facing the same issues (although on some I would disagree they are issues).

Basically where I work they have also decided to move to Agile with several teams (each with its own independent product). Some decided to do Scrum, others decided to do Kanban and a few went with a mix (Scrumban?). My team is among those who decided to do Scrum. Decided is an overstatement as the only action taken in this direction was to hire a few experienced Scrum Masters and let them handle any transformation necessary, but without any formal authority. Obviously we ran in the same walls: PM's suddently became PO's in name only, even those familiar with Scrum chose deliberately to overstep their boundaries, the team has had not even an informal training (too busy) so everyone read the manifesto and the guide mixed with previous experience resulted into some strange interpretations of Scrum (even though the Guide is pretty clear on what is and what is not Scrum). Bottom line, it's a mess.

On one hand, the team would like the benefits of Scrum but they fear the PM/PO and are actively choosing to obey him blindly and place all decisions in his hands. For them it goes like this:
- the sprint is a commitment set in stone that shouldn't change and the team must do everything it set out to do regardless of what happens during the sprint (they choose to do overtime to make up for interference). Although there is frustration, they actively reject any change that would draw a line against the PM/PO
- they tend to overcommit on the slightest pressure from the PM/PO
- they are frustrated that sometimes the PM/PO contacts them directly => I don't see this as an issue, as a SM I am not a middle-man, technical clarifications are between the DT and the PO. I do try to step in sometimes and remind them that any change to the sprint should be first considered and them approved by the team, however they approve everything the PM asks.

For the PO, it's a little different. He knows the basic outlines from the Guide.
- he is frustrated that the team overcommits but at the same time he actively micromanages the sprint
- he pressures the team to plan the entire sprint at the planning meeting (although the Guide clearly states that work should be broken down for a few days ahead) and then asks them to make an absolute commit on their plan
- often he pushes interlinked stories (for example: create a piece of functionality while having a story to deliver it in production in the same sprint) instead of waiting to group packs of functionalities (what we call 'increment') done in at least a couple of sprints in the same release. => put this together with the absolute commitment, any change throws everything haywire.

In my opinion (and what I am trying to do now), the main issue is with the DT. If the DT decides to draw its perimeter of responsibilities around the Guide, the combined force of the DT and SM can force the PM/PO back. Any productivity cost will be recovered once a rythm is established and the DT learns to use the velocity at planning.

As a SM you can't take the role of a dictator and push the team. The problem for me is that the team doesn't seem to want a change, despite the situation. What makes it worse (IMHO) is that currently there is a kind of frustrating stability where mandatory sprint deliveries overshoot the commitment with a kind of precision that is simply accepted by everyone. Therefore everyone keeps their frustrations (team has the micromanagement and commitment, the PO has the clients on his back with missed deadlines on their part). Obviously, the concept of "maximizing the work done by the DT" can't be found in anyone's vocabulary.
Michael
New Member
New Member
Posts:15
Michael

--
11 Oct 2013 04:51 AM
Hi Adascalu,
I am afraid that we are not workng in the same company, but I also think our problems are almost the same.
I think the main problems here is that the Company is "saying" they want the change but is not "embracing" it for real, a kind of "yes I want it, but not really want it" (you know what I mean?) This way the company just put all the responsibility over the SM's shoulders, so if everything works, the Company will say they made the right decission, but if itdoesn't it will be the SM ans Scrum fault (a very comfortable situation for the Company, isn't it?).
As I said in other posts I have 5+ years as a SM and have implemented it correctly in other comanies, but this is the worst company of them all.

You mentioned that your company hired a bunch of experienced SMs, are you one of them? What the othe SMs say? Do you do Scrum of Scrums? What people say during the restrospectives? Are you the only one that is raising the problems during the retrospective (I do, and I became the "bad guy" in the office, many people hate me (literally...),but also respect me(even if Ithink it's not the best way to be respected...

I rally hope you can shar the answers to my questions soon. Keep strong (I am trying to keep stron as well, even if many times it's no easy...)
Michael
New Member
New Member
Posts:15
Michael

--
03 Jan 2014 06:18 AM
It is sad, but it is not working...

Yes, this is the end, PMO definitely gave up and decided to keep working the same way they always did, as Project Managers, agreeing absurd delivery dates and pushing the development team to work long hours to delivery in those dates.

The recurring answer to any question that comes from the Development team is “We already agreed the delivery dates with the customer so if we don´t make it, we are going to lose the customer!” (Shock doctrine?).

What´s worst, top management agreed on this and they are supporting the PMOs even if they told me they have seen changes, but not enough changes… I agree with them, but it´s not because of Scrum, it´s because Project Managers kept being Project Manager, and never demonstrated any willing to change. POs are a very important part of a Scrum Team and expecting a commitment only from the developers is not good at all, as it seems the rules are different for both teams and this is creating a very combative environment (Devs vs PMs) and the projects are not moving forward at all.

They are asking me to do Scrum in a more waterfall way (what?).

Therefore, I am giving up and I will stop wasting my time.

This is the end of a true story.

Thank you all guys for your support.
Ian Mitchell
Advanced Member
Advanced Member
Posts:570
Ian Mitchell

--
03 Jan 2014 06:38 AM
> This is the end of a true story.

If it's any consolation, it's a common story. The dysfunctions you have witnessed, and your attempts to resolve them, will serve you in good stead in coming projects. You have probably learned ten times more than you would have done if stakeholders had been sensible and given Scrum a proper chance. Ironically, this is a foundry in which the best Scrum Masters are often forged. Good luck.
michael
New Member
New Member
Posts:29
michael

--
03 Jan 2014 11:56 AM
sounds difficult, if we think back a bit we know PMs have existed a long time and lets not forget different applications of the PM format PMI, PRINCE2, PMBOK, PROPS, so we have a variety of ways to do it.
The one thing that isn't practiced in any of these is change behaviors as they focus on the method rather than the bottom up intelligence, its top to bottom and sometimes with no intelligence as the methods are not adhered to.
Simply just use this as an inspect and adapt opportunity, don't kick yourself and don't be downhearted about it.

Large organizations and generally organizations with a lot of legacy behind them really find it difficult to change.
Why? " because we have always done that" and that's the way forward in their eyes.
Normally change happens in organizations like that when jobs are on the line when the traditional methods have failed, or you get someone that really does support the change that ensures it happens (or both) ie an ambassador not an assassin for something.

Here for example the organization could have done away with the role of PM and made them all PO or simply put one team as SCRUM vs a team of carrot and the stick.
They didn't which makes you wonder how committed they were or just lip service to some current buzzword?
Could be that in time when its getting difficult they get a chance to inspect and adapt with transparency if it all goes wrong, the nice thing is you will be the guy that introduced them to the ways of scrum so in many ways will be responsible for their success if they do adapt to it, hows that for a bad ending. :-)
You are not authorized to post a reply.
Page 2 of 2 << < 12


Feedback