Why My Project Sucks

This is basically a follow up to the previous blog. So here is why my project sucks…

Firstly we are distributed across two offices with the justification of “the people in the other office need to feel involved”, or that is what one manager explained to me. They could have just assigned them their own important project rather than unnecessarily split the team.  Due to the office split, half the team were managed by the person actually assigned as the Team Manager, and the others were line managed by a manager in the other office who was primarily the Team Manager of a different team.

That manager was in charge of (what I liked to call) Team Duplicate who kept on duplicating our work. It’s approaching a year since our project started and we don’t really have much to show for it. However, what we did do; they wanted to directly duplicate (either directly using our code, or basically copy and paste) to have a slight spin on it.

Half the team aren’t interested in doing Code Reviews. This slows you down when you start coding a feature that relies on some other work, but yet it isn’t committed yet, because it hasn’t been reviewed. It then becomes a bit fiddly to manage code branches and merging code.

Unclear requirements. It seemed one person in the “Product” Team was making them up, rather than looking at contractual requirements or features that users actually desired.

The Product Owner didn’t take ownership of the requirements. This is linked to the above, but also he kept on saying “this is a technical project and I’m not a technical person.” No, Requirements are written as “User Stories” which are from a User’s point of view. It’s up to developers to discuss the technical implementation details. We didn’t have requirements from a user’s point of view, so it was difficult to understand what the end goal was. If the Product Owner actually wrote User Stories that were well-defined, it would highlight what UI designs we need from the UX Designers, and they can pass the work onto the UI Controls team. Additionally, with clearer requirements, it would probably highlight the distinction between my team and Team Duplicate.

The Team Manager added some ideas he wanted people to look at, but they weren’t backed up to a requirement. Again, they were a technical implementation detail, but what were we implementing? In the refinement sessions, we kept on pushing these “User Stories” down the backlog, but the Team Manager was reluctant to remove it outright, because “we may need it. It could come in handy one day.” If the Product Owner took ownership, he would have just binned these so-called requirements.

Due to slow progress due to many of the above reasons, we had a high turnover of staff. Most people that moved, simply switched projects, although I think one person did leave the business. We have a team of 9, and have had 5 replacements over 7 months. One person partially moved teams. He seemed to shift his focus to help another team, but seemed to dabble in both projects. It really felt like he didn’t care about the project anymore.