Sunday, December 18, 2011

Feature Branches: Making it Easy

In my previous post I wrote about the benefits of using feature branches for quality assurance. As with all tools features branches don’t come with benefits only. There are unwanted side effects. Fortunately there are ways to minimize or eliminate them.

One such area is creation of the branches. There are various factors to look at. For one your version control system (VCS) should make it easy to create branches. For some systems this is a no-brainer and for other VCS’s some more work may be required. Most of the teams I work with use Subversion or GIT, and branching is not an issue.

When creating a feature branch, the VCS is only one of the tools that is affected. You also need to consider the client side of the equation. For example, how easy is it to switch between branches? How often do you need to switch between branches? What does the support in the VCS client look like? Do you need integration of your VCS client into the integrated development environment (IDE) your team is using? By choosing an appropriate VCS introducing feature branches becomes much easier.

Apart from the VCS other systems your development team is using may be affected as well when branches are created, whether they are feature branches or others. For example you may be using a continuous integration (CI) system such as TeamCity, Jenkins or CruiseControl.NET. Once the new branch has been created you want to make sure it is picked up by the CI system as well and automatically built. Therefore each time you create a branch you typically want to set up a new branch as well.

You may have other systems that may need to reflect that a new branch has been created. For example a bug tracking system may offer the branch name as the affected version when entering a bug. Or you may use a tool to plan and track progress for a particular feature. Again this would then be set up accordingly when a new branch is created.

As these activities will have to be done each time a feature branch is created, it is an obvious candidate for automation in particular if your team works on dozens or hundreds of features each year. With appropriate APIs of affected systems automation is not an overly complex task. Instead it is just a matter of putting the time in.

In closing I’d like to give you a specific example from one of the teams I am working with. Creating feature branches is completely automated in this case and the time required is only as long as it takes to type in the name of the features branch. The remainder is automated. This includes the creation of the feature branch in the VCS, setting up the new build configuration in the CI, creating the feature as a project in the project tracking system, adding a configuration to the test bed controller and setting up automated merging. Taken together it typically takes about 10 seconds and is saving hundreds of hours of development time per year.

In one of the next posts I’ll describe techniques that help making the merge of feature branches into the main development branch easier.

Monday, December 05, 2011

Feature Branches and Quality Assurance

An almost “classic” way of managing branches is to have a main branch into which all development work is committed. When a release is prepared a release branch is created. Quality assurance (QA), including testing and bug fixing, is done on that release branch. Any code changes are usually propagated to the main branch.

When introducing feature branches the question is whether you would still do all the quality assurance work on that release branch. You can, but in my experience there are better options available to you.

With the “classic” setup you also often see teams putting a lot of quality assurance work into the release branch. This tends to increase significantly the time from when you create the branch to when you release the software. This can lead to spikes in the QA workload. For example if you have planned 4 weeks for release management (QA plus other items required for release) and you are on a quarterly release cycle, every 3rd month typically has a higher workload for the team taking care of the release.

Therefore it might make sense to look for better ways to level the release management work. Feature branches give you additional options.

Since content wise a feature branch is your main development branch plus only one feature, some quality assurance efforts can take place in the feature branch and focus on that particular feature without having to worry about changes that may be in progress in other branches. Also, all QA efforts can start as soon as the first story has been completed on the feature branch. In this case “QA efforts” doesn’t mean that quality is tested into the product. Instead it means that certain tests, e.g. platform, installation and upgrade tests can be run very early in the project. Equally you can start with usability and performance testing very early, too. Quality assurance may also include feedback sessions with customers. By using prototype version from the feature branch, those sessions gain focus as well.

The general idea is to move in as many work items as possible from the release management process and to move as many items from the release branch to the feature branches. With this approach the time between creating a release branch and shipping the software can be shortened extremely, more in the range of hours or days. Since more options exists for quality assurance work, this also reduces or avoids altogether spikes in the QA workload of the development team.

There is one other item that requires consideration. Even despite all efforts in the feature branch you cannot guarantee that the system is not broken when the branch is merged back into the main development branch. You will want to have some integration tests in place to speed up that verification process.

In summary you are distributing the release management work across three places. Firstly you put as many of these items into the feature branches as you can. Second, you need integration testing for when the feature branches are merged. And you keep only the unavoidable release management task in the release branch that you cannot reasonably do in the release management branch.

