Hello architecture people, I have a question that's about how to structure the team to implement a given architecture. Assuming some form of Layer Architecture 101 you typically have two choices about how to structure your team to implement it. 1. Horizontal - assign dedicated teams to each layer, e.g. a team focused on only the UI, a team focused on only the domain model. The teams negotiate 'contracts' about how the whole should fit together. 2. Vertical - create multi-skilled feature teams that are responsible for a vertical slice through the layers to implement a feature.
To get things started I'll post my opinion.
I feel that the Horizontal method has the following problems; a) runs a greater risk of 'over-the-fence' responsibility, i.e. the whole picture becomes distorted with team members too blinkered to the issues in their own sphere b) Customer-Supplier contention - e.g. the UI team is swamped with requests and can't service a biz layer contract, which means that either the biz code can't start or will be implemented and gather dust before it is used. c) The main advantage I can see is that it forces you into considering strict contracts but is strict contracts really a good way if you believe in agile architecture?
Vertical - a) suffers from 'hogging' a team member to work on a specific feature, i.e. they're not available until the feature(s) they're working on are complete, so you have to negotiate the teams structures for features b) harder to outsource (?)
We have had success with both techniques. (Though I always thought of them as the other way around ... vertical being teams per layer and horizontal being across layers ... but I will use your terminology.)
With the horizontal approach, we were able to have a team work on the business objects and fully test them using unit testing techniques. Then the UI team worked with those objects. But often times the UI team found additional properties or methods that they needed, which required change requests to the business layer team. This worked well when we had team members with specific experience. In one case, we had some GREAT UI Web developers and wanted them to focus just on the UI pieces so had the rest of the team on the business layer.
With the vertical approach, the team members were all knowledgeable in both UI development and the business layer, so they were able to work on a full feature. Since the code included the UI, however, there was a tendency to skip some of the unit testing, because the developer could perform the test using the UI. So it took a bit of management to ensure the unit tests were still developed.
Hope this helps.
www.insteptech.com ; msmvps.com/blogs/deborahk
We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
here we are talking about creation of team based on the software architecture that is being created. Please do note that you create any kind of team’s structure, the over all cost of the project should be taken into consideration. The effective creation of a team structure should be cost effective which in turn reduce to cost. Here we are going to talk about resource management which has a reference to cost structure. The selection of resource for various roles for the software project is very important and selection of corrective resources which will be able to meet project and management objective is very important. The proper planning of entire software project infrastructure with a cost effective should be very effective in terms good quality software. Hiring the correct software resources which able to deliver output based on task assigned which will result in combined output in term of good quality software. Any software methodology weather agile or rup if implemented in correct manner which follow strict principles, then focus of project and management objective can be achievable target. There will be problems , people in each of chain of command have a good code of conduct where their actions should be inclined with software and management objectives.
Thanks, that's very interesting. I can certainly see the temptation to use the UI testing as the only test vehicle. With the team-per-layer mechanism did you see any of the issues I mentioned regarding the whole-picture/Customer-Supplier problems?
I've seen mixed results with splitting a team into specialisations.
Where a specialist designer was used in one project to do the xaml in expression blend this worked reasonably smoothly and have a way better result. Developers are never going to be as good as artists in making something look great IMO.
On other projects where there were specialist teams I've seen friction and waste. When the overall result isn't quite right I see the the temptation to point at the other "teams". Then one team are waiting for the other to do such and such or they need some change request. IMO you want everyone working together for agile. You don't want half your resource to say "sorry, I don't do that" when you have more work to do in one layer than another.
The way to see developers sitting round doing nothing is to split responsibilities across teams in different locations and different reporting. Then you really guarantee that UI team and the mid layer team leaders will fall out. If one team is in a third party company/supplier and have no experience of this sort of liaison and little noticeable aptitude then that's a great way to waste time. Although perhaps someone benefits from the consequent posting....
Thanks, very interesting too. I think that highlights my feelings/concerns.
Certainly a single reporting mechanism for physically separate members of team is sensible. I'd certainly like to hear views about incorporating outsourced teams into either of these groupings.
I think outsourcing to a remote team is frequently false economy.
It's very difficult to manage some team that is thousands of miles away, keeps different hours and speaks a different language.
It's way easier to explain to someone who is in your office what you want and to keep an eye on the direction they're headed.
With remote teams you have to watch them like a hawk. Even then the quality can be shockingly bad.
Years back I worked for a global manufacturing company which was German owned. They had standards. Standards for all sorts of things but certainly for measurements. Oddly enough, measurements were to be in metric. I had to interface data provided by another system, whose developer was in another country. This process took about 30 times longer than I expected. Partly because we were essentially equals in the chain of command and I could ask him to do stuff but not tell him. Some of the problems are a lot funnier now as I look back. The stuff manufactured had width and length as attributes. These were captured by his system. Sometimes in metres, sometimes feet and inches, sometimes feet and a decimal representation of feet ( so like 12.25 ) and sometimes inches. All went into the same field. The resultant numbers were clearly ridiculous and many failed validation. It was only after querying this that the guy thought to mention "oh, you need these other two fields to tell what the measurement is in". I had to escalate right up the chain until the right bosses talked to the right bosses and he eventually calculated metres. The interface validation continued to generate errors for a significant portion of data. He explained that they didn't do any programmatic validation. It was up to the user to check their data. ( His app was lotus notes in case you're wondering how it could possibly work.) Anyhow, this guy wasn't in timbuktu living in a mud hut. He was American living in America and working for an American department which had been part of the company but was now outsourced. No validation was the standard approach in his department.
The time I spent working out what was going wrong and explaining to that guy was just ridiculous. I'm pretty sure I could have rewritten that notes system and written the interface in the time it took. This guy was obviously very bad at his job. During this long drawn out process his manager changed. Eventually the second manager grudgiingly agreed that maybe they ought to start putting in validation.
This was an xml interface file which was one table's worth of data. We had a clear and detailed specification. The guy writing the code ignored it. He didn't misunderstand it or find scope to deliberately do so. He didn't read it at all until German management started talking to his directors.
I'd tell you about my experiences with the team in Mumbai but you wouldn't believe it. Suffice to say it was worse.
I do not agree with andy reply. Because in real software development , mainly depends how we deal with people , when two countries are involved , people normally forget the cross cultural difference and please do take to time understand the cross cultural difference and learn and adapt a team within in existing environment and focusing on achievable target
Ok I think we have one vote for not oursourcing ever ;) "Shouty" Phijo, I think it's difficult to disagree with someones experiences, but if outsourcing is viable then how would you slice the teams wrt to the architectural responsibilities?
I should write a book.
How not to develop systems. Using real life experiences to demonstrate what definitely doesn't work and why.
There are situations where introducing friction is actually a plus. So if you had legacy systems which you don't really want to change at all then outsourcing support for these might be a good idea. There is specialist knowledge which is sometimes necessary but you don't really want a team of cobol programmers sitting there doing nothing 90% of the time.
Say you had a multinational business. For whatever reason you want quite different views on the same system in different countries. You could use MVVM, your core team develop the system for use in the main country you operate from. You have a developer in each of the other countries and each maintains the customised views for their country to local tastes.
Any way you look at it, the least risk would be if your two teams work on stuff which is independent of each other. Wherever possible it's best if a team is located close to whoever understands what they're supposed to do.
Thanks Andy, yes I think a book would be good.
So with your specialist localisation teams in place, can you guess where this is going, would you have a team of localisation specialists or a feature team that included those specialists? Even though I prefer the feature team I think a team of localisation experts sounds more viable. Thought provoking, thanks.
Well that's quite a tricky one.
I like the idea of a team of specialists because when specialist A is on holiday I'd have specialist B know a bit about what he's doing so he can place a digit in the dyke.
Specialists which you hire permanently are something of a problem. What do they do if there's no call for their specialisation some proportion of the time.
Which is why outsourcing your cobol systems to someone who has a team of 10 cobol specialists can make sense. They're also looking after 20 other clients' mature and stable systems. They likely always have enough work to keep them going. They can afford to have that really really specialist guy that knows all about something weird which is rarely useful but sometimes critical.
There's a lot to the subject. A lot more than the bottom line comparison that some look at.