Agile Development – Is it for you?

A short answer to a very broad question – Yes.  For a more in depth answer keep reading.

Defining Agile

If you are in the software development world you have no doubt heard the term “agile” thrown around as much as any other word over the past few years.  But what exactly is agile? Does agile mean the same thing to you as it does to me or anyone else?  The chances are probably not.

I have been in a few different industries besides software development and can tell you that each one is different with it’s own set of rules and practices.  One thing that is common between all of them is how to get more value out of an existing set of resources.  So how is this done?  Other terms come to mind here such as Lean and Six Sigma.  Improving existing processes and re-engineering obsolete processes are a must to keep growing.  In software development this is no different and this is where the term “agile” comes in to play. 

Methodology Choices

Agile is a broad term that describes a movement.  Terms like Scrum and XP are specific implementations of this movement.  Each implementation has it’s own set of practices such as TDD, BDD, Stand Ups (scrums), sprints, etc. So the next question is which one do you follow? This is where the confusion comes into play. 

The purists / elitists would have you believe that if you don’t adopt every process / best practice of the methodology then you are doomed to fail.  This is naive and closed minded in my opinion.  If you follow every process to the letter and don’t attempt to improvise or improve the processes then how can we be expected to continue to improve as an industry?  At some point each group would plateau. 

Each process out there fits some teams better than others since each team is different.  Each team has it’s own dynamics that are unique.  So how can one be expected to apply the same business model to every team?  I would say it’s not possible.  What is possible however is to take the best practices from any implementation / methodology that suits your team best and apply it to your team’s processes. 

Test Driven Development

An example of a specific methodology would be Test Driven Development (TDD).  There are many people in the agile community that swear by this concept.  There are just as many that do not believe in it.  I am somewhere in the middle.  I believe testing your code at the unit level is imperative.  Having a high level of test coverage on your code is not a bad thing.  However – we do live in a world where in the end you have to deliver software.  There is a delicate balance between writing production code and test code.  Writing tests for the sake of writing tests however seems wasteful.    A good article on this concept can be found here. 

There are many that believe TDD is the Holy Grail when it comes to quality and software development.  Again I think this is naive.  TDD is a tool that can help you achieve a higher level of quality in the code you write.  However, the code will NEVER be better than the person who wrote it.  If the developer “didn’t consider that scenario” or “didn’t realize the implications” of a feature or technology then the code can be just as buggy or more so than someone who didn’t write it using TDD.  TDD should NOT be used as a crutch to say “hey look at my code – it’s great code because I wrote it TDD”. 

Summary

So based on the above how can we define agile?  A few key concepts come to mind:

• Ability to adapt to change (both at a team and organization level)
• Providing high quality / easily maintainable code at an acceptable pace
• Consistently improving existing processes

Each one of us can choose to become more agile in our daily processes through development practices.  But to do so at a team or organizational level you must be willing to adopt change.  See my post here about what prevents a team from adopting change. 

One other thing to keep in mind and this is where I differ from most of the elitists.  You do NOT have to adopt EVERY methodology to become a better organization.  You can choose what fits your team and apply it.  This does not mean you are doomed to fail.  It means that you are willing to accept that your team must change and you are starting the process to implement that change. 

What does it mean to be a “True” Team Member?

Most of us have been part of a team at one point or another in our lives.  This could have been a sports team, academic team, or team in the business world.  But were we really a “true” member of the team?  When I say “true” member of the team I think of many traits but the following move to the top of the list:

• Respect
• Trust
• Loyalty

Each trait above cannot be had without the others.  They are intertwined and built within the interpersonal relationships that each team member builds with the other members.

Respect

Respect is a two way street.  People usually start out with a certain level of respect for others.  This respect is built up over time through interactions with others.  In order to earn respect of your peers you must give respect and be considerate and compassionate towards others.  Remember you can respect someone and still not like them personally.

Trust

Trust in your team is vital to be successful.  If you don’t trust the team members you work with then you will have a hard time being a productive team.  If those around you don’t trust you – then there is a good chance you will be alienated at some point, if it hasn’t occurred already.  It takes a long time to build up trust in others but only a few seconds to lose it all.

Loyalty

Being loyal to your team is vital to gain “trust” and “respect” from your team members.  Actions demonstrate loyalty – not words.  Below are some items I consider to be actions from a loyal team member

• Helping other team members when possible.  This includes training, teaching, and at the minimum – moral support.
• Not tearing down other’s attempts at new things – you must be supportive.  It is okay to provide constructive criticism to others when needed.  It is not okay to belittle their work when the motivation is not to genuinely help them improve.
• Always maintain a positive attitude towards other team members even in high stress moments
• NOT condoning actions that are detrimental to the team.  This means if you see something that can have a major negative impact on the team – you speak up to protect the team – not the individual.  This should only be done as a last resort.
• Keeping interpersonal issues within the team when healthy to do so and addressing as needed.

