Do you have a “Calling” or a “Job”?

I am almost done reading “The Happiness Advantage” by Shawn Achor. In it he talks a little bit about how people view their jobs. Regardless of the job, whether it is a janitor or a CEO, if you view your job as your “calling” then you have a tendency to be more successful at it (success is based on your own criteria).

So I started thinking about what I do and why I feel I am successful at it. First, what is success to me? Well, success to me is a combination of things. It is me looking forward to getting up and going to work everyday (well almost everyday), it is displayed to me as my customers (those folks inside Burt’s Bees at the moment) thankfulness for me solving a real problem, as my work having a positive financial impact to my company, as me being able to spend quality time with my family and enjoy a life outside of my work.  These are my primary criteria and indicators of success.

So lets match my criteria for success with the last year here at Burt’s.

As an Agile Software Development Coach and a Software Engineer my job is to guide others through a methodology that I am passionate about and to demonstrate to them its effectiveness by participating in it as an engineer. I love what I do! And I love the group of people I do it with! We really enjoy our work day. We laugh a lot and swear too much, but we get work done and our customers are generally pleased with our work.

The last year has seen two clear victories for the Agile methodology here at Burt’s. Two projects where the business came away happy and the application development group came away proud of what it produced. I credit the business for being open to Agile and the team for working hard at making it work.

We believe our work has a positive financial impact on the company (we have also been told this by those who would know). We can see the time saved in not having to discern certain data points, in being able to add data points to the ERP without much effort and using those points to make strategic decisions. Great indicators to the application development team that our efforts are paying off.

We also are able to work from home when we need to. When my daughter has a gymnastics meet out of town, I don’t have to beg and plead to get the time to go.  When my son has a soccer tryout at 5:30pm 45 minutes away through Raleigh traffic, I can leave early to get him there. When my wife and I want to spend time helping a refugee family during the day in Durham with our church group, I am given time to do that. So my life outside of Burt’s is a blessing and I am happy to be able to have one.

Do I feel my job is my “calling” as Achor talks about in his book? You bet! Do I think I am more successful as a result of my attitude or does my attitude stem from my success? Well, I believe my attitude contributes to my success more than my success contributes to my attitude but each case is true.

In my previous “job”, I felt I was successful to a certain extent but I did not see it as my “calling”.  It did not hit all of the criteria I outlined above. Some things were missing. Which is one reason why I left to find my “calling”.

What is your “calling” and are you doing it?

Till next time…

Technorati Tags: Software Development,Agile,Coach,Engineer,Methodology,Durham,Attitude

Strong Management in Agile Development Deflect and Prevent Distractions

I remember in High School listening to Bill Cosby when he did the bit on parenting.  How he compared parenting to being a hockey goalie, I think.  The parent needed to deflect one tantrum after another or something like that.  It has been a long time since I listened to a Bill Cosby tape.  That was funny stuff back in the 70’s and 80’s.

Little did I know then that what Cosby described would be applicable to leading and managing teams. A good leader can be like a hockey goalie with his team as the net and all the distractions as the puck. He does his best to prevent the distractions from causing in-efficiencies on his team.

What do I mean when I say distractions? This can be a very broad range of items but in the software development world it can generally include things like unnecessary meetings, office politics, feature and scope creep, pet projects that aren’t a priority to the business.  There are many more but these are a few I have observed over the last few years.

In an agile development shop teams are supposed to be communicating and interacting directly with each other and with stakeholders on a daily basis. This means someone from the business needs to actively participate in the process of developing the software and have the authority to make decisions regarding that software. In some instances the stakeholders are represented by a single person. This person should have the authority to make decisions and communicate with the team when ever they feel the need. It is management’s responsibility to give this person the tools and resources to be as efficient as possible in this communication.

Some may think this contradicts the deflection theory because “why on earth would a business person talk directly to a developer?” (Yeah – I heard that), but I disagree. The key to deflection is the unnecessary bit:  things that are not required to move the project forward.  In my view this communication is required. Not only is it not a distraction but it is, if done right, one of the single most important aspects of software development.

This is where management plays a key role in the agile world. Sure the teams should be self-directing and be made up of all that are required to push the product to the customer. But management is important here because they hold the bigger picture in hand. A good manager will work with the development team and the stakeholders to be sure there is proper direction and focus. He will prevent any distractions that may result in loss of velocity. He will give guidance when there is a conflict in the priority of stories. He will prevent the office politics from interfering with the movement of the team.  He does all these things so the team doesn’t have to; so the team can do what it does best: produce software that meets the customers prioritized requirements.

