In an earlier post, I outlined why I think that there is value in enterprise developer specialization. I concluded that there are four emerging classes of developers: User Facing, Mobile, Business Logic and Data, and Operations.
Continue reading “The User Facing Developer”
Without debating the merits of any of those particular technology choices, this is a pretty typical tech stack for a modern enterprise application. Customers have come to expect a certain level of style and polish from their applications. They also expect the applications to be secure and fast. To achieve these results requires a complex and diverse set of technologies, being implemented by developers that fully understand their capabilities.
The diversity of these technologies along with the rapid pace of change in the industry have led me to conclude that it is no longer reasonable to be a full-stack developer. Instead, there are four general classes of developers in the enterprise development space. They are User Facing, Mobile, Business Logic and Data, and Operations.
Over the next few weeks I am going to address the details of these classes, how they fit into a unified agile workflow, and respond to some of the doubts that I have heard from full-stack developers and their managers when I have discussed this topic.
Martin Fowler published some of my thoughts on Enterprise Architecture!
Often, I am asked to help teams that are not accomplishing their goals. The team insists that everyone is working hard and always busy. They feel that the problem is in the requirements, schedule or demands of management. Their customers and management feel like they are not getting what they want out of the team. If the team is busy but not delivering enough value, what is happening?
Almost certainly the team is not using value-based metrics. They are either working without measuring progress or using self-serving metrics like velocity or utilization. A team can work all day, but unless that work furthers a customer or business objective, the work is not productive.
If your team is busy but not perceived as getting the job done, reconsider how you are measuring work completed. Be sure to include some kind of value metric. In the best case you can tie directly to business objectives like sales, conversions, margin or new customers. If your lead time or delivery cycle is too long, consider asking your product owner or stakeholder to score stories on business value. Measure points velocity but also consider business value. If you are completing a disproportionately high number of low business value stories, consider your iteration mix. Make sure to include enough stories that the business finds valuable along with those your team values, like tech tasks or tech debt remediation.
Being busy is not inherently a bad thing, but busy and non-productive is bad for morale. It usually results in the business asking more from the team, leading to long days and death marches. Always be prepared to demonstrate the value of your work to the business and adjust accordingly. A team working fewer hours productively will be valued higher than a team working hard and accomplishing little.