Category: Enterprise Agile

I can remember a time that being an enterprise developer involved knowing one major technology.  For me, that was Java.  We wrote monolithic applications in Swing, and deployed by running an installer on the desktop.  User data was stored in files and sharing meant putting data on a floppy disk and handing it to a colleague.  Eventually, critical projects started storing data in networked databases using Oracle or MS SQL Server.  We learned SQL.  Around the same time, backing up our source code to a network share went out of style in favor of version control systems.  We learned CVS or SVN or Perforce (and learned hard lessons about Source Safe).  When the web arrived, we had to pivot from Swing to HTML and JSP, and would copy-paste some Javascript into our pages for some scrolling text or other fancy animation.  We were full-stack developers, learning quickly to grasp the growing ecosystem in our enterprise.

Fast forward to today: the last enterprise project that I worked on included a Javascript framework (Angular JS), a CSS scripting language (SASS), HTML, a web server (Node.js), a Java API (Dropwizard), a Java server container (Jetty), an ORM library (Hibernate), a database (Postgres), database migration scripts (Liquibase), server configuration (Puppet) and we experimented with Docker.  OAuth2 handled authentication and authorization.  It was deployed on AWS so we needed CloudFormation Templates to help manage server and storage instances.  We were required to support desktop, tablet and mobile so we built a responsive application that needed to be designed and tested on all three targets.  They were considering native mobile in the future which would bring in iOS and Android technologies and the testing baggage that comes along with them.

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.

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.

=Kevin