Friday, April 23, 2010

Are you Agile?

I recently went to a seminar in Durham on Agile Development Methodologies. This seminar was sponsored by AccuRev and Anithillpro (UrbanCode). I learned a little bit, some of my core beliefs were re-enforced, and I was a bit surprised by the level of Agile development my company was at compared to other companies that were represented at the seminar.

So, first of all, for those not acquainted with the term Agile, here is a link to wikipedia’s description and below is the Agile Manifesto.  I have been told that any presentation on Agile should include the Agile Manifesto. So, while this is not a presentation, I believe it to be valuable to see it in black and white.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

There is also the related “Twelve Principles behind the Agile Manifesto”.

So what did I learn in this brief seminar? One of the main take-aways from the seminar was directly related to the last line of the Manifesto.  This was probably skewed a bit because the seminar was sponsored by a tools company. But, I learned that the items on the right are important so long as they support the items on the left.  That is, if someone tells you that they are doing Agile therefore they do not use tools, write documentation, or plan their design.  They are not doing Agile.  Tools, Documentation and Design are very important, so long as they support the items on the left.

What were some of the things that helped re-enforce my core beliefs? First, Agile requires management and executive by-in and participation.  Too often a team that practices Agile Development falls flat.  One reason for this is that the management and executives either, 1) do not have by-in to the process and do not promote the process. Or, and what I believe to be the worse of the two scenarios, 2) they do not participate in or own the process.  The success of any development methodology hinges on management and executive participation.

Second, and related, is the priorities of the development team need to be clearly represented and talked about daily. The Product Owners are key to making this happen.  If a Product owner is successful at transforming executive Value Story Cards to Story Cards for the development team and move them through the swim lanes, then the project has a great chance for success.  If this is difficult for the Product owner and priorities are not clear, the team is doomed. If the executive wants this specific feature to be a part of this sprint then the Product owner needs to be adept enough to help the executive decide what feature will NOT be a part of that sprint. This is a give and take. I believe this to be one of the most challenging aspects of Agile to overcome.

What surprised me? Well, in short, I was surprised by how much further along my company is in practicing Agile Methodologies than most of those organizations represented at the seminar.  And yet, how far away we are from implementing some of the key principles.  I am excited that we are moving closer to adopting these principles but the realist in me knows that we have a ways to go.  Especially in the area of priority setting.  We continue to learn and move closer, like most teams. And, I am encouraged.

The Agile Manifesto is an important step in the evolution of Software Engineering.  When an organization follows the principles associated with the Manifesto there is no limit to what they can accomplish.

Tell next time…

Thursday, April 08, 2010

Managers Getting Value from Their Team

One of the blogs I read is by Scott Berkun. He writes about management and public speaking.  One of his latest entries is entitled “Should managers know how to code?”.  He basically puts managers into 2 categories.  A. Managers of software development teams and B. project managers and team leads.  Then he makes a series of points that a manager in any role should strive towards.  I’ll let you read the blog to get all the details.

What I would like to comment on is the statement he makes in one of his points. Scott says that “Managers don’t need to be experts – they need to be great at getting functional value out of experts of any kind.” I believe this to be a pivotal statement regarding a manager’s success or failure.

A few years back, when I was a Programmer Analyst with the Mashantucket Pequot Tribal Nation in Connecticut, I had the opportunity to listen to Sir Richard Branson speak about being successful.   One of the most important things I learned that day, and something that has stuck with me throughout my career, is that in order to to be successful one has to surround themselves with people who know what they are doing and let them do it. In my eyes, this is exactly what Scott is talking about.  But Scott goes a little further.

Letting the experts do what they are experts at is only part of the equation.  Another part of the equation is the latter part of Scott’s statement. If the experts you surround yourself with do not add value to your particular function in an organization then their worth as an expert is diminished. Being able to direct an expert’s knowledge and know-how to a particular function to add value is key to the success of any manager.

I have had the privilege of having managers throughout my career in software engineering who are exceptional at this key concept.  I have also had a couple who were very bad at it and it showed. Aside from these two specific cases, one from early in my career and one from later in my career, the managers I have had have allowed me to do what it was I did best and helped me focus on adding value to the company while I was doing it.

The first manager I had that demonstrated this ability, after I really understood its value and looked for it, was Fritz Kade at MPTN.  He demonstrated the innate ability to get his group to, not only accomplish the task at hand, but also to learn from it and apply that learning to future tasks. He helped me through some very troubling times early in my career and I thank him for that because I would not be who I am today without his learning opportunities.  Though this has nothing to do with the subject at hand, he also will forever be memorialized with his statement to me at dinner one night with my wife: “The more you eat, the more you can eat.” Although, he only weighed about 150 lbs.

One of my managers that did not demonstrate this ability very well, (not to be named to protect the guilty) fortunately for me, was not my direct manager but my manager’s manager.  He was guilty of one of the most egregious managerial mistakes I have seen: Drive-by Management.  We spent 45 minutes in a working meeting, that he should have attended, working through the details of a pretty complex insurance policy task.  He arrived at the end of the meeting and stated “this is the way we are going to do it.”  He had no input from his staff and offered no chance to poke holes in “his way.”  We all left that meeting drained.  We wasted our time and effort and worse yet, he lost the respect of almost everyone in that room. This is a classic case of mis-managing your team and your project.

So as a manager I strive to see the value my staff can give in any given situation and help them focus on that value. I believe I have one of the most talented IT staff available so I consider myself lucky.  And they are helping me be successful and hopefully I am returning the favor. Of course, if you have a staff that is not as good as you would like them to be, then you have to have a different ability.  That is the ability get the most out of what you’ve got.  But that is another story and a story of mine that I might tell you about in a later post.

till next time…