During a sprint a team has to remain focused on the goal. So often the team gets distracted from the goal. Some of the sources of distraction are as follows:

1. Other Projects
2. Personal issues
3. Lack of hardware
4. Lack of team synergy

Other Projects

These can range from pet project from a manager to the previous project a team member was working on. Also, there always seems to be an emergency project that needs to be worked on.  All of these affect the velocity of a team and may affect if the team is able to finish the user stories it has committed to. It is important that the ScrumMaster communicates to the management and product owner how much other projects are affecting the team and when they become major impediments. I my role as a ScrumMaster this has been the most prevalent issues I had to deal with. It is no fun when you have to tell a resource manager you report to that they are affecting the viability of a project.

Personal Problems

All of us face time when we have family issues or have physical problems that need attention. Unfortunately our jobs may be the cause of many of our problems. Our jobs cause stress that may affect our health and our families. It is important that we create a healthy work environment that does not cause excessive stress. Employees need to have time with their families and time for recreation to keep a healthy body. A good exercise routine leads to a more productive employee and less visit to the doctor. If we keep to a 40 hour work week we will have time to spend with our families.

Lack of hardware

It in uncalled for that companies invest in adequate hardware for their employees. Niceties such as dual large monitor, powerful laptops and large disk drives are cheep compared the cost of a employee. Necessary hardware should be available to the employee without having to go through excessive red tape. Also the supporting  build and testing environments should be setup and supported from the beginning. There is no excuse for the lack of good hardware.

Lack of team synergy

So often a team is a team in name only. So often the individuals are just working on their tasks and nothing else. If they finish early they will find something that interests them to do and not even consider what other task they can work on.

In a productive team the members learn how to leverage each others strengths. They work together for a single purpose. There is no individual recognition. We as a team work together toward the goal of finishing the sprint goals. Each member makes sure they do their part by taking on available tasks.

Agile methodologies support best software practices. One of these practices is that working together as a team is more productive then individual contributors to a project. But it is easy for a team to be demotivated.

We all start out being motivated. We like the work we do and we want to do a good job. So what happens? It is the situation we work in that demotivates. This includes the stress and company culture. This quote is from “Agile Coaching”:

These are factors that demotivate people if they are not present, even though these factors are not motivators when they are present. For instance, fast computers, decent coffee and fair pay won’t be noticed if they are there, but their absence can demotivate employees.

It important to be aware of what may be demotivating a team.

We often look at Agile adoption from an organization level but what about adoption at a personal level> What does it mean for you as a developer to adopt Agile methodologies.

Let’s start with your own developement practices. What do you value as a developer? How have you improved your development practices over the last year?

Here are some practices that an Agile developer should adopt:

1. Test Driven Development.
   This is more then just writing unit test, it is having the unit test drive your development.
2. Code refactoring
   Do you leave the code you work on more readable and easier to understand?
3. Code ownership
   Do you take responsibility for what you do?

I am sure you can add to the list. The point is are you constantly trying to improve the way you develop software.

How often do we go about our jobs and have not real passion about what we do? When an friends asks what you do for a living what do you tell them? Do you say I work for company XYZ or I am a C/C++ programmers (or what ever you current skill is)?

Is there a skill you can teach others because you really believe they would benefit from learning the skill? Do others recognize an underlying passion to make your work place better or the world better around you?

So much about agile is about be passionate first about improving your own skills and the improving the skills of those you work with. Be passionate about improving!

This morning I had a very interesting discussion about the culture at the company I work for. We as developers have been instructed to use a testing tool that our QA group uses. This is all well and good because the tool is based on JUnit and is XML driven. The problem is that the tool is only supported in the QA testing environments. The tools cannot be used in the regular development environment. So if developers do use the tool for tests it will have to be for QA regression testing and cannot be used in a test driven development (TDD) style.

This is very frustrating because TDD is the proven way to create quality software. Also, developers are going to resist using tools that do not enhance their job and the quality of their software. Who wants to add more time to an already tight schedule to develop test that one cannot use.

I was informed that our culture does not value testing by the developers. Oh, there have been directives that all new code will be unit tested but because good tools have not been provided this type of testing is spotty at best.

To do our job efficiently and produce top quality code we need to have environments that support us not hinder us.

It is interesting to see how resource managers like to micromanage the task list. It seems that when a task list is defined for a story that it is etched in stone. Let’s face it, none of us can plan ahead 24 hours let alone for a two week sprint. We have a general idea and a goal we are striving toward. The tasks give a road map to get there, but there may be many detours along the way.

I have been learning much about introducing Agile methodologies into a large organization. Many times it has seem almost hopeless. But I took a different approach over the last several months. I decided to really make the team I am working with the most productive team in our company.

Well we have gone through two major product releases and the team is really coming together. They have learned to work together and leverage each other strengths.

One thing I am learning it to look for the little changes in Agile adoption. Over the months these little changes accumulate and make for some very significant changes in an organization.

In Agile we value the developers as people with unique skills and interests. That is why one of the key concepts in Agile is:

People over process

In large development groups it seems that the software developers are treated a replaceable cogs in a development organization. I was again reminded of this by a fellow developer. He wish he had never been put on a given project. The reason he was put on it was because he was available. It was a one person project that was way under-scoped.

We are community beings. Having a sense community makes us more productive. Grouping engineers in self organized teams is the ideal way to use resources. You can assign projects to teams who will focus on getting the job done.