It’s not in our scope…. It’s the other team!
Posted on November 4, 2015
I recently participated in a meeting with a development team responsible for a certain part of a solution. The team was responsible for implementing an integration solution between two systems – one system responsible for our business logic and another system responsible for creating customer print.
As the application architect, I have the responsibility for ensuring the technical quality in the solution, but I also have an unstated responsibility to look for the correctness of the solution. It’s not just how it does it, but also that it does the right thing. I had noticed that the solution the team proposed was able to take data from our core system and transform it to the format consumable by the print system. That was the basic requirement. They fulfilled it! But there was a bunch of issues with the solution. If a print didn’t succeed, there was absolutely no way to communicate the status back to the core system.
We called for the meeting to ask for their perspective on this. The answer was CRAZY!
“If anything goes wrong, we will put the failing print job on a fail queue and then we expect the maintenance team to take care of it”
So not only will you not tell the user that it has been failing, but you actually expect a manual process to be set up to handle fails? And extra work on a maintenance team that is already busy handling weird stuff?
This was clearly not acceptable, so we pushed the team a bit. They ended up saying that it wasn’t part of scope for the team and that if it should be in scope, it should be the scope of the core solution team.
What is wrong here?
First of all, the team was clearly aware that things could go wrong, but the team didn’t go to their product owner to mention that something could be wrong with the way the solution was scoped. It is always the responsibility of a professional team to pose questions before implementing things. There is no value in creating a fantastic solution if it doesn’t solve the business problem or actually make the business worse.
Secondly, the team was blaming the other team. THIS is not a constructive way of dealing with problems. In this case, the team couldn’t solve the problem themselves. They needed an endpoint from the other team to communicate status back. This was clearly a joint venture between the two teams.
Third, this wasn’t a question of blaming. This was basically just a question to the overall functionality of the system. In stead of going into defence mode, the team could quickly say that they were aware of the problem and they were in a dialogue with the product owner to solve it in an upcoming sprint.
How to fix this?
One of the problems here is that the teams are divided into technology specific teams – not functional teams. If a cross functional team had the responsibility for the end-to-end solution, there would have been a much higher chance that the team would have found the problem a lot earlier.
Also having a product owner close by would have helped things a lot. Nobody stated the requirement that status should be communicated back to the core system. But if a P.O. is close by, this kind of requirements can be handled and prioritized fairly quickly.
What could I have done to mitigate this?
The problems described above are real. The teams should be cross functional. The teams should take more responsibility etc… But could I, as an architect, have done anything to make things better?
My role in this project is being a cop! I know, it is not constructive at all (I’ll post about this later) but that is just the way it is. As the role of the cop, I called for the meeting. This means that the team is basically in defence mode before the meeting is starting – because they know that I want to questioning their work which makes them less constructive.
What I probably should have done was to ask both the core and integration team to a meeting along with the product owner – with a much more clear agenda that stated that the purpose of the meeting was to find solutions – not blaming teams. Because I just called for a meeting with the headline “Printing solution challenges” I didn’t help out here!