Thanks Nuno, now I understand precisely what you mean by designer vs. software engineers. And absolutely it has to be collaborative. Both are members of the project team, and if an issue is important, any team member has the right to stand on the tracks. On a functioning team, dissent is welcomed and should be rewarded, in fact. It's up to the whole team to become better at what they do over time.
It sounds to me like you're a designer, and frustrated at being ignored by Software Engineers. Maybe you just don't have a multi-function development team, and there are department walls in the way. I had cases like that at IBM and I had to bang a few heads. Because I was reporting purely on the project, directly to "God", I didn't worry about the politics.
But if you're a member of the team,you are responsible for being heard. and be collaborative in reaching consensus. In the scenario I described at IBM, a risk to market performance was as big an issue as cost or schedule, probably bigger, in fact. It is up to the whole team to deliver a quality product within the constraints given. The Software Engineers actually build the thing of course, so they have ultimate the power to do it any way they want, but they do not have the authority. The team will be judged after the fact by the product's success. Ultimately that will determine who does and does not get team leadership positions down the road.
So in my situation at IBM, the team's monthly report could include a concern from the designer that the product would not reach its business goals with the UI imagined by the Engineers. That report goes directly to the big boss at the top of the food chain, so you better have some evidence of your claim. The real issue is that the team does not have consensus, and needs to evaluate the impact of each alternative. So before you go blowing the whistle, you raise a project issue that you need to evaluate the UI before implementing it. Usability tests, focus groups, field trial or whatever makes sense. If the group is functioning properly, they recommend to the big boss that the project be changed to incorporate the tests. The recommendation comes with the additional funding, headcount, and time required. to do the tests. Now you're running it like a business. Now the big boss can make a simple decision. Can he afford this or not? Does he think it's worth it or not? If yes, everyone is happy, and you go with whatever results you get from the user tests. And the project expectations have officially agreed and changed.
In this case the boss will say yes 99% of the time, and congratulate the team for its professionalism. But sometimes he'll say no. It's his business after all, and there may be factors you know nothing about. But if he says no, you've been heard, and the risk is now on him. If it actually flops for the reason the team had predicted, the boss is on the hook, in writing. Both the team and the boss will make better decisions on the next project.
So I guess that the answer to your original question is that there is only one project team, it has all of the necessary skills represented, and it must achieve consensus. "Because I know better" is not an acceptable response from anyone. The choices are simple, go one way, go the other way, or get more information. In our example above, it would be pretty hard for the Engineers to refuse to even ask permission to find out. In that case, I might write the report that the project is at risk because the team is not in consensus. What I would say would not be as polite as what I wrote on the record, even though I am an Engineer.
I always write too much, but I hope that makes sense.
I once turned an IBM software development lab on its head by simply streamlining the objectives-setting process. Ultimately, we were all responsible to the Country VP, a pretty significant guy in IBM. His motivation was simple: the company gave him substantial resources: 2,000 software developers in our case, and expected product sales sufficient to support all of us, the sales and support channel, corporate overhead and the shareholders, Not complicated. Each product group defined product goals but they usually didn't understand. So I found a simple way of quantifying the goals in terms of headcount spent, delivery date, and time sensitivity. There was zero misunderstanding of the goal, "down to the floor sweeper", if you'll pardon the phrase. There were also zero surprises when our team presented monthly to the VP. Each project was either on track, at risk of going off the rails without clearly specified corrective action ("the ask"), or broken. The guy with the authority allocated continued resources and rewards to the "on-track" teams, decided whether to fund the corrective action, accept a different outcome, or stop investing in the "at risk" projects, and whether to terminate "broken" projects or ask for a new proposal. It took less than 5 minutes per project each month, and every project had its day in court if necessary.
OK. Management is about investment and return, nothing else. Our objectives-setting allowed us to interpret the big bosses motivation into project parameters that everyone understood and agreed. You will notice that the design objectives and methods were nowhere in the equation. That's because they belonged to the development team. Developers never seemed to believe that the big guy didn't care a damn how they did it, or even what they built, so long as it made sense to the technical experts (who were a part of the development team) and ultimately to customers, as reflected in sales. That's right a year or two after the fact you learned if you were right or wrong, and whether you needed to adjust your expectations. That was essential feedback to the development team, who still decided what needed to be built and adjusted for real world changes as they went. The big guy didn't load his shotgun if the product flopped, he recognized that his management team needed to better at educating the developers about reasonable market expectations.
It worked brilliantly. I got to do it because the existing over-managed development process consistently failed to deliver products that were industry-leaders or market winners and weren't paying rent. When we simplified the decision-making and left project as well as technical decisions to the developers, and gave them responsibility for their work, the whole situation turned around almost over night.
Like the others I don't entirely understand your distinction between developers and designers, but it doesn't matter. The answer to your question is simple, whoever is responsible for the result (developers?) decides, taking input from anyone appropriate (designers?).
Development 101, hire great people, trust them to do the right thing, then keep training them to do it ever better. Oh yeah, our VP started sleeping nights. recovered from his ulcers, stopped scouring the halls to find someone to chew out, and adopted MBWA to listen what these really smart guys had to say.
Good Reply. Could you please explain who is involved as "Management" and their role in the development process. From a traditional point of view, Managers exist to authorize resources and approve/deny project changes, as well as administrative functions like salaries, promotions, professional development, budgets, infrastructure, and so on, so if they are involved in product development everyday, Agile must mean something different. How does that work?