Preface

I am a contracted developer on a young project (less than a year old). Agile is relatively new to this team, and I have been giving a lot of feedback to help improve on the Agile workflow between my dev tasks. One of the more important pieces of feedback was the following:

• Define story requirements at the start of the sprint


• Refrain from changing requirements mid-sprint on a "hey we don't like this, fix it" basis

I have been pretty aggressive in pushing some of the changes forward and it has been paying off big time for productivity and organization of resources and documentation.

I have read through a related question that outlines most of the feedback I was hoping for in this situation, but there are more details and I was hoping you guys could put your two cents in.

My situation

Similarly to the related question, I am currently dealing with an analyst that likes to change requirements mid-sprint. She is not a very technical person, so her technical requirements are from the business perspective, which leaves a lot of room for miscommunication, especially when documentation for the requirements is very poorly organized. She is also the proxy PO, which makes this entire situation tricky.

This is following multiple sprint retrospectives where an action item following the meeting was to define and document the sprint requirements at the start to make sure everyone was on the same page. This would require the analysts to put together the changes they wanted to see as technical requirements for stories, then let any non-defective oddities be written in the backlog for consideration in the next sprint.

Now, I am aware that requirements are not immutable. However, it is becoming a habit for this analyst to make changes to requirements. 2 days left in the sprint and she outlined several changes to the requirements. She also decided to circumvent changing stories by writing them as bugs, assuming the code is "broken" and needs to be "fixed" since it does not follow the new requirement she defined in the same minute.

Something that's extremely annoying is that she shows 0 trust in me as the main developer of the team. On one occasion, I informed her of a requirement from my tech lead that was contradictory to the way she wanted data to be mapped. She added my dev advisor to the conversation and opened to him with "[he] seems to be confused, can you help him?" On another occasion, during a meeting she brought up a "bug" that was covered by a story she wrote in the backlog that I hadn't started working on (because it's in the backlog), and when I pointed that out, she did not hesitate to shut me down and confirm that she was going to write up a bug for it anyways.

I am at least partially convinced that a main reason why she treats me like this is because I am a contractor. However, that is only an assumption, and I have no idea how she treats the other developers since she doesn't address many of them directly in meetings, so take that point entirely with a grain of salt.

She does, however, have no respect for developer time since she has regularly dragged business-related discussions in technical meetings way past the scheduled end time, along with interrupting anyone who says otherwise. The former was also a retrospective action item that she has ignored for a couple sprints.

I have a few questions regarding all this:

1. How do I stop a meeting from being derailed by the aforementioned behavior if the moderator is absent, inactive, or complicit in the derailing? Or, more broadly, how do I exercise my Meeting Rights in the face of someone who threatens one or more of them?


2. How do I professionally convince this analyst that I know what I'm talking about from a technical perspective?


3. Most importantly, how do I professionally convince this analyst to apply the feedback from the past couple retrospectives?

Any feedback on any of these points is welcome. Be as critical as you can be, tell me I'm being stupid if it's appropriate, and let me know if there's anything else I can clarify here.