Thanks to Bill Cosby I enjoyed some summer nights with friends around the tape deck in my youth. I didn’t know, at the time, that my career would have some basis in his comedy.

Till next time…

Technorati Tags: Management,Agile Development

Software Environments: Separation and Configuration is Key

I just left a meeting with several folks from the server group, the web services group, and my applications group.  The discussion was around environments and promotion of software through these environments. Let me tell you, there are some very different ideas out there regarding this process.

I thought I would let you know how I prefer to make this work so that there is the best opportunity for a successful installation. Now these concepts are not specific to internal software development where the customer is part of the same organization as the group developing the software. These concepts are the same for shrink wrap or cloud based software.  I have worked with all of these types of software development projects and have been successful utilizing these concepts.

The first, and arguably one of the hardest to implement, is the concept of a separation of environments. The separation of environments from step to step should encompass all pieces of a software system wherever possible. This means that each environment should have, where applicable, a web services server, an application server, a database instance (server if possible) to name a few. 

At a minimum a team should have three such environments; a development environment, a test environment, and a production environment. Each containing a distinct and atomic system that requires gates to be passed in order to achieve entry.

These gates should include automated unit tests and code analysis. The code deployed in each environment should have been proven in the previous environment. The automated code that does the actual deployment to each environment should be exactly the same in each environment so you are always executing the same thing from environment to environment and not creating unnecessary variables.  This allows you to have the experience of many deployments prior to the one crucial deployment to production, thus mitigating and alleviating most risks of deployment.

One of the single most important aspects of achieving separation of environments is Configuration Management. Configuration Management is the management of all pieces of a software product’s lifecycle from initial coding through deployment. Configuration Management as a discipline in software development is getting more and more respect these days, for which I am very happy. This is a very challenging aspect to any software development project.  A properly maintained and automated configuration management system is a must for any organization that puts any product into production ands wants to do it as efficiently as possible.

It is the details of each system where a configuration management engineer earns his money. Each will be different based on the product, but the concepts are the same.  One of my favorite books Software Configuration Management Patterns deals with some of these concepts and how source control management is an integral part of the process.

No matter what system you are working on, try to keep your environments separated and remember: automate, automate, automate.

Till next time…

Technorati Tags: Configuration Management,SCM,release planning

ASP.Net – Code Behind and the Times

In 2001 Microsoft gave us ASP.Net.  The successor to what we now call “Classic ASP”. This brought the full power of the Visual Studio IDE to web development. Allowing us to write “Code Behind” in our favorite language, either Visual Basic or C#, for WebForms development inside Visual Studio.

This was a significant improvement to Classic ASP and to the developers ability to quickly produce web applications based on Microsoft Technology.  Up till then we had to use Visual Interdev. And was that a mess or what?

While I was an engineer at FM Global back in 2001, I was on the team that adopted .Net while it was still in beta.  (I know, pretty progressive for an insurance company, huh.) We had Microsoft consultants on site what seemed to be 24/7. We were learning a completely new way to code in a completely new IDE. Visual Studio .Net was simply amazing to all of us.  We were all Visual Basic developers then and being able to code using VB in this new environment was fantastic.

A couple of years later we were building an extranet application for our clients to be able to access their insurance information on the web.  We had been programming in .Net for a while but we were still VB programmers.  We were writing procedural code in an Object Oriented world.  There were some Code Behind methods that were several hundred lines of code long and full of spaghetti.

This is when we started learning about how VB can be a fully object oriented language and about utilizing Agile development techniques to help with the quality of our code.  It all started to come together. Our designs improved because we started to design our code to be testable. Our time to build and release methods were being revamped so we could be more efficient.  We were using code generation tools. It was a time of great learning.  We made our share of mistakes but all-in-all it was good.

Why do I reflect on such times?  I was reminded about these times because I am currently working with a group that is in a very similar situation.  Folks who are mostly COBOL programmers learning ASP.Net for the first time or are early in their object oriented programming learning and none of them have any Agile exposure at all.  I am sharing my experiences with them to help them grasp some of these concepts.

While doing a code review, one finds an asp button with an OnClick event that has 300+ lines of code in it, one is reminded of these times.  I am coaching my team in the craftsmanship of Agile Software Development, Object Oriented Programming and ASP.Net. So it behooves me to try to remember where I was and remind myself that there was a time when I wrote 300+ lines of code in a single method.  Well, maybe not that much but still…

