6

I've been transferred to another department at our company lately.

The team was going well but I notice they have some issues regarding with our Software Architect. On our team we are separated into two divisions which currently we are doing most of the front end development and on the other division which are concentrated on doing the back end API's (Back End Development). The two divisions meet only once or twice a week via meeting calls. Both divisions are separated geographically on two different countries. That's why we collaborate through calls and emails.

We keep on getting the feedback results with the back end team on what have they completed on the past 2 months. The Software Architect on the back end team said to us that the back end was going well and they keep on repeating the same answer as we want their outputs that they haven't given it yet for the past month.

Lately on our Division (Front End Development). We had a meeting with the back end team as well as for the project manager and business managers. My Team (Front End) raised our concern regarding what are the deadlines and project deliverables of our web project and as well as for the outputs of the back end team. We were really shocked that they have developed only two API for the past 2 months that is unrelated to what is agreed on the first place. Without any databases at all. Its very unimaginable.

One of the project manager (from a different department) asked several questions with the software architect.

Project Manager: What programming language did your team use on the back end API's? (Java, PHP, etc).

Software Architect: Is that even important? Let me get to the team

Software Architect: I have a quick question, what is Agile Scrum and why are we using it?

Software Architect: Also we need the API source code from the (project manager's) department so that we can reuse the code from our end

We were really in such surprise that he even didn't know what Agile Scrum is.

As a member of the team, what can I do to make things go well with both teams?

(Updated: We have talked it already with the business management and they seem to take the Software Architects side over our concerns)

Improve this question
4
  • Why is he asking for API code if their team is the one doing the API work? Might help to clarify departments with a variable or something to keep things straight in the question.
    – mutt
    Commented Apr 27, 2017 at 4:31
  • I have modified the subject to tone it down so it doesn't come across so subjective and inflammatory, and some minor edits.
    – Jane S
    Commented Apr 27, 2017 at 5:50
  • The last question of the architect : is it him as the backend developer that is asking for what API has develop the front end ? Front end don't produces API, they produces UI and they don't need it to valide their backend. Seems like a trap to me.
    – Walfrat
    Commented Apr 27, 2017 at 12:01
  • FWIW, the architect's first statement is accurate as it applies to the interface between front-end and back-end. The consumer of the doesn't need to know the language behind the interface. If the PM has concerns regarding performance that would be different, but not as an interface
    – cdkMoose
    Commented Apr 27, 2017 at 17:10

4 Answers 4

Reset to default
14

This is a bigger problem than just the Architect. You also have an ineffective PM.

We keep on getting the feedback results with the back end team on what have they completed on the past 2 months. The Software Architect on the back end team said to us that the back end was going well [but] they haven't given it yet for the past month.

The PM should managing the interactions between the teams, but he is seriously asleep at the wheel if he's accepting that work has been done from the remote team without any evidence of it. Likewise, if he doesn't believe that the work is done but is not taking action. Whether the architect understands Scrum or not is not the most relevant point - he and his team are making promises, failing on them, and they're not being held to account. Presumably the failure will all come out at some long distant future point when nothing works as planned, but by that time it will be far too late to rectify the situation.

Improve this answer
1
  • Note that if the PM was competent, he would be the center of the Scrum method, and thus there is no way that they don't know what is Scrum/Agile, at least very roughly.
    – Walfrat
    Commented Apr 27, 2017 at 11:59
6

You need management to take action. If the architect doesn't even have a clue how to do his own job there will be a huge impact, unless there is someone else to do his job plus their own, which will have a long term impact. Management needs to find out about that guy and how he got hired to start with, maybe he is skilled elsewhere and misplaced, but that is really, really bad responses for an architect.

An architect should have solid dev experience as well as program designing through the full life cycle and usually with multiple languages unless specialized in certain technologies. The agile part doesn't concern me as much, even though he should be at least familiar even if he hasn't worked it before, but the responses on code languages and demanding code to copy is shocking, along with the output of the other team seeming poor from what you are saying. Some API's are very complex and take time, but if it's a simple API and there are supposed to be numerous and they aren't making good time then management needs to motivate them to perform or do some personnel adjustments to make things happen.

Escalate your concerns to management immediately and get them to either take action or expect delays due to the other team.

Improve this answer
3
  • This is an "All hands on deck" emergency. Your management needs to send in an audit team to the backend devs IMMEDIATELY. Something tells me you're going to have a lot of disappointment very soon.
    – Wesley Long
    Commented Apr 27, 2017 at 4:55
  • The problem is that the "management" is siding with the back end team. They trust them more than the front end team
    – Jon
    Commented Apr 27, 2017 at 5:11
  • @Jon If management is siding with the back end team, then you have to focus on the impact on you/your teams work instead of the lack of production from the other team. If they perform really badly, it should show up over time and cause change, but be sure that your work and your teams work is fully on track and any slips caused by the other team are fully documented to show the exact cause for each delay in detail.
    – mutt
    Commented Apr 27, 2017 at 11:04
3

Clearly, there is a management and potentially miscommunication issues. Management issue is covered by other answers. I'd like to add some of the technical suggestions that you can voice when discussing the issue with your management:

  • Have one Scrum backlog that both teams use for development
  • Align Sprints for both teams, combine Sprint review meeting (demo) for both teams
  • Agree on the API prototypes. Write small quick integration tests that return mocked data. UI team can work with the prototype and API team knows the format of the real data that they need to return
  • Run integration tests on your CI server
  • When backend API is implemented, write more integration tests using real data
  • Consider using chat applications to speed up and improve communication between teams (e.g. slack or similar)
  • Create an API plan. Segregate similar functionality into partitions. Track number of the implemented API and what's left. Implement most important API first and aim to release fully working UI and API each sprint
Improve this answer
1

As a member of the team, what can I do to make things go well with both teams?

Simple answer: The architect needs to go. This person should already know the answer to the questions you mentioned in the post.

The not so simple how:

Dealing with a bad software architect is very difficult. If you company has decided that it needs one ( first ) and then actually hires one, he has a certain elevated status. I used to work with one who I called an expert google'er, he could not code or implement simple concept examples.

The way our team dealt with them was to consistently challenge him technically, and ask for him to provide mock-ups of concepts ( more that what you can just google ) he wanted the team to implement. In the end, after consistently doing this, management started to see that although the person had a fancy title, they could not actually do much to add value to the team and they were let go.

It took awhile, and was painful. I don't envy your position.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .