Category: Agility

Is it time for developers to specialize?

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.

 

technology_growth

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.

Busy is not productive

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

While there is value in the items on the right…

The agile manifesto is a precisely crafted document in which every word matters.  The phrase “while there is value in the items on the right” if often interpreted as “we must avoid the things on the right at all costs”. This is neither the intent of the authors of the manifesto nor is it a good way to develop software.

Processes and tools

Processes and tools can help bring about consistency which reduces churn, reduces duplication and increases predictability. One of the biggest challenges for agile software development is that traditional managers believe that they will lose control of the development effort.  This will erode their ability to predict when milestones will be accomplished. A process can give newcomers that security while still fueling innovation.  The process does not have to be heavyweight or dictated by management.  The team can decide on and agree to follow the process.  Careful selection of tools can save money and effort; not everything has to be written in house.  A thoughtful balance is necessary to success.

Comprehensive documentation

If there is a single extra word in the manifesto, it might be the “comprehensive” in this line.  I find it very difficult to ever value comprehensive documentation, and much less to create it.  That said, some documentation has value and that is often neglected.  The argument is made that tests and well written commit messages substitute for all documentation on a software project.  “Getting started” documents, architectural diagrams and notes about interactions with external systems can be very valuable to a project and save the team a lot of time.  Recently I had a discussion with some colleagues about Javadoc comments.  They were being required to comment every method but found that most of the existing code had boilerplate comments that satisfied the static code analysis tools without providing any useful information.  We agreed that adding Javadoc comments for an external facing API made sense, but internal classes should self-document with good naming conventions and tests.  In short, any document that you as a developer would want to read should be written for your team.  One day you might thank yourself.

Contract negotiation

My wife works in the insurance industry and frequently shares stories of lawsuits and claims. This is the world we live in, and a good contract is the difference between freedom and shackles. A well crafted contract supports changing priorities, team size and direction. A poor one limits the team to a narrow objective that might as well be solved with a waterfall process. Work to get the contract out of the way and move on to the real problem.

Following a plan

In the same way that I think the “comprehensive” in “comprehensive documentation” is superfluous, the “following” in “following a plan” may be the best placed word in the manifesto.  This line is misinterpreted more than all the others and is use as justification to skip any kind of release planning, forethought, and design.  Eisenhower said “Plans are nothing; planning is everything”.  Waterfall teams spend up to months planning and the plan is held sacred, not to be changed until the cycle is complete.  Agile software must be planned but the plan is mutable and need not be followed.  Planning helps clarify requirements, reveal gaps, set priorities and makes sure the project team and the business are heading for the same goal.  Skipping this crucial step can lead to muddy requirements and, at worst, development of the wrong product that adds little value.

There is no doubt in my mind that valuing the things on the left more than the things on the right leads to higher value software and more effective teams.  Responding to change, preferring working software, collaboration and interactions are very powerful.  The authors of the agile manifesto were right to value them more but also to give value to the things on the right.  Neither group should be ignored and finding the right balance for your team is essential to successful software delivery.

=Kevin