Dev Manager is acting as Product Owner

The Development Team should inform the PO.
The Dev Team can just say "we are ok for doing your stuff next Sprint, if our PO is also OK"
The PO is responsible for the Product Backlog, not any other "managers"

The PO reports to the dev mgr too. Now what?

If your PO have no authority on the Backlog, then, he/she is just not the PO.
If the Dev Manager want to decide the order and value of the Product Backlog Item, then give him the PO role.
Maybe the current PO, helped by your Scrum Master, should explain the role of PO in Scrum.

If your managers actually don't want you to work using the Scrum framework, you can try to have the managers squeezed between the Scrum Team and the client/customer how should be very happy of Scrum because of the transparency on the product you offer.

The current PO is completely submissive to the dev mgr, both organizationally and culturally. Since this is currently an internal project, there is no "customer" of which to speak.

I really only see two options here: 1) quietly inform the Scrum Master of the dev mgr's subversion of Scrum, or 2) quietly inform the dev mgr's boss (VP) of the same.

Neither (1) or (2) will end well for me. So, I either need to suck it up becuase I clearly have no opportunity to improve this organization's process, or find another job. Is there an option (3) I have not considered?

I'm very sad for you. You are trying to perform the job of your Scrum master plus your own developer job.
It is very difficult to change an organization mindset, especially without sponsorship.

Be confident you do your best.
You have already improve a lot your understanding of Scrum, but the people around you are far away behind.
Be patient, the improvement will take a lot time to implant.
Of course I don't know the people around you, but I'll give option 1 - (inform the SM) a try.
Option 2 is in the hand of the SM.

Option 3 can be asking & planning for training for the whole team ; attending seminars ; coaching from outside experts

Either option 1 or 2 will probably result in retribution for me being the Scrum "whistleblower".

I have inquired about training, and was told I need to plead my case, as there is no formal training budget. The new VP who came on board informally trained the organization on Scrum. He clearly did a poor job.

You are not "whistleblower", you are raising impediments.
Again, I don't know the people around you, it difficult for you to be honest and transparent if their is a strong lack of confidence and respect around you.

You can try not to ask training or coaching for you, but for the whole team.

I understand what you're saying, but the impediment is my boss himself. He doesn't follow the process. I can't fix that without consequences to myself, can I?

If I ask for training for the whole team, it will be denied because the VP already trained the team himself, albeit ineffectively. He'd never approve outside training, as it would be an offense to his ego.

Perhaps I'm jumping to too many conclusions here, but I've been doing this for 20 years, and I know human nature.

Ask for a few days of in-site coaching, not for a outside 2 day-training.
The message to your VP could be "we understood your great training but actually we have a hard time trying to make it work"

Just try an experiment, ask everyone on the team to register on scrum.org.
This can form part of an experiment.
Get everyone together and have a room with LAN access.
Ask everyone to sit the open exam (including the VP), this is based on real deal Scrum.
The results from the experiment will show as a percentage on how scrum is understood.
Same conditions as everyone, one shot to do the best you can in the time you can.

Passing the Scrum Open assessment is an indication that you are aware of some of the basics of Scrum.
The VP cant argue with the results from this experiment.
Its also a bit of fun to get people thinking about scrum as well, 30 minutes well invested.
This will give you the data that's the important part.
What people think and what people know are two separate things.
Here were testing the what they know based on what they think from what they have been taught.

If your prediction is right the data will show that people need to be educated "correctly".
To say Ken and Jeff know nothing if the result goes how you think it will, will just show it even more.

Michael

There are no agile whistleblowers, only team members who promote transparency.

Expose the impediments (focusing on the problem rather than the person) using information radiators and then try to cultivate retrospective analysis. I don't recommend promoting solutions at this stage...just exposing the problems. Who prioritized what, and when and why? What were the consequences? All team members should be pro-active about bringing these matters to general attention.

Transparency is the first step in an agile transformation. If this is objectionable to an organization, then it is reasonable to consider if it would be more productive to invest your time and effort elsewhere.

Since my desire for transparency is solely directed at one person (my dev mgr), then I fear the consequences. The daily stand up is not a "safe place" in which to raise this impediment.

