The country needs and, unless I mistake its temper, the country demands bold, persistent experimentation. It is common sense to take a method and try it: If it fails, admit it frankly and try another. But above all, try something., Franklin D. Roosevelt

I'm a Product Development Leader at Ericsson. Ideas and thoughts expressed in this blog are my own personal views and not an endorsement by Ericsson.

Tuesday, 6 January 2015

This is an expression of my observations of the challenges I see teams facing.For our organisation to be agile, we have an explicit need for the "Vertical slice" team. Where every team can make updates across the system, pretty much independently of other teams. Nothing, or at least no other team, gets in the way of progress of the "Vertical slice" team! But in the real world we often shy away from the Vertical team from both a line management and a technical leadership point of view and we continue to form component based teams.

Management are tasked with staffing teams with enough competence to get the job done. When focusing on a component, it is far easier to tick competence boxes on the fewer technologies. Also certain in vogue technologies' developers command a kings ransom. It's just financially impossible to have one of those guys in every team.

For developers, the "money" is in being an expert in whatever technology is currently "hot", so developers have a inherent incentive to become an expert in relatively few technologies. The best way to become an expert is to focus entirely on that technology.

The component based team:

Pros

The most "natural" way for most organisations to setup its' teams.

Scope of the teams' responsibility is small so they have excellent technical focus. There are a few technologies that the team works intimately with, all the time. Line mgt and developers are happy.

Team members can become true experts in an area or technology.

Can build out a "complex" component out of sophisticated "niche" technologies relatively quickly.

Cons

That team only knows a small part of the system. They are effectively limited to working on that part of the system.

The team can have the illusion of being successful in a product that is failing

There is a big "tax" when moving people or other teams onto or off this component.

Those people become key to the organization even though they might not be domain experts in the business. The team can make themselves indispensable to the organisation.

Component becomes impossible to fundamentally change its technology as the business changes. A component team is loyal to the technology because they have so much expertise. The business adapts its solutions to fit the technologies employed.

Long term waste/expense. Over medium to long term you end up building parts of a component that are "nice to have" and may never be used by the business.

Monday, 5 January 2015

Its been a while... Had a busy 6 months since my last post. With the new year and all that I'm back and will be creating some articles. The main aim of this blog is to share some observations and knowledge, while re-enforcing my own learning.

The aim is at least 1 per month, as per last year. While I haven't been publishing, I have been gathering some ideas for articles. I hope to add some book and video reviews as I go.