The Goal

I participated in a meeting recently that was designed to create a document that would help govern the actions of the organization. I quickly felt that the goal of making a document was lost when we started debating the order of words. I wondered how we were going to get to talking about behavior when we were getting hung up on sentence structure. As I sat there thinking about the situation, I was reminded that the same kind of thing happens in Agile all too often.

People try to implement the details of Agile without thinking about the goal at hand. With Agile, or any software business methodology, the goal should be to deliver value to the customers. The customers define what is valuable, so all you have to do is behave in a way that gets the value from an idea to tangible.

I was reminded today that my writings about some of the details can sound absolute - a "My way, or the highway" sort of ring to them. Sometimes this is one hundred percent true, because the goal of a specific piece may be to evoke a response, to challenge one's current thinking. Other times my writing is about a specific situation in my work that I felt went particularly well or particularly poorly.

At the end of the day, I really have no preference for how a company operates, so long as it does operate in a way that the good employees are happy. My thinking here is that the "good employees" I mention and I can work any number of places, for any range of salaries, and any range of responsibility levels. Yet, they are going to pick to work for one company over another based on their job satisfaction.

My argument, and central theme for my writings in this blog, is that happy employees are good for customers and delivering value. I also submit for your review that Agile has a lot of practices which have a high success rate of leading to happy employees. Thank you for your readership, I look forward to using this new feedback to increase the clarity of what is important when I write in the future.