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

New Buzzword in Software Development–Craftsmanship

9PAUXZYJ7299

There is a new buzzword in the Software development industry.  This buzzword is “Craftsmanship”  There is a Manifesto. There is a conference SCNA. There is a website.  There is a new Academy. And there are many followers, one of whom I had the pleasure to be trained by back in 2006, Uncle Bob Martin, and one I have lunch with every now and then, Jared Richardson.

This is a new buzzword but it is not a new word to the industry. From everything I can gather it originated in Steve McConnell’s Book Code Complete: A Practical Handbook of Software Construction.  In this book, (which every software developer in the world should read) Steve talks about the construction metaphor as it relates to software development. This linking of craftsman in construction to craftsman in software development is not a new thing.

What is new? Well, what is new is the pervasiveness of the word as it applies to software development.  Software engineers are beginning to call themselves craftsman. The connotation of good craftsmanship is something that we all can strive for.  It is a belief that we need to take some pride in our work and always do it to the best of our ability and if we discover that we made a mistake then we own it and fix it.  This notion is spreading amongst our community at a rapid rate. 

The community also champions many extreme programming practices like pair programming and test driven development. These are practices that enhance our craftsmanship while developing solutions to problems. I am very pleased that this word is becoming a part of our nomenclature. I have not always considered my work as full of craftsmanship, but you better believe I strive to fill it to the brim now.

Till next time…

Technorati Tags: Software Craftsmanship,Agile,SCNA

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

Estimation: why can’t we get it?

In software development shops across the world there is absolutely nothing more frightening to software developers than estimating a task. The fear stems from the unknown. The phrase “I don’t know what I don’t know” comes to mind.

The pressure of giving an estimate for a task in terms of amount of effort can be very heavy. Somehow telling someone how long it will take to get this task “done” has turned into a self defense mechanism. So-much-so that sometimes engineers “pad” their estimate to almost twice what they believe it will actually take.

And then, the project managers get ahold of the estimate and they pad another 50%. This brings the estimate to 3 times what the engineer actually thought the task was going to take. And you know what happens? It takes that long or longer, but rarely does it take shorter.

Why? Why do we always end up taking longer than we originally thought? In my experience there are a few reasons for this phenomena. Each of which has played out in development shops that I have been a part of.

The first is the self-fulfilling prophesy syndrome. This is when a developer fills the estimation time because he has the time to fill.  In this scenario, if you give an engineer 8 hours to do the work, he will take 8 hours to do the work. In my estimation this is the worst kind of situation a development shop can be in. Because this is a good indication that your engineers are bored and do not have a vested interest in the shipping of the product.

A second reason estimations are off the mark is because engineers don’t learn from what they have previously estimated. Even green engineers right out of college have some experience estimating. They do it every day of there live in college. How long will it take to get this homework done so I can head out with the guys and play Gears of War? When an engineer is able to take into consideration previous work/estimate relationships and contrast with the complexity of his current task, that engineer is already more accurate.

Another reason is because the task is to great to estimate accurately.  This is the one thing I see more often than anything else.  An engineer has not taken the time to break down the task into manageable chunks. I like to pose this question to my team: Which estimate is going to be more accurate? 1. How long will it take to drive from downtown Raleigh to downtown Durham given moderate traffic conditions? or 2. How long will it take to drive from downtown Raleigh to Times Square in New York City? Of course we all know the answer. Because when we estimate small chunks we are more accurate.

There are more reasons than these but these make up a great percent assuming it is the engineer giving the estimate.  If it is not then there is a bigger issue that needs to be addressed in the organization.  So when an engineer thinks a task is going to take 4 hours he should estimate 4 hours and not pad anything.  He should then take into account how long it did take and what happened during that time. He should use this knowledge the next time he needs to give an estimate. He should also learn to be breaking down his tasks into realistic estimate-able chunks. Some say if it takes longer than a day then it is more than one task. I am not going to be that stringent but I think that is a good target.

