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.

Answering your first question:
You don't. At least not without backup from that person's supervisor. As long as she is in charge of all ceremonies and is the PO, what she says, goes, as it's on her if it fails. You could try to bring your concerns up to her manager in writing.

Answering your second question:
There is a concept called "protected sprint" in the Agile methodology that basically tells you, once you start your sprint, you shouldn't change your targets (be they defects or stories). If you do so, just like your BA is doing, you are working with moving goal posts. It's very unlikely anything worthwhile will get done in this manner and that's why you have protected sprints.

There are a lot of ways a protecting a sprint and still allowing for inherent changes to the sprint goal that this person could apply instead of just changing the user stories acceptance criteria mid-sprint, but to apply them she would actually need to be competent with the Agile methodology, which she clearly is not.

Ask her to take a few courses on Agile from certified instructors. Give examples from previous employers that had similar problems and how they got solved. I've met this situation multiple times in my career and tried all the above advice. If the person is not willing to learn, listen and apply you are just wasting your breath.

Answering your third question: It's not her job to appraise your performance as a dev, just as it isn't yours to appraise hers as a BA. If she oversteps her bounds in relation to you, tell her to her face, ask her to stop. If she does it again, raise it to her boss. If nothing changes within a reasonable time, up your contract rates to make up for the hostile attitude or leave and tell everyone you meet what a crappy employer Company X is.

Nothing long-lasting can be built on distrust. And if what you are saying is correct, it is my opinion that she deeply distrusts you either as a human or as a professional. In my career I had to deal with this kind of harassment at the workplace several times. Some people just don't mesh together, some people just don't want to see you as a peer regardless of how good you are. Some can be convinced with hard facts or lots of work, but it's usually counter-productive to put the effort in convincing your co-worker you are apt at your job instead of actually doing your job. What I found working is to just mind your business and do your job to the best of your abilities. Eventually they will figure out they are wrong to distrust your abilities/person. Some might even admit it.

Bottom line, you can't convince someone who distrusts you to do something for you (or for themselves and their project) until you fix the trust issue.