strategic User Experience design and a transformation toward a user centric organization. A mention briefly the requirement of multi-skilled and multi-functional engineering teams, but before going into that I want to take you back say 15 years.
In the mid nineties the bulk of software engineers either worked on the Windows platform or on some kind of mainframe. I was part of the first group and remember very well that Microsoft encouraged us the follow the Windows DNA (if I remember well) that basically was marketing speak for three tiered solutions with a data, business and user tier. The story was nice and correct, but the implementation was hard. The technology based on COM and DCOM was just difficult to get deployed and hard to get robust. Many decided to ignore and just build very fat client applications. For this engineering teams used their favorite development tool, for instance Visual Basic, Visual C++, Delphi, DBase, FoxPro, etc. and an engineer would cover a chunk of functionality from the database up to the user interface. Working on the user interface was more focused on following the Windows style guide as it was focusing on the user and how the execute tasks. The companies successful in this era differentiated based on their technology capabilities, as I also said in the importance of strategic UX article.
Fast forwarding to today we can also see that Microsoft consistently have been telling us to separate the business logic from the user interface and always has provided tooling and architecture patterns to do so. We also see that the scope of solutions we need to offer today has has become much broader. Depending on your solution you might need a native Windows and/or Mac client, a web client (including one working on tablets) and mobile clients for iOS, Android, Windows Phone and Blackberry. The number of platforms, each with their specific engineering challenges, has exploded and at the same time we want to transform the business to have a more user centric focus. This is your challenge of today.
The generic software engineer from the mid nineties is not going to solve this challenge, you need specialists for each individual area. If you ever watch Pimp my Ride on MTV you see that there is a specialist for the bodywork, interior, sound system, engine, wheels, etc. and they all work together to deliver the end product. In software development, unless you want to settle for mediocre, you need exactly the same, a specialist for every single little detail of the solution.
If you're an engineer reading this you have to decide who you want to be and study to become one. It might sound harsh, but you won't survive if you don't specialize. If you're a manager reading this you have to review your team and/or organization and restructure, reeducate and rehire to make sure you get the right expertise in the right place.
Scrum brought use multi-functional teams that build end to end solutions, however there is a limit to the size of an effective scrum team. It might not be possible to fit all in a single team and you might have to rethink the scope of your solutions. What if the API is the end product? In this case your scrum teams can deliver up to the API and other teams than deliver the various client solutions. This scales better in your organization and allows easier outsourcing of expertise you don't have or is to costly to gain. This especially might be true for developing many different mobile clients.
Great software can only be delivered by a team of specialists.