Adventures in Agile

This blog is about programming in general and some other topics here and there. Currently the focus is on a lot of Agile practices such as CI, BDD/TDD and other tools/practices that help companies turn out high quality software fast.

Thursday, August 19, 2010

I haven't blogged in a while, but an email from someone triggered me to put up some Agile thoughts.

Someone emailed me an issue today. I thought I would share it with you and include my response:

"... due to an entirely unnecessary international conference call with a brand new manager-type of a big International customer who suddenly thrust himself into a long-running discussion with their Indian subsidiary. Of course, we now have to dance around and kiss HIS culo, so I have to be in the office at an ungodly hour.

I find that the profitability of successful companies disguises a lot of fatty tissue (i.e. not-very-busy Manager-types). So we get a "suddenly self-appointed stake-holder" who is high enough in the mucky-muck list so you can do nothing about it. Of course, after spending all this time and effort to get him/her involved, they fade away, leaving a giant hole in the team's productivity. Anybody have ideas on how to handle these? Suggestions appreciated."

No solution comes to mind except simply supporting an Agile and transparent process should do the trick. Here is some background on the type of attitude that is at work here:

Eventually, these people end up quitting on their own if it becomes impossible for them to hide their antics. Reasons given for quitting usually are "I've outgrown the company", "I need new challenges", etc.

Watch for behaviours such as forcing themselves to be the point of contact for major customers and purposely leaving people in the dark wrt to these customers so they appear to be more knowledgeable. After the useful people have been fired for ineffectiveness (because now they look like they are the fatty parts of the company that can be trimmed), this person ends up with a raise and higher title due to the amount of responsibility. And because they are the ones in contact with clients, they appear to be the only one to have the tools to calm an irate client. They've now become a bottle neck and productivity starts to crawl as the idea of delegating anything wrt requirements is not possible.

Once they quit because the found a better job, productivity goes through the roof! The higher ups instantly know that the joke was on them for the last 2-4 years since this person was hired. They were able to find a better job because on paper it looks like they were doing so well - including a promotion in a relatively short amount of time.

I've seen this at least a couple of times during my consulting days. I call these people "professional ladder climbers". To them, the only goal is to get promoted, get a raise and has nothing to do with making the organization effective. As long as they satisfy the optics, no one is the wiser until it's too late to do anything about it and they've gone to greener pastures.

This is why I support a transparent process. Agile stuff makes this possible. Now to implement some of these processes in government offices so our tax dollars can go to teachers and charities instead of these narcissistic leaches. I suspect most are not self-aware enough or don't care to know their impact on society or those immediately around them.

Since some people couldn't get the time off work or couldn't afford to attend the conference, they won't be able to get the great discount we have on some books that we have at 20% off the cover price. Please look them up online for the price and subtract 20%. We also include the tax in that price. Let me know through twitter:

Sunday, September 20, 2009

Lets start by getting the transaction side of the application going. We're going to have a customer class that will have some simple properties at first.

Here is the project setup:

This is a pretty easy start. We have the test project that will exercise anything that we write. The messages project is where all our messages will reside. The Transaction Service will house our coordination of receiving commands to the Domain. We'll worry about the event publishing in a little bit. The Domain project will house our entities.

A little while ago I wrote about a time machine for your application. This based on Greg Young's infamous Event Sourcing strategy. It's time to get a sample application going with this approach. I'll also take it one step further and apply the same strategy to the reporting side of the application. A lot of this hinges on the Open Closed Principle (OCP) so I'll try and enforce that through GIT hooks.

Here is a recap of the steps I'll be taking:

1. Event Sourcing and CQS to the extreme as prescribed by Greg.2. Event Sourcing for reporting schema changes.3. OCP application to the versioning of the dB instead of version scripts.4. Enforcement of the OCP to the pub/sub of the reporting dB.5. OCP application to the reporting services side through GIT hooks.