In a future post I will discuss another technique for what you can do to reduce the effort and risk for merging a feature branch back into the main development branch.

Monday, November 28, 2011

Reducing Schedule Risks: Feature Branches

Software development projects are subject to a number of risks. One of these risks is schedule risk. By this I mean that you may not be able to ship on time because of some nasty discovery while executing the project.

Of course you don’t know what you don’t know. You cannot foresee what you will discover as you work through the project plan (or backlog). No matter how much effort you put in planning your project, breaking down the stories, even running some spikes, you will find that you cannot totally eliminate surprises that add to your workload.

Although we cannot totally eliminate that risk there are techniques that help with mitigating it. Firstly you can build in an allowance for discovery into your plans. Some people would call it a buffer.

A different option is to break your deliverable into multiple features. Often you will observe that most of the features are completed within the deadline while a small number may overrun. You will run into a problem, though, if you are using a single branch in the version control system (VCS) for your work. Your only option will be to deliver late once all features are complete.

Therefore a different approach is using feature branches. For each feature that you have scheduled you create a separate branch. Once the feature is complete you merge it back into your main branch, e.g. ‘trunk’ in Subversion. As you approach the deadline, e.g. the release date, you now have options. You can either ship with just the features that are complete or you wait until some or all of the remaining features are complete as well.

Of course this changes the scope of the release. However, if the features are worked on in their priority you may be able to ship the more important features even early or at least on time. This is sometimes a viable alternative to not shipping at all.

In the teams that I have worked with this approach is working quite well. There are a few more aspects to this but I’ll cover these in a future post.

Tuesday, November 15, 2011

Measuring Productivity of Software Engineering

Not too long ago I had a conversation with a friend and we discussed productivity in software engineering. In particular we got hung up on the question how to measure it.

It’s not that nobody had ever tried to measure it. I have probably about 30 to 40 books just on metrics alone. So far, however, I haven’t found a method that would meet my requirements. Let me explain.

Let’s assume you have a team that is working frantically and has a high productivity. Let’s further assume that you had a metric that can measure the productivity reliably. At some point the team ships the new system, not only on time but with a record breaking productivity maybe even ahead of time.

Enter the customer or even better the actual user. They sit in front of your brand new system. The initial comment: “This is not what I wanted. I don’t need a system for making hotel reservations I need a system that helps me control my production plan.” (OK, not a real case but I have to protect the innocent and I think it makes the point.)

In this scenario, what good is it if you have the best productivity on the planet if as a result you deliver the wrong features? Wouldn’t this indicate that in the end it is the customer who judges whether they get enough value for money? And wouldn’t that be a good metric for productivity? In this case, because the wrong system was delivered the “productivity” in terms of features with business value was zero. At least from this customers perspective.

In the discussion with my friend we really go stuck at some point. We had already agreed that counting lines of code (LOC) doesn’t help, or counting the number of classes, methods, function points, statements, screens, etc. Equally counting the hours doesn’t work.

My friend and I agreed on all of this. We couldn’t find a metric that we believed would work. Then I asked him how he measures productivity and his answer was: “gut feeling”. I’m not quite sure about his answer.

As for me I have decided that if several customers tell me that they believe they get good value for their money, e.g. for their maintenance fees, then I take that as a sign for a good productivity. Productivity measured as in business value perceived by the customer. Does that mean we now lean back and have a good time? No. We still use a continuous improvement process within our team to find even better ways of working, even more waste we can eliminate. And we continue to have a good time on top of the hard work!

Saturday, November 05, 2011

Small Commits

Again and again I see example of why it pays off to have small commits. By that I mean something very practical, namely a commit to a version control system.

As I work through a story I don’t implement the entire story in one go. Instead I look for even smaller steps, ideally using tests to drive the development.

When I say small I mean more on the scale of every few minutes rather than maybe a couple times per day.

If something doesn’t work correctly I have only a very small number of places where to look for what is wrong. Most issues I find by just looking at the code changes. This works even better when I work with a programming partner.

As I find most issues by just looking at source code only rarely I need a debugger let alone stepping through vast amounts of code. This, too, is a time saver.

And in case I stuffed up the code completely I don’t lose much work, maybe just a few minutes, and I pull out all my code changes. Then I start from where I was just at the last commit. I continue from a known position.

