Agile Mistakes 

digitalobjectivist

I’ve been on plenty of teams in plenty of different types of organizations. Large, small, transitioning to Agile, agile veterans, teams doing TDD, BDD, and teams having no clue what they’re doing.  And guess what, for the most part they have varying levels of success and those successes make them complacent and unwilling to fight the fight to make the processes better. So below I’m going to compile a list of common mistakes I’ve seen that have slowed down development or helped pile up technical debt.

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.

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.

Finally, I got a mechanical keyboard (G.SKILL RIPJAWS KM780R RGB)

Digital Objectivist

I am in the process of building a new desktop for myself, but since I have children that process is a long one. To spread the costs out I am buying peripherals first. I have gotten two 4k monitors, a gaming mouse, and latest a mechanical keyboard.

I got it from Amazon on sale. Initially a friend had sent me the link to the red led only version but I figure if it has lights they might as well be useful so I upgraded to the full RGB version.

How it feels

I had never used a mechanical keyboard before so I didn’t know exactly what to expect. Well let me tell you expect to be pleased. The tactile and auditory feedback you get with each key press is completely worth the money. If you game or type it is completely worth the upgrade from a normal keyboard. It’s like having Heinz ketchup after a lifetime of Hunts.

Lighting

I am glad I spent the extra money for the full color spectrum; it is just straight up fun. There are enough lighting effects that it gives you incentive to keep typing to keep the lighting effects triggering. Secondly, color coding the keyboard for different games is great. It is helpful to have that visual aspect when looking at the keyboard to reorient yourself when playing. The one thing I wish this had done better actually programming new lighting sequences. The software is not as intuitive as it could be.

Macros

A macro is a macro and this keyboard does pretty much everything you’d want. It’s easy to program it using their software.  I haven’t gotten a chance to play an MMORPG with it, but that’s pretty much where macros shine.

All in all I am happy with the purchase. Being that this is my first mechanical keyboard I don’t know how the other switch types feel but since I liked this one so much I am now inclined to try them out at a Best Buy.  Not buy one there though, obviously.

How Not to Blog

Digital Objectivist

I am a professional software engineer and like most professional software engineers I search for  answers to questions I have coding nearly every day.  Also, like most professional software engineers I have attempted to blog a few times in the past and have made it to around blog post #3 before giving up.

This time I intend the results to be different and to think about the missteps I have made in the past that resulted in my blogs being, essentially, still-born.

Too Specific

Each time I had started a blog previously I had a very specific goal in mind.  Usually that goal was to write coding articles, discuss politics, or analyze non-fiction writing from an Objectivist perspective.  Each time I got bored.  This blog will not be so specific.

Now I don’t want this to be a place where I talk about what is going on in my personal life every day or post pics of what I am eating (it’s probably chicken wings).  I want this blog to be useful.  Useful to coders stuck on a problem or useful to an individual who feels like everyone else is fucking insane with their nonsense ideas.  So with that in mind, around half the posts will revolve around coding with the rest delving into philosophy and politics.  It’ll ebb and flow as the mood strikes me or as one of those topics becomes more relevant in my life.

Too Academic

I found that in my previous blogs I tried to write with a voice that wasn’t my own.  During my day…usually a lot… I find myself cursing or coming up with analogies to help explain what I’m thinking but in my previous blogs I strayed away from that to try and give an impression that I was professional or “above it.”  Well fuck that.  It’s not how I think, its not how I speak, so it shouldn’t be how I write.  Hopefully this means that my posts can come more frequently and easily and I won’t spend as much time rewriting my own words until they’re not.

Too Inconvenient

I had always blogged from my desktop at home before and I think this made it “a thing” I had to do at night after chores were done or between games I’d play.  WELL NOT ANYMORE.  I decided to forgo trying to write my own site or build my own blog software or any of the other insane things we developers try to do to avoid using someone else’s software.  This time I decided to go with a simple WordPress blog that I can install in one click and already has an app for my phone so I can write articles on my way into work or, more likely, while I’m on the toilet.  Nuggets of wisdom can drop while I drop other nuggets now.