Estimating is a skill that gets better with practice.  In the Agile development world we give estimates every iteration and every day. It is the only way to get better.  Keep at it and don’t get discouraged.

Till next time…

Technorati Tags: Estimation,Agile

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

Can Agile work from the bottom up?

Many organizations have tried to implement “Agile” in their development process. Some have been extremely successful.  Others have failed miserably.

I have worked with 4 organizations in the last 10 years that have implemented some form of agile development. They vary in their success and they vary in their implementation.  Each company having its own values and culture affecting the outcome. They also have implemented some of the agile techniques but have not come to emulate the Agile Manifesto to it’s fullest.

I have written about what agile means before. And mentioned the need for support from upper management. I still believe that in order to truly embrace the Agile Manifesto and be successful, an organization requires support from upper management and as far up as the CIO and CEO.

But where does that leave some folks who are learning about Agile and what it means but don’t have the support from above? Well there are some steps you can take as an individual to begin. First of all, don’t try to do everything at once. look at your organization, consider the culture, consider the current process, consider the resources.

A good friend of mine, Jason, brought Agile to the for-front at FM Global, where I used to work and where I first learned about Agile. He slowly brought it in our organization by adapting his team.  He had a few people on his team look at new tools like cruise-control and nunit.  That’s where I started.

Jason assigned me to look at this new tool called cruisecontrol.net back in 2004 and 2005  It is a tool for continuous integration. And another team member looked at nunit which is an automated unit testing framework.  These tools are still around and supported by the community.  But a funny thing happened.  Microsoft took notice and now Visual Studio and TFS have fully functioning Unit testing frameworks and Continuous Integration build systems.

Jason managed to get his team utilizing Agile techniques and upper management noticed. So much so that the company paid for all of us to take an Agile, Test Driven Development, and pair programming course with “Uncle” Bob Martin.  So we trained with the best. If you ask Jason I am sure he will tell you it was a slow process.  He is now a professional Agile Coach so I guess he knows what he is talking about.

My experience has been the same. Since I left that company in 2008 I have worked with 3 organizations all at various stages in their Agile process.  One had daily standups (SCRUM) meetings but nothing else. One had nothing but Continuous Integration but not for all projects. And one had “iterative development” for some projects.  I managed to work with all of them to enhance what they had.  I am still working on the last one.

So can you make Agile work from the bottom up? It isn’t easy and it takes a long time but, you can have an affect.  You may not implement all the agile principles. But some of the common practices can go along way to making your group a bit more Agile.  Keep it up.

Till next time…

Technorati Tags: Agile,Cruisecontrol.net,CCNet,Development Methodologies

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…

To SCRUM or not to SCRUM

I am faced with a dilemma.  It is not a life or death problem, nor is it even important in the grand scheme of life.  However, it is a dilemma I face with my team.

Let me try to explain my dilemma.  We currently are using TFS as our source control application.  we are slowly beginning to utilize the Tasks for development and will continue to move toward integrating QA etc..  We are using the Agile Team Project template that ships with TFS with some minor modifications.  We now have about 17 Team Projects with more to come.

The problem is that our development process is more like SCRUM.  So, low and behold, I found what I thought was fantastic. www.scrumforteamsystem.com developed by Conchango.  This is great! I thought.  I downloaded and put it in our sandbox.  I played with it and found it almost perfect.  Now,the crux of the problem.  Without major surgery,  I can not convert my current Team Projects to use the Scrum templates. 

My dilemma is: Do I bite the bullet and create new Team Projects with the Scrum templates?  Do I spend time upgrading my surgical skills and TRY to convert my existing Team Projects?  Or do I do nothing with the current Team Projects (mine included) and only use the Scrum template for new Team Projects?

I have sent an email to Conchango asking if they provide a utility to convert the Team Projects.  No reply from them.  I must admit, what I know of TFS templates, it is not a trivial task to convert Team Projects to a different template.

If anyone out there has any ideas, I am open to suggestions.