Posted By Olivier Ledru on 16 Aug 2014 05:38 AM
The Development Team should inform the PO.
The Dev Team can just say "we are ok for doing your stuff next Sprint, if our PO is also OK"
The PO is responsible for the Product Backlog, not any other "managers"

I disagree that the Product Owner should be involved in this, at least at this point. Respectfully, I also disagree that the Development Team should be tasked with (a) confronting the Development Manager, and (b) making *any* promises - no matter how thin - regarding the next Sprint. The former puts the Development Team in an awkward position with their functional manager, which may increase anxiety, further distract them from their work, etc. The latter could easily be construed by the Development Manager as a future commitment, even if the Development Team qualifies their response with "if our PO is also OK."

In my opinion, this falls squarely on the shoulders of the Scrum Master; this is precisely the type of situation for which the Scrum Master is prescribed:

1) Remove impediments
2) Improve the organization's understanding of Scrum

As Scrum Master, I would have a discussion with the Development Manager and explain how his/her actions are counterproductive to the entire Scrum process, not just to the Development Team. The best way to do this is to quantify the impact of his/her actions on the Development Team, and explain why Scrum forbids this type of interaction. For instance, introducing items into the Sprint Backlog through backdoor interactions severely impacts transparency.

If there is resistance on the part of the Development Manager, the Scrum Master then needs to examine why. Is there an issue with the organization's commitment to Scrum, or just the manager's commitment to Scrum?

Thank you Jason. I think your analysis is spot on.

Since I raised my initial concerns in this thread, the Dev Mgr seemed to sense my frustration, and we spoke privately. I raised many of the points discussed in this thread regarding our roles, Scrum, etc. He was very receptive, and clearly wants to not only learn, but be a part of the solution.

He asked what we could be doing differently or better, and I explained that we're not fullying embracing Scrum (i.e. blurry roles, no Sprint retrospective, priorities outside the commited sprint PBIs, etc.)

The Scrum master was unaware, and I mentioned to her that we should at minimum be two sprints ahead in our grooming (we're grooming just-in-time, which is stressful and inaccurate), and that we are not learning any lessons that a Sprint Retrospective is prescribed to help with.

I still think the Scrum Master is the weak link in the whole situation. From where I sit, she's a daily stand-up facilitator and no more. I hope she's more, but I haven't seen it.

I'm glad to hear the Development Manager was receptive and open to suggestions; I'd take that as a clear indication of his commitment to the framework. Nice work!

As for your Scrum Master, it sounds like there's an opportunity to lead by example, especially now that the Development Manager has overtly expressed a desire to more fully embrace Scrum. At the end of your current Sprint, you might consider suggesting to her that the team participate in the requisite Retrospective, and express your desire to hear her feedback on the team's performance.

Since you aren't participating in Retrospectives right now, may I ask what 'done' means to the team today? What did it mean when you first began participating in Sprints? This is something that should evolve over time; has it?

I can see that the SM is receptive too. In our daily SU yesterday, I suggested the Sprint Retro, and she scribbled in her book, agreeing that we have been avoiding it and need it.

"Done" has been quite nebulous. We've generally had a theme for each sprint, and features to be implemented that fit within that theme. Done has meant that there are zero defects for those features by Sprint Demo day (the Monday after the Friday when the sprint ends).

I also have a feeling that my team is the furthest along (relative to the rest of the org) in our practicing of Scrum. This isn't saying much though.

Hey, congratulations to your achievements - it sounds like several steps into the right direction (from my perspective)!

And I wanted to thank you for this thread. As our organization is just changing into something agile-like, this helped me a lot in understanding and foreseeing some future problems. So: thank you!

Posted By AnotherDotCom on 25 Aug 2014 11:11 AM
Hey, congratulations to your achievements - it sounds like several steps into the right direction (from my perspective)!

And I wanted to thank you for this thread. As our organization is just changing into something agile-like, this helped me a lot in understanding and foreseeing some future problems. So: thank you!

You're very welcome. This community does a great job at providing shared learning.

As a footnote to my story, my team has a Sprint Retrospective this week that will hopefully allow us to shine a spotlight on areas for improvement.

I'm looking forward to read your feed-back of your Retrospective !