Till next time…

Technorati Tags: Visual Studio,Agile,Object Oriend Programming,Microsoft,ASP.Net

When you can’t get where you want to be.

Many times in my life I have wanted to be somewhere in my career or in my family life that may have been just out of reach. It is during those times that I have had a significant amount of growth and have met some of the long lasting fiends in my life.

Back in 1995 when I was a theater electrician working in the Fox Theater at Foxwoods Resort and Casino, I knew I wanted to be a computer programmer. Don’t get me wrong, I loved working in the theater. In fact, I continue to work in the theater till this day. But what I wanted was just out of reach. I had no formal computer training and I couldn’t stop working to get it.  This is a situation a lot of folks are in today, I’m sure.

So I was fortunate enough to hook up with someone else in the theater department who was doing a little computer work. He and I became fast friends and still are very good friends to this day.  (His wife and kid came up from Florida to visit us last spring and we truly enjoy each others company.) Pete and I did little things in the theater department with computers to help our bosses.  He started a daily log for the technicians and I started a scheduling program for the lighting group.  We were learning more and more as we went along. We stretched ourselves because we new where we wanted to be.

Our bosses started to notice, and fortunately for us, they were progressive enough at the time to see where this could lead the theater department.  Soon, Pete and I had our own office with the best computers you could buy in 1996 and a copy of Visual Basic version 3 or 4. We went to a couple of training courses and the next thing you know we are, well sort of, real programmers. 

This paid off for both of us when Foxwoods decided to centralize all the folks working in IT. Pete and I went on to work in MIS. We are both now far into our IT careers and I am very thankful to him, Bill and Brian for helping me get to where I wanted to be.

So the point I am trying to make here is that sometimes when you cant get to where you want to be, maybe the best place you should be is where you are.  Look around you. Take in what is happening.  See where you might be able to utilize a skill or technology that will help promote you to where you want to be. And notice the people around you.  Who has influence? Who can you help that may be in a position to help you out someday.

In my case, at the moment, patience is my greatest ally. Where I want to be may take some time. And some of the folks I am meeting on my journey are absolutely the best. So, Jane, JD, Marc, (to name a few) I thank you!

Till next time…

Retrospective: Does it help?

In the world of Agile Development there is this practice known as a Retrospective. A Retrospective is when teams get together to reflect on what happened during the iteration that just completed.  it is a time for the team to answer a few questions about their process, the result, the engineering, anything that may need to be reviewed by the team for approval or improvement.

If the team is serious about its commitment to self organize/govern then the Retrospective is crucial to the teams success. Being able to discuss openly what you may need to improve on is a great tool to improve efficiency. It has been my experience that this takes a couple of iterations before the team really can see the results of their efforts.

On the other hand, I worked with a team late last year that got it almost right away.  The QA team member was not on the same page as the other team members and that came out in the first iteration’s retrospective. suggestions were made for improvement and some strategies discussed. An action plan was implemented.
At the next iteration’s retrospective the team was openly thankful to the QA team member for his role during the iteration.  They also were all encouraged by what open communication and review can do to help the team be more efficient. It was demonstrable for them. It was tangible.

There are many ways teams implement retrospectives. I like to answer three questions:

1. What did we do well?
2. What do we need to improve on?
3. What will we actively work on and how?

I find these three questions as a starting point to move teams closer to efficiency. What are some of the ways retrospectives are utilized in your Agile team?

Till next time…

Technorati Tags: Agile,Retrospectives

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…

This Will Make Someone Happy

Today I read a blog from Sean McCown that encourages developers to be professionals when it comes to interacting with a database.  In a nut shell, (Go read his blog for more) he says that coders should not write code a specific way to make the DBA happy.  They should write the code that way because it is right way to access a database.

I appreciate Sean’s sentiment and would like to take that a bit further.  This paradigm should be applied to all disciplines surrounding an application developer.  Whether it be the DBA, the QA analyst, the Build Engineer or the Automation Engineer. They all have the “right” way to access or to test or to automate. These are not because they want to make things hard for the app dev, no. It is because each discipline has specific knowledge about how their systems work the best. 

Just as a DBA can say this way to code will retrieve the data you want faster and more reliably than the other way, an Automation Engineer can and should say, coding this way will make the automation work more efficiently and have a higher quality return rate.

A coder will have a greater understanding of where efficiencies can be gained in his application if he can reach out to these disciplines and understand the “whys” instead of just making someone happy.

Till next time…