I've tried to focus on your key questions in your TL;DR part, but have taken the time to go through some other points.
Key TL;DR; Questions
How can I communicate to Eve that things are not how she think they are?
Please note that, based on what you've said, no concrete evidence that things are the way you think they are has been mentioned, either.
Now, I'm not saying that you have no reasonable grounds to think that you could be getting blamed behind your back. What I'm saying is that you don't know for a fact that this is what is actually happening.
It could also be that the several project failures you mentioned have placed that startup environment and its management under intense stress... especially if their thoughts are that they're trying to keep their startup from having to file for bankruptcy or something serious like that, and they end up venting at the first sign of additional frustration, whether real or perceived.
Therefore, keep this distinction in mind as one possibility.
On the other hand, if we assume that you're correct, it doesn't sound like there's much you can do. How many other software developers exist there with the responsibility of bringing the application(s) to life? It sounds like it's only you and Adam who are writing any code at all.
You also said that
Adam and Eve are very close
I don't know what "very close" means in this context (e.g. they hang out frequently, or are a couple, family, etc.), but whatever the case, it sounds like the level of rapport/trust between them is greater than yours is. (You don't say how long you've been there, etc.) I think that can make perceptions about any sort of criticism even worse, regardless of how well-intended it is -especially since you report to Adam, not Eve.
What alternatives do I have to point this out to Adam and/or Eve?
From what you said, it doesn't look like there're many good alternatives. I think I'd prepare my resume and start looking elsewhere. If they're blaming you now, they're also going to blame you when the project fails, even if it was b/c of their own management practices (or lack thereof); it doesn't look like an environment I'd like to stay at.
If you tell Adam that it's his fault, it's not like he's going to say "Yeah, that's a fair point; let me tell Eve how much I agree on that".
It also doesn't sound like you have regular meetings with Eve (e.g. 1-on-1s), which can make things difficult. It could also make things worse if you go directly to Eve, since it could be perceived by Adam as "going over my head to blame me" and by Eve as "going over Adam's head to blame him", regardless of how objective and accurate your descriptions of the situation are.
If Eve trusts Adam more than she trusts you for whatever reason (and it sounds like that might be the case), then going to Eve will simply be an exercise in shooting yourself in the foot.
Also, while your intentions may be good, it's unlikely they'll take your unsolicited management advice well[1]. Just find a different (and hopefully better) place to work and leave the failure of any future projects to be an unambiguous consequence of their own doing; their poor management practices and/or Adam's technical competence (or lack thereof) will be the only things left to blame after you're no longer there.
Other Details
[I] made some suggestions like having a list of requirements for each task, as we currently don't follow that process, and him to review my work when I am "done".
Here's the first big problem I see. In short: How can anyone tell when anything is "done" when no one knows that "done" means? Until the team starts including this "done" criteria as part of the features, user stories, tasks, etc. there's nothing to review.
Do you guys perform a daily standup meeting? If not, you should. (More below.)
Today, we had another feature that had to be redone, it was finished before I went on vacation - but Adam/Even decided to categorize the data on the server when I was out - Adam Did it on the server today - but the application needs to reflect that change. Hence, it failed to categorize data on the applications
Then this is the appropriate moment to state the following facts in no uncertain terms:
- the feature was done before you left, based on the requirement at that time;
- requirements were changed arbitrarily by Adam;
- Adam made these changes during your absence
You can reword it as appropriately as you'd like, but you need to be explicit about what the facts are. If it turns out that you are being blamed behind your back, then this is the moment to use facts in your favor in a way that does not require making a direct accusation. Simply presenting the facts as part of the regular conversation and letting the facts stand for themselves would be my strategy here.
Eve to Adam: Why data are [sic] not categorized?
Adam looks at me and says: I thought it was!
Me: No it is not, the last time we touched this screen from the app side was before I went to the vacation.
I think your response here failed to note the relevant facts I pointed out above. Any reasonable person should conclude that it is unreasonable to be upset at you in this situation. That said, I've also met unreasonable people, so...
Adam always micromanages (and sometimes both Adam and Eve) my work
Have you considered saying that, maybe, just maybe, if they were to let you do your tasks without constantly being told how to do your job, then maybe you could be more empowered to be more productive/successful and, thus, help them be more successful than what they already are, especially after several failed projects?
Note that this should be worded better; I just put it out like that to avoid ambiguity. I'm also assuming that they don't have good reasons to be concerned about your performance when you're left alone.
[they're] always updated of everything I do on hourly-basis.
This is very disruptive, especially for a software developer. Given that software development is about solving problems in your head, constant interruptions are going to disrupt your thinking process.
This is like frequently throwing water at someone who's trying to start a bonfire, and then expect them to be successful at making a bonfire. It's absurd.
You should all agree to perform a single daily stand-up meeting where everyone provides their update, discuss issues and solutions, and then go back to working without unnecessary interruptions. This meeting is usually about 15-20 minutes and some of the topics everyone should consider include:
- What you did the day before (e.g. yesterday I did
A, B, C, etc.)
- Any obstacles you've run into (e.g. I'm stuck on task
D; I'd like to discuss possible solutions after everyone else has given their updates)
- What you expect to do today (e.g. today I expect to finish
D and get started on E)
Each member provides the same information during every meeting, every day. It's a daily stand-up, after all. :)
I agreed with Adam that I come back from vacation and we start building two test devices and integrate rest of the features.
I've never been in a startup environment, but something tells me that things change rapidly in said environment. Therefore, the fact that they did it while you were gone should not be a problem. On the other hand, it should also not be used against you.
Several technical and managerial deficiencies I consider are the source of these problems.
I don't think there's much you can do, other than changing the managers. Consider if any of the following has been discussed:
- things you think you've identified as problems;
- potential ways to workaround/solve those problems;
- why you think a proposed solution is likely to work;
and whether it was done before the projects failed, or at least immediately after the most recent failure, if at all. If nothing has changed after several failures, I see no reason to think anything will.
This is the reason why Agile methodologies incorporate a team retrospective at the end of each sprint (i.e. not project!): to provide an opportunity to reflect on what did and didn't go so well in the sprint and commit to fixing it for the next.
You don't wait until after the project has failed, and you certainly don't wait until after several of them have failed. If there's a refusal, at any level, to learn from past mistakes, then they'll just keep repeating them and failing. The first step to fixing problems is acknowledging their existence.
Also, if nothing improves, projects will keep failing, they'll end bankrupting the company, and you unemployed if you chose to stay there. The only way you can change your managers here is by getting a different job.
Footnotes
[1] I once had a manager M who assigned L as the team lead. To my surprise, M told me during a "performance evaluation", that the tasks I was working on were "not important". My reply to M was, basically, that L was the team lead, that it was his responsibility as the lead to identify/create the stories that he wanted us to work on during our sprints, and that, according to L, the tasks were "very important". Did M act in a reasonable way and say "Thanks for bringing that to my attention; I'll talk to L because it seems we have different ideas about what's important"? No. She just got more upset and did not fix anything...
