Agile Development ... choosing THE methodology

Agile development is a trendy subject for quite some time, there are lots of discussions around it and even more around it's implementing methodologies (Scrum, XP ...).
What I can see so far there is not an easy task choosing the appropriate development methodology, and thus tons of "ink" are used to argue around THE methodology.
All agile implementations have a set of practices and many of them are common, but in order to have "something else" a distinctive note is added to justify the name and then we start debating ... and we looove debating.
So I ask myself is there any chance to find a methodology that would answer all the needs of a strong development process? So far the answer is NO and I think we do a lot of "beat around the bush" instead of focusing on a particular process context needs and try to make that work with a set of practices that make sense.
However the sense making part is not an easy one because not all people share the same principles nor have the same focus but again I think the process context should drive.

Spooky windows and his registry

If you prefer Explorer to not open new windows every time you click on a folder, I found you need to do this, using Regedit. Back up the registry first of course.

1. Start-->Run-->Regedit

2. Go to HKEY_CLASSES_ROOT\Directory\Shell

3. double-click on '(Default)'. Where it says 'Value Data', type exactly the following line:
C:\WINDOWS\explorer.exe "%1"

Close Regedit. Obviously you need the right basic settings in the folder options-->file types of Explorer, this is assuming you did all that and nothing else worked. HTH.

I found this on: http://www.annoyances.org/exec/forum/winxp/1108647242
Many thank to original author.

The business of managing human resources

Most of the companies have the main focus on producing goods or providing services with available resources.

The scenario is something like this:

• recruitment - bring a resource inside - a resource that has a list of mandatory skills
  
• initial training - ensure minimum of training so that the resource can be integrated into a development team (the soon he starts practicing the better)
  
• performance management - ensure that the resource is up to date with job required skills and is happy with his evolution (professional end financial)
  

I believe things will need to change a bit in the future because of human evolutionary nature and the business opportunity.

What is actually happening with previous scenario:

• you don't always get what you need from a resource (not enough experience, not enough skills)
  
• people want more and is normal, this is the evolution's main drive
  
• companies don't always want to invest more because it doesn't serve their purpose
• people seek for places that would eventually satisfy their needs
• they leave the boat opening the path for a replacer
• and the process goes on and on
  

The business opportunity is explained in the following approach:

• recruitment - bring a resource in
  
• initial training - ensure as much training as he needs to start practicing
• performance management - ensure training to achieve excellence and state the upper excellence limit that makes sense to your business. If the resource achieves maximum on skills needed by the company and wants more, the company should facilitate (trade) transfer to another company that has a suitable position

Who wins here?

• the recruiter can better evaluate the new employee for his references and previous position
• the employee is in a continuous evolution and his performance will always grow
  
• the company that trades the employee will better manage it's resources by being aware and facilitating the exits
• the companies will better reshape their profile, turning focus in what they are best on (delivering goods or services or delivering professionals)
  
• the business and technological environment will standardize, share and faster evolve
  

The value of a development team

Although we don't always like to hear this the average value of a development team is directly proportional with the quality of the product they create.
How do we measure the quality is a long discussion I am not going to open in this article but among the base components we can mention:

• the compliance with specifications

• the number of bugs summon after release

• the flexibility and scalability of the product

Achieving quality is a matter of pragmatism, responsibility, maturity, openness, feedback.

There is no perfect plan but a good enough plan is better than no plan

Lots of releases are delayed, postponed or even canceled just before going live because at a certain moment the planning is treated more like a guideline and people start acting like a herd of cats. We do what we feel that is important loosing the focus on the key values and the project is starting to behave like a car with lots of drivers each one spinning his wheel.
Is true that not only planning ensures a successful release, all the activities in the pre-release do matter, but planning is the base brick, if we make it weak then the project has big chances to fall apart.
So when do we to start planning? I'd say that we can start planning when a clear image of a functionality that would bring value to the project exists.
How to build a healthy plan? I believe that breaking it in small independent components, easy to track, will make our task easier.
Is important to know for each component of a system:

• how much time will it take to build?


• what resources are needed and how much will they cost in relation with the value of the component?


• how will it interact with the rest of the system?


• is it a critical component?


• can it be and does it worth to build a prototype? can the prototype be tested? etc.

The answers to these questions will build the plan, actually a set of small plans ... but this is only the preparation phase before hitting the road.
Next we will have to track the plans and ensure they are followed. If the plan for a component cannot be followed we should make a step back and see why is it happening and take some actions ... adapt it or leave it. We should also acknowledge the reasons and learn from mistakes.

Unit Testing saves time

There is a big misunderstanding about Unit Testing in some environments, and this is that development stage takes longer when Unit tests are written, and this what I'd like to argue in this article about.
As a developer each one of us must test his written code otherwise how would one now it is done, so he is starting the server (or the GUI or the batches or anything he created) and starts clicking around to see how it works. This will not be started only once in the entire development time frame but several times and the developer will try to prove himself that he did a good job.
All this need of confirmation that one is on the right path costs time, and costs much more time than writing a set of tests that will made the checks automatically in a more accurate manner.
It costs time when developing the very task and costs even more time when the functionality is integrated or aggregated with other parts of the application ... there we have to start testing again to see if integration was clean or bloody.
And this is not all ... it will cost very expensive time when the bug is spotted in release downs, because the functionality will no longer be fresh in developers mind and he'll have to dig in order to find what the heck was in his mind when he wrote the code.

As a conclusion I think that development driven by tests taking more time than free tests development is a myth that is summon either by lazy developers either by lazy developers who became managers.

A good way to start your day

Erik Mongrain - Airtap