So the next question is what do you do if you find yourself sitting outside the team’s inner circle?  How do you go from being alienated to being a contributing and respected member of the team?

The short answer is I don’t know if it’s possible.

In more detail I would say that it would require a fundamental change.

Step 1 – Identify the cause

Is the problem yourself or the group of people you are working with?  I would say most of the time it is the individual.  So assuming that is the case – why were you alienated in the first place?

Did you not get along with another team member?

Was there an incident that led to friction between you and the team?

Has anyone approached you about this situation?  More than one?

If you can answer yes to any of the questions above then the best chance answer is you were the cause.  But there is good news – you might be able to change it if you aren’t too far out there.

Step 2 – Makes some changes

There is a popular phrase out there “Change your organization – or Change your organization”.

I have a similar one for this situation -   “Change your ways or plan on Changing your organization”.

If you were able to identify the cause in Step 1 and have come to the conclusion it is not you – then there is a good chance there is nothing you can do to fix your status with the team.  I am not saying it isn’t worth a try – but the the probability is you are part of the problem and not willing to admit it – so you might as well start looking as you are not really ready to fix the root cause of the issue.  Happy job hunting.

For those who realized there are things that they could have done better – here is where you start.

Pull Your Own Weight

One of the most critical things a team member can do is pull your own weight.  Make sure that your contribution to the team is above and beyond for what you are tasked with.  Whatever you do – do not pat yourself on the back though.  This will be frowned upon no matter how good of a job you do.  Let others take notice in your improvement.

Do not attempt to take on too much

Attempting to do too much may imply that you are trying to “buy” your way back in to the team through additional work.  This is a fine line between pulling your weight and trying to do it all that you really do not want to cross.

Build Relationships backup slowly

Any attempt to be too friendly too quick will most likely be met with resistance.  Most people are forgiving by nature and time heals most wounds.  If you are at odds with someone and come in Monday morning and ask about their family there is a good chance this interaction will be viewed as non-genuine.  Over time you can build those relationships back up to an acceptable level.

Step 3 – Maintain your changes

I have seen this before in others.  A person will go through and make the changes necessary to reduce the friction but will be right back to the “old ways” a few months later.  Personal communication and interaction with others can be a difficult task for some.  Always ask yourself if you are treating others as you would like to be treated.  I know this is the golden rule – but it is called that for a reason.  Respect it and abide by it.  It really does make personal interactions better.

I personally have been on both sides of this fence.  Early in my career when I was still naive and for lack of a better term “stupid” I did alienate my self from a team.  It was not a good feeling at all.  What was worse is I was not able to repair it.  I moved on to a different company and made a vow to myself never to get into that situation again.  I continue to this day to try and improve my interactions with others.  It is something I will always strive to do better with.

I am hoping that the information above will help at least one person who reads it. If that is the case then this post was most definitely worth it.

Developer Testing

During my tenure in the software industry one of the biggest challenges that I have seen from a development team was when was it time to pass the story from the developer to the tester.  Having come up through the software industry via a background in hardware, support, testing, and now development this answer is obvious to me.  However, from experience, quite a few developers tend to release the feature(story for the agile folks) to QA prematurely. 

Depending on what type of system you are doing (Agile, Waterfall, etc) I think it’s important for any developer to thoroughly test the feature up to the point where it is not practical any longer.  I will use the example below to demonstrate my point.

 

Step 1 – Developer gets the specs / requirements (no laughs here) for the feature

Step 2 – Developer implements the code changes

Step 3 – Developer ensures code changes are functioning as expected

Step 4 – Tester tests the changes in a testing / staging environment and notifies developers of any bugs

Step 5 – After all bugs are fixed and tester passes the feature

Step 6 – Customer / Business accepts the changes (UAT)

There are many philosophies and ideas surrounding these steps (especially 2 and 3) on how this should be carried out.  There are many proponents (and opponents) to methodologies such as TDD, BDD, etc.  I feel that regardless of the methodology chosen that the following should be completed by the developer prior to moving to Step 4.

• Each main code path has a unit test to verify the functions are working as expected
• Main integration tests are carried out on the section
• The feature has been walked through / exercised by the developer through the UI *
• If there are multiple data storage options – each one is tested **

* Note that this is not always feasible and goes back to my point above about being practical or not.  This does not have to be done through an official installation – but should be done via the development environment.

** Sometimes the team assignments dictate this is the responsibility of someone other than the developer – in these instances the value of the developer performing the test should be measured on a case by case basis. 

