Agile RTP (ARTp) meetup

Last night I attended my first meetup with the group Agile RTP. This is a group of Agile enthusiasts, practitioners, and those who just want to learn more about Agile.  They meet about once a month and have various presentations and discussions around the Agile movement and community. If you are unfamiliar with Agile, see my last post.

This month the presentation was entitled How "Bottom Up" is Failing the Agile Community.  It was presented by the CEO of Gearstream inc., Brad Murphy. Brad is a veteran of software development starting out as a programmer with Smalltalk way back when and moving on to found several successful startups.

So how is “Bottom Up” failing the Agile community?  Well,  the premise of Brad’s presentation is pretty straight forward and one that I have talked about before in this space.  Agile is not just a practice that should be isolated to one group in an organization.  Though my experience has been that it is in these silos that Agile has it’s roots. In order for Agile to be as successful as it can be, the inclination, the encouragement and the participation needs to start at the top. Executives, Directors and Sr. level managers need to be actively involved in making and shaping the Agile effort in their organizations.  As Brad indicated in his presentation, without commitment and participation from this level, the effort is doomed.

One thing that I would have liked to hear more about is how small companies can break through that executive barrier.  Brad started his presentation with the disclaimer that his experience is primarily with very large companies and their executives.  There was a little bit of discussion around this topic after the presentation and what I got from that is that small companies and large companies have the same goal: create value to succeed. 

The Agile community needs to address that goal, not just show that Agile saves the company money and gets the product out the door quicker (which are valuable outcomes). Brad shows in his presentation that in some ways these quick fixes can diminish the movement if that's all that is presented.  He gave the example of Apple and Dell in 1997.  Apple was a smallish company with somewhere around $700 million in revenue and Dell’s revenue was around $3 billion (can’t remember exact figures).  Today Dell is a $30 billion company and Apple is around $250 billion company.  The difference is that Dell focused on the thought that the consumer wanted cheap PCs while Apple focused on providing value that the consumers didn’t even know they needed.  It’s all about providing value.

All-in-all it was a well received presentation with some very interesting questions, answers and discussion following. If you are at all interested in Agile, I would encourage you to find your nearest Agile community get-together. If you are in the triangle area of NC I hope to see you at the next meetup.

till next time…

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…

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…

Interesting CCNet behavior

We have a utility that generates our build scripts when it is passed a directory path as an argument.  The utility finds all the .sln files in the directory and its sub directories.  Then it interrogates the sln files to find out what the project dependencies' are and then generates a build script.  We use this utility in all of our CCNet projects.  CCNet calls the utility and then the next CCNet task calls the resultant batch script.

The engineers wanted to use this utility for their daily local builds so I created a single batch file that calls the utility based on a known Build location that contains all our sln files and then calls the batch files that were just generated.  Unfortunately, if one of the batch files failed it would exit out of the entire script with the exit code not allowing the engineer’s build to continue.  Now this is expected behavior given that none of the generated scripts’ EXIT statements have the /B argument. So I added it.

Everything seemed to be fine when I ran my first tests.  These were positive tests to make sure existing green CCNet projects would stay green.  But then on my negative tests something unexpected came to light.  My red build returned green.  I wanted to validate this was the case so I removed the /B from the batch script and ran the test again. The build turned red.

I am not sure why this is the case.  I looked through the CCNet doc but could not find the answer.  I am not sure if this is a CCNet issue or a CMD.exe issue (CCNet uses this when shelling out to batch files.)

My solution was to add an argument to our script building utility. The utility, with the new argument present, will generate the scripts with the /B on the EXIT command.  If the argument is not present then it does not include the /B.  I then added the new argument to the batch script for the engineers and now we are all happy. 

Well sort of. I still want to know why CCNet behaves this way. I created a thread on the ccnet-user google group discussion board.  I’ll update you on any responses i get.

till next time…

New Feature in CCNet 1.5

So I was looking at the CCNet documentation this morning because I needed to refresh my mind regarding some syntax.  As I was searching I found the Parallel Task feature.  This feature allows you to run several tasks at the same time as the name might indicate.  Well this is all well and good and I will use the Parallel Task feature.  But what was even more exciting to me (I get excited easily) was the Sequential Task feature.  I know, I know.  You say CCNet has always had sequential tasks.  In fact, they are built sequentially automatically.  Yes this is true.

But what I could never do is have CCNet move on to the next task if the first task failed.  Now I can.  See, the Sequential Task has an attribute associated with it called continueOnFailure.  This is a boolean attribute that if set to “true” allows the set of tasks inside the sequence to build even if the previous one failed.  I love it!

I love it because I am using a ccnet applet tool which I have written about in a previous post that allows me to forcebuild a CruiseControl.Net project from the command line.  This comes in very handy.  Well, I use this in all of our builds here at Emergent.  But sometimes because of the nature of our re-usable config files I want to force a build that may not exist yet on some build machines, say, if I were just testing it on one machine. So I put these forcebuild steps inside this sequential task with the continueOnFailure set to true and I am golden. 

I haven’t put this into practice yet because I just found out about it.  But, I’ll let you know if it doesn’t work.  I’m thinking it will.

Till next time…