The Front Log

Everyone knows a well groomed back log is a key to agile development and yet most development teams don’t have one. One of the most common mistakes I’ve seen is that a team will start a long term project and not go through the process of creating features, stories in those features, and working through the high level implementation of those stories.

Skipping this process has bitten every development project in the ass. What happens is that as the dead line approaches (yes there is always a deadline) the development team realizes there is suddenly ten additional stories needed to actually move the application into a usable state. Or worse yet, the business owner suddenly realizes that a key feature(s) is missing and it will CRIPPLE THE WHOLE BUSINESS FOREVER if it is not there on go-live.

Most of this can be avoided if you just spend the time going over the features and stories from the get go. And I mean go over them. Glazed looks from developers absentmindedly agreeing to everything does not count. Business owners writing emails on their phone does not count. This is truly a case of an ounce of prevention is worth a pound of cure.

The front log is where a team just keeps adding features as the project goes on, knowing full well that they are due at release, completely destroys estimation and timelines. Don’t skip backlog creation and don’t skip grooming. It is the leg-day of software development.

Arrows of Responsibility

Look, as developers we know we are the best. You need a database, we can set one up. You need IIS configured, no probs. Load balancer needs configured? Shut your face we’ve done that hundreds of times. In large orgs we do not have control over every aspect of application and very often there are specialized teams to take care of those tasks for us.  And yet, even though they are essentially “helper teams” that perform one aspect of the development process it is those helper teams and not the development team  that can set insane SLA’s (a freaking month to setup a production database???) or demand certain artifacts before they will even begin to consider scheduling your work. I call this the arrows of responsibility.

Depending on your organization, fighting this battle can range from tough to impossible but I can tell you it is worth it. Ignoring problems with external dependencies will kill your progress. Allowing external teams, especially if they are a weak link in the development process, impose restrictions on you without you agreeing will slow down development.

Now there are a few strategies you can use. One is to realize it is a war and take any small victory you can get and never give up ground. Meet with these teams and work out expectations in advanced (this is where a useful backlog will prevent your team from scrambling and looking dumb). Talk to QA and agree on what is a “bug” and how it will be tracked (please do not create bugs during a sprint for an in-progress story when you know it will be fixed). Talk to the database teams to let your devs do some development while allowing them to do code reviews. Find the pain points and attack them. If you are persistent then things usually improve.

However, some organizations are so large that you’ll come out of those meetings feeling like you are fighting Cthulhu. Insanity will set in and you’ll consider crushing your skull with the side of your laptop to escape the nightmare you must be in. If this is your scenario, use the corner of the laptop as it is the strongest point and best for crushing. Also, invest in Dev-ops.

Automate away those pain points as much as you can. Release management tickets a pain? Now you have one click deployments (And you can send automated tickets for tracking purposes to keep that team happy enough). Gathering database scripts together take a whole day only to have the db team reject it? Deploy in the CD pipeline using DacPac (if you’re using SQL server) and have that team be part of the approval process so they have no excuse about not seeing it before. The benefits are many. If you are not doing Dev-ops yet you are giving these other teams a chance to meddle in some manual hand off process.

Agile Waterfall

Just don’t for the love of a non existent God. Having three sprints of requirement gathering, four sprints of development, two of testing, and one of deployment is not making your application any better. Pretending to be agile by just calling yourself agile does not work. And no, you are not in the process of transitioning; you are merely in the process of self delusion. You get none of the benefits of an iterative process and (most likely) all the annoying ceremony of grooming sessions and retrospectives without any of their benefit. The whole point of agile is that you do what works for you but it should always be with the principles of agile in mind: iterative, empowered, and speed.  If all your development is one and done, you’re not agile.  If your dev team has no say over how it builds something or what tools they use you’re not agile. If your process gives you no room to fail then every failure will be a catastrophe. Agile waterfall masks all the risks but solved for none of them. It will also make the process of moving to agile a joke to your team.