Too many times have I seen developers rush through the coding process and not pay attention to Step 3.  The mentality is “Throw it over the wall and let QA (testers) find the bugs and I will fix them”.  I do not agree with this mentality.  Too many times this practice leads to extra effort being put in to the same process.  This reminds me of the old phrase – “If it’s worth doing – it’s worth doing right the first time”.  I know we are all under pressure and stress to get things accomplished – but sometimes when we pay closer attention to the details – the overall workflow process is improved and more work is accomplished.  The work in this case are features for the end user. 

Work – Life Balance

Work – Life balance is a concept that can be expressed in many ways.  When I first started working with a large company a few years ago this term was pushed on employees all the time while the application however was an after thought.  I see many people in the IT / Software industry who have put in many – many long days, weeks, and months.  There were times where I was putting in 18 + hour days to complete a project.  That was a year and a half ago….

After that project was complete I made a vow to myself to never do that to myself or my FAMILY again. There will always been occasional day where you have to put in overtime.  This should be the exception – not the norm.  Right after this occurred I started my courtship with programming (coding).  Up to this point I had done many things in the IT industry but most had to do with “maintenance” type fields such as network engineer, PC technician, and Software Testing / Support.  Programming was different – this was an art.  I was able to create things from nothing.  I was entranced. 

So how did I keep my promise to myself?  First, I scaled back the time I spent at work to a normal 40 hour work week.  Some weeks crept up to 45 here and there – but never above that.  Second, I began to spend more time with the family and slowly bring the fire back in to a marriage of 9 years that had slowly started to fizzle.  I was lucky.  I realized just in the nick of time that I had put my career before my family. So the hard part now was how to keep the “loves” of my life happy.  I had my family and my job, my faith, and also my career.  The problem was my career needed some special attention to get to the next level (Software Developer). 

To achieve this I began studying the art of programming beginning with C#.  I spent as much time at night (after the wife and kids were in bed) reading, coding, and coding some more.  There were many nights were I was up until 3am in the morning only to be up at 6 am.  It really did help.  I was able to start writing successful programs at work that were useful to the team automating many manual tasks. 

Fast forward to today.  I no longer do the late nights any more.  I still am in love with programming as much now as I ever was.  But I have found a new love that trumps just about everything else.  I am in love with LIFE.  This love includes spending time with my kids, my friends, and my family.  It includes doing things for myself that don’t include anyone else in my life like playing tennis again.  I also found a new hobby in wood working.  I see a lot of similarities between wood working and programming as both are works of art.  I learned patience from programming that I will be able to apply to other areas in my life that I was never able to do before. 

There are some rules I have now that help me stay on track.

1. I am never on the PC while my kids are awake (unless they are on it with me)
2. I work 40 hours a week as much as possible
3. I do NOT under any circumstance bring my work (work projects) home with me any longer.  Note that I do not consider learning about programming work – even though that is what I do all day.
4. Whatever I am doing I force my self to stop and answer any questions either of my sons have
5. I make sure I show my wife EVERYDAY how much I love here
6. Thank God everyday for the blessing he has given me for which I do not deserve

If you are reading this post I ask you to remember what the true important things are in your life and hold them dear.

This post was inspired by a quote I came across tonight and was compelled to write about.

“Dream as if you’ll live forever. Live as if you’ll die today.” – James Dean

I’m too valuable – I can’t be replaced…..

This is a phrase we hear all to often in today’s business environment.  Many individuals feel they are irreplaceable.  Far too often they found out just the opposite.  It’s surprising when you look at teams where a “core” team member leaves and the team does just fine or in some cases better.  Did the team suffer when that person left – maybe.  Maybe not.  You usually can’t realize the full impact of someone leaving a team until they are gone.  Every team has a “bus number”, or number of people hit by a bus that would cause a team or product to come to a stand still if those members were lost.  Each team is different based on the size of the team and the specialization factor within a team.  By specialization factor I mean certain core areas of a product that a select few people truly understand and work on.  There are many reasons this occurs but some that come to mind quickly are (critical area, very complex stuff, and ownership). 

While I don’t believe you should let anyone work on any part of your application (widget effect) I do believe more than one or two people (based on size of team) should know all of the critical components in your product.  You should always have one or two backups.  This leads me to my next point – and the subject of this post.  Is there a such thing as being irreplaceable?  I believe in certain unique circumstances there are – but normally that is not the case.  If management allows the team to evolve into this scenario – then shame on them. 

My favorite saying is this – “Anyone can be replaced, it’s just a matter of how much and long of an inconvenience it is to replace that person”.  This “replacement factor” also includes experience / knowledge with the product / organization that you simply CANNOT buy on the open market.  So the next time you hear one of the following phrases (or think it yourself) then you might want to reconsider your stance on the subject.

“I can’t be replaced – this system is too complex”.

“It would cost them way too much to replace me”.

“I’m the backbone of this team”.