January 2008 Entries

This week I learned a hard lesson.  I was at a customer site and assumed that because my boss agreed with the Agile principles and practices that I was touting, then the customer would agree without question.  I didn't even make a proper presentation as to the benefits that the customer could expect.  Michael Cline said in response to my last post, On Agile Island, "the customer cares about one thing. Does it make my life easier?"  I shared various features of Agile, but I did not really address the benefit to the customer.  I did not take the time to understand his process and his point of view.  Ultimately, what I was doing was proposing a considerable change with no obvious benefits. 

People hate change.  I was forced to regroup and look at how I could still apply Agile principles and gain the customer's confidence at the same time.  As Michael suggests, many of the Agile practices are for us, the builders of the software, and are not directly beneficial to the customer.  Indirectly, these practices allow us to provide a better product to the customer.  But, he is blinded by the prospect of drastic change.  Our goal should be to introduce small changes that gradually lead our customers to a new status quo.  We should help them become Agile without even realizing it.

So, how will I clean up the mess that I have made?  First, I will give the customer what he wants.  Then, I will speak in terms that he understands.  Finally, I will implement one small but significant change, iterative development.  This is one change that the customer is willing to try.  After a few iterations, I hope that the customer will reap the rewards.  When the time is right, when he can say, “This is what we do”, then I can consider the change successful and move on.

I am working on two new projects.  On one of these projects I am the only resource.  I am responsible for obtaining user stories from the customer, testing, development and deployment.  The only thing that is managed by someone else is the  priority of the stories.  There are a couple of things I noticed that is different than Agile team experiences that I have had.

First, while it may seem that this situation greatly simplifies communication, it is still of utmost importance.  What I mean by this is that I still need to document critical decisions and the reasons behind them.  I cannot assume that I will remember everything.  The good news is that the documentation can be less refined.  The bad news is, I am the only person to hold myself accountable, so it is easy to say, "I'll do it later", or "I'll remember, I don't need to document it."  It is clear that Agile requires great discipline.  I believe that an Agile individual has to be even more disciplined because of the absence of accountability.

Second, two brains are better than one.  Probably the greatest difficulty I face is coming up with good solutions to the problems that I face.  There is no substitution for collaboration.  I simply do not think like other people, so I may not see the things that they see.  Each person, each role, has different experience and a different perspective.  Collaborative brainstorming opens doors to elegant solutions that individuals alone may never discover.  This is one of the greatest values in a team that I will sorely miss. 

On the other hand, I am fortunate to have established relationships with individuals that enjoy sharing ideas outside of the office.  Though many of us work at different organizations, we share in the same cooperative game.  We seek to improve our understanding of the software development process in order to advance our careers and benefit our employers.  These long term relationships should never be neglected.  They are invaluable.

I was talking to a former coworker and good friend of mine today.  He suggested that I include, in my blog, my experiences of working from home.  At my new job I am working from home almost every day.  There are certainly many benefits (like fewer trips to the gas pump), but there are also some drawbacks.  The most obvious drawback that I have already encountered is the difficulty in collaboration.  Essentially, this is part of the reason I started this blog to begin with.

I am new to the bubble-boy environment, so I won't issue any judgments yet.  I'll wait a couple of months.

I have started on a new project and am looking forward to implementing continuous integration (CI).  There are quite a few decisions that need to be made as far as how we want to handle the build and deployment process.  I am working with a small group of people who have worked together in the past.  They have some practices that have worked well for them.  I don't want to rock the boat too much, so I am evaluating their process with what I know and am familiar with myself.  The biggest difference between us... Java for them and .Net for me.

The first significant divergence is related to database change management.  They have used a process maintaining change scripts for their clients while updating the creation scripts for source control.  This allows them to easily query their source control system for a specific revision and build both the application and the database.  Personally, it feels like there is extra work involved in updating the creation scripts.  I like the idea of storing the change scripts (including data manipulation to accommodate updating schemas) in source control and letting the build tool of choice execute the scripts in the proper order.

I will be working with the team to determine what makes the most sense for us.  If there are no compelling reasons to change this aspect of the build process, then I will leave it alone.  Another consideration is making it easy for developers to submit change scripts in reference to user story or defect ids.  The team already has something similar for their previous projects but I think that it is specific to a client.

If anyone has experience with either of these approaches (or with other approaches altogether) feel free to provide feedback.  Expect an update in a couple of days.

Well, I have been thinking about hopping on the blogwagon for quite a while.  Now, I have finally done it.

For a brief introduction to me, I am a software developer of 13 years and an Agilist.  I am currently at a new start-up company, Xcis-Software.  As you can imagine, my responsibilities are extensive.  I see this as a unique opportunity to put Agile into practice from many different perspectives.

My intent for this blog is not to provide brilliant insight to the masses.  Certainly, my insight is very limited in scope.  Simply put, I want to keep an online journal of my software development experiences.  There are two compelling reasons for this.  First, it is nice to know where I have been.  If I find myself criticizing others for their technical decisions, then I need only look back a few months to recognize that I am not as smart as I thought.  Second, I want to provide a means for my friends from past collaborations to keep in touch.  Perhaps I can initiate some brainstorming sessions along the way.

Welcome to my blog.