The principle at work is small increments. This also applies to roadmaps, budget spreadsheets and other items. Just give it a try!

My recommendation: With commits you can’t err on the too small side!

Friday, October 28, 2011

Man Days

Today I overheard a conversation which I would like to share with you:

Anna (Consultant): “Can you confirm that you mean 30 man days, meaning 6 work weeks?”

Susan (Developer): “Confirmed – 30 woman days.”

Wednesday, August 03, 2011

Long Methods

How do you know in any programming language that a method or function that you implemented is too long?

Answer: You know when you use normal font size and have to scroll up and down despite having a 30-inch screen.

Recommendation: If you have to scroll vertically or horizontally on a 30-inch screen you definitely should consider refactoring this function or method.

Tuesday, July 26, 2011

Task Switching

Somewhere I read that task switching is one of the biggest time killers for your daily work. For example if you have your team working on many different items in parallel and you expect them to devote at least some time to each item each day task switching can become a huge waste of time. Apparently it takes the human brain about 15 to 30 minutes to become completely immersed into a new topic.

This certainly does not apply to somebody selling movie tickets. No disrespect, selling movie tickets is important. I love watching movies!

Switching between task has a bigger impact on knowledge workers and certainly on people developing software.

About two months ago I assessed the work distribution in my team. I want to find out whether task switching was an issue and if so what could be changed to reduce it.

In our particular case we found that almost all members of our team were switching between fixing bugs and working on improvements. At the same time everybody was also expected to answer the phone and mails, participate in forum discussions and provide second level support. Bottom line: A lot of task switching went on.

So what did we do about this? We split up our team into two teams and assigned each with a subset of the above activities. At the moment we are still experimenting which activities should be assigned to which team.

A little more than one month has passed since we implemented the change. The initial observations are encouraging. One team has been assigned the items that we believe can be best planned using iterations as time boxes. The other team is working on the items that are better managed using a kanban system. Both teams are now in a much better position in terms of reducing task switching. Transparency has significantly increased as we are now using planning and tracking tools that are better suited to the type of tasks assigned to each of the teams.

I’d like to encourage you as an agile leader to go and look for yourself and assess how much task switching is going on in your team. Chances are you find a an easy way to improve the performance of your team.

Monday, June 13, 2011

Email Junkies

In my last blog I wrote about smartphone junkies. I’ve discovered another species recently: “Email junkies”. Let me explain.

Last week I got a phone call and the person at the other end asked me a question and when I said that I don’t know what he was talking about he then asked whether I hadn’t seen the email he had sent 20 minutes earlier.

I don’t know about you but I’m not sure whether I see value in spending my day starting at my email inbox. Sure I love hearing from people but then if it is really important they can reach me via text or give me a phone call right away.

In my team I typically give the advice to check email only once in the morning and once in the afternoon. Or check it three times a day if you must.

At all other times it probably is the best to close the email client completely. Then it won’t even show those small little pop-ups at the lower right corner of your screen, which are another popular distraction.

If you want to focus on more important things then make wise choice as to when and how often you check your email. It can be a big time saver.

Equally if you send me an email don’t feel offended if I don’t read it and respond to it within a few minutes!

Thursday, March 03, 2011

Smartphone Junkies

Ever been in a meeting and a smartphone goes off? Sounds familiar? It's amazing what smart phones can do these days in particular how you can stay connected all the time, be it email, SMS, twitter, Facebook, you name it. Cleverly used these devices can support collaboration and keep feedback loops short.

Some rules are common sense in the meantime. Switch at least the sound off. In some cases it might be useful to even switch off vibration as it can still distract if the smartphone is just sitting on the table and then starts hopping around. And even if both are switched off, some people are so addicted to checking every five minutes whether there is a new message that it could become a distraction even in short meetings like a daily scrum.

So, in my experience the best option is not bringing these devices to meetings in the first place. A different option could be a tray close to the door where people could then just put their phones during the meeting and pick them up again afterwards.

Bottom line: It's not the phone that is smart. It's the person using it cleverly!

Monday, February 21, 2011

All About Agile

I just added another entry to the “Interesting Links” section. There are quite a few sites about agile approaches in particular for software development. Kelly Waters has put a lot of effort in her site – “All About Agile” - over the last view years and I find the material and links to further information very valuable. Have a look and I’m sure you will find nuggets, too.

Hostgator promo code