Speed, it's all about speed!

In a previous post, I compared Agile methodologies with evolution in nature (Agile, Chaos and Evolution). There I compare the fitness of and organism with the amount of working software the team can deliver in an iteration. Increasing the amount of software delivered (I will call it velocity from now on) is equivalent to increasing life expectancy in nature.

This means velocity is critical for today's Software Development. If you want to last longer, you need to increase your velocity. The team needs to do everything they can to improve it.

Increasing the velocity, many times turns into a problem, rather than a solution. Instead of finding better and faster ways to do things, they just aim to cut what doesn't seem important, and you end up with thousands lines of code in production without any testing, documentation or even logic. That would be like trying to go faster with all your wheels flat. It might seem you go faster in the beginning, but you are putting in risk everybody on the car if the trip is long.

I will go over some concepts and show you some ways to improve your velocity without putting any life in risk. 

Closest Train Station

Imagine somebody asks you to take him to the train station. You can take him to any of the station of a particular train line. You will just look the closest one and take him there. You would never take him to the train station on the other side of the country! When you are doing software development, you are taking your customers to a train station. You need to find the closest one and go there. If you take them to the station on the other side of the country, you will waste a lot of work and time doing the train job. You need to take your customers to a point where they can keep going without you taking them all the way.

In this case, you are not affecting your speed, but you are traveling less distance, which in the end, achieves the same goal. You need to minimize the distance you have to take your customers. This is the equivalent of "the art of maximizing the amount of work not done" in the agile manifesto. The more things you don't do, the faster the customers get where they want.

Minimize Work in Progress

Work in progress are the tasks you are working at the same time. Any task you started working on and it's not yet used in production is considered work in progress. Having more WIP affects your velocity an quality. Another way to say the same to make it more generic is if "you have to still think or manage that story". Everybody on the team, will have to manage WIP, and waste time on it. If you do not manage it well, your quality and speed will decrease considerably. Also, it prevents people from being focused.

Once you finished working on a task, get it to the users as soon as possible, and stop thinking about it. This is in particular important, when you don't have automated regression tests and a good testing environment. Good testing policy could back up your work done 2 or 6 months later when the users get it.

WIP affects you not only by having to manage it, but also because it implies context switching. Context switching is a great source of bugs, and it reduces a lot your speed. You can easily verify this, with a simple and known exercise.

Prepare 4 pieces of paper and a stopwatch. With the first two pieces of paper write numbers in one and letters in the other one at the same time. Write a "1" in the first paper, and an "A" in the second all the way up to "10" and the letter "J". Measure the time it took you to complete it.
Then, with the other two pieces of paper, grab the first one and write numbers from 1 to 10, then the second and write letters from A to J, and again take the time it took you. You will clearly realize how context switching affects your speed and quality. As an example, it took me 29.82 secs to do the first part and only 16.23 sec the second part. It had also better quality, because I didn't have to rethink the letters every time I was writing them
You can imagine  context switching will be harder with complex development tasks. There will be more bugs because your context will not change completely and it will be harder to maintain it in your brain.

I think reducing WIP, increases your quality and velocity. I understand this it not easy, as there is always too many things to do, and they have to be done yesterday. But as I just showed you, doing all those things at the same time, will make you work more, think more and it will still take you longer. You will also do it with less quality.

Increase Quality to increase reusability and reduce rework
Lately, technology has been going really fast, allowing you to reuse almost any application you have and combine it with others to increase your flexibility and productivity. The only way to achieve this, is by building applications on top of other applications.

I could verify with many years of doing really large development projects, anything you didn't do a year ago, will take you two or three times the effort to correct it today. I will not also take you longer, but it will also have a great amount of bugs. All this because it was poorly requested, poorly developed, poorly tested, and poorly documented, so all the assumptions done a year or two ago to make it work will be lost.

Investing on doing the right thing, and doing it right in software development is the only way you will be able to build things on top of your application. If you don't do the right thing, you will spend a lot of time changing and fixing it, and probably throwing away a lot of what has already been done. This will not allow you to have the time to build something else on top of it.
If you don't do it right, you end with something complex, full of bugs, no documentation, no tests, no knowledge to allow you to build on top of it either. Both cases imply a lot of rework. Reducing rework translates in to doing less and reusing more. The only way to reduce rework is by making quality a pillar of your process.

Conclusions

Increasing your velocity is the only way to last longer on IT. Still, this doesn't mean doing it recklessly. Even an old lady can push the accelerator pedal to the bottom and go up to 150 miles, but I wouldn't like being on the car when it happens. You have to do like race drivers and practice all the time trying to do the perfect turn. Only trying to make it better you will be able to go faster. It will not happen on your first iteration, or the second. First try to get to a stable point, where you are doing the right thing right. Then practice will allow you to go faster and see better ways to do things. If you just stop doing important pieces to go faster, you only foolish yourself.