What makes them tick?

November 10, 2007

Recently, I was involved in a discussion regarding the optimal organizational structure for a large software engineering organization. Several of the attendees were proposing various structures. The primary goal was efficiency and maximizing the output of each individual.

The proposals included ideas such as creating a resource pool made up of software engineers with varying skill sets where team members act as a group waiting for assignments. In this scenario, any given engineer could be working on many different projects over a period of time. The source code tree he is working on today may very well be different than the one he had worked on even the prior week.

As the discussion progressed, I found myself believing the participants had missed a critical point. My belief was and is workers (software developers in particular) need to feel a sense of ownership in the project they are working on. In other words, most modern day developers are not content to work on code where they do not have an understanding of how their effort relates to the success of the unit. Beyond understanding, they need to feel as if they have influence. My belief is not only based on a suspicion regarding what motivates software engineers, it is primarily based on personal experience.

During the course of discussion, I commented, “regardless of the structure that is chosen for any organizational structure, it is critical to analyze the individuals which participate within that organizational structure. You simply cannot make a decision regarding organizations without an understanding of the impact it has on the individuals”.

Admittedly, the notion is somewhat intuitively obvious. However, I have witnessed many discussions regarding companies, organizations, etc. which simply do not take into consideration what it is that makes the employees do what they do. What makes them tick? While its impossible to generalize across a large organization, everyone is different, it is possible to understand the general effect an organizational structure may have on a team. The first test, simply ask yourself the questions…How would I respond if I were put into a given work structure? How would it feel to transition from collectively owning a product to serving a role in a resource pool? Would you be as motivated and energized?


What’s in a name?

November 10, 2007

Today, this blog received its final name “Working Software Every Two Weeks”. While Agile development may mean different things to different people. One key concept remains consistent. The successful Agile development team will focus on completing working software in very short time frames or increments. For many Agile teams the chosen length is two weeks.

For me personally, this name carries great significance. My first introduction to Agile development included the statement “that is a nice waterfall process, however, I am most interested in a software methodology that allows us to deliver meaningful software every two weeks”. Admittedly, I was quite skeptical at the time. Today, the skepticism has been replaced with deep conviction that Agile development is the most productive and rewarding way to create software.