On Agile Leadership

Feature Branches: Making it Easy

2011-12-18T08:43:00.001+13:00

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.

Feature Branches and Quality Assurance

2011-12-05T11:27:00.001+13:00

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.

Reducing Schedule Risks: Feature Branches

2011-11-28T17:31:00.001+13:00

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.

Measuring Productivity of Software Engineering

2011-11-15T09:10:00.001+13:00

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!

Small Commits

2011-11-05T13:10:00.001+13:00

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!

Man Days

2011-10-28T15:39:00.001+13:00

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.”

Long Methods

2011-08-03T23:37:00.001+12:00

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.

Task Switching

2011-07-26T05:28:00.001+12:00

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.

Email Junkies

2011-06-13T19:39:00.001+12:00

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!

Smartphone Junkies

2011-03-03T07:46:00.000+13:00

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!

All About Agile

2011-02-21T16:49:00.001+13:00

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.

Improving Estimates

2010-03-16T06:57:00.000+13:00

An important capability of an agile team - in fact of any software development team - is estimating. Certainly you can break down any body of work into tiny bits, then estimate each tiny bit and total up the numbers to get an overall estimate of the entire body of work. But how small should you break it down?

When you use stories - or you may call them tasks or something similar - you can use a story as the unit which needs to get estimated. Initially it will be hard on the team. For example how would you estimate the size of a story if the estimators have different roles such as developer, business analyst, tester, user interface expert, performance engineer, etc. How can a developer assess what amount of effort is required by the user interface expert or the tester?

In reality they don't need to. With the initial set of stories all you need to do is agreeing on some relative sizing. These sizing will be in all likelihood completely off anyways. That fact of life should make this first step more relaxed. After the iteration is complete you look at how much you completed. Let's say you use NUTS as the unit for relative size. (NUTS = nebulous units of time, credits go to Darren Rowley from whom I learned this one.) Then you can look at the completed stories at the end of the iteration and see whether the initial estimate was correct. Was story 'xyz' really twice the size of story 'abc'? It doesn't have to be scientifically perfect. All that matters is that you give it your best shot and record the actuals.

By recording the initial estimates and the actuals you are already on your way to improving your estimates. Please keep in mind that generally estimates are provided by a cross-functional team rather than by individuals. And ideally the estimates are provided by the team that will do the work eventually.

By default you should sign up for stories that don't fit an iteration. If they are too large, break them into smaller pieces. At times, however, it can happen that a story is not complete at the end of the iteration and at the beginning of the next. One example could be that some capacity was left over towards the end of the iteration and work on an additional story was started.

If a story is incomplete at the end of the iteration (for whatever reason!) then the team should assess whether the size of the story is still good or whether it needs to be updated (either way!). If the estimate is changed then you should record the updated estimate as well. Why? The only reason to record the updated estimate is to allow for a proper capacity planning in the new iteration. You need to know the updated/current estimate and how much is left, so that the team doesn't over-commit but signs up to only as much work as they think they can accomplish.

So in effect, you are recording three numbers: The initial estimate, the updated estimate (history of this is not required), and the actual figure once the story is complete. The comparison of initial estimate and actual number allows you to measure how - as a team - you become better at estimating. The updated estimate is important for understanding how much work your team signed up for in a particular iteration.

If you like you can use a simple spreadsheet for recording these numbers. Make sure you add some dates for further analysis, e.g. how was the quality of estimates in quarter one compared to quarter two? A team is getting good at estimates if you use a mix of about 10 to 20 stories and the delta between the total of initial estimates and the total of actuals is less then 10%. I have worked with teams that got this figure to less than 5%, which is excellent. Always keep in mind that we are talking about estimates - we are trying to look into the future - and not about prediction.

A word of caution: Recording these numbers is important as a tool for the team. Stay away from the temptation of using it to measure the individual performance of a team member. Even if unintentional, as soon as any team member even just perceives it as a performance control mechanism, tracking the estimates and actuals is dead. The team must be able to update estimates without fear whether the fear is induced deliberately or accidentally.

Working with this tool - recording the estimates and actuals - and experimenting with it can lead to an extremely powerful tool. It doesn't increase the capacity of the team but it definitely will lead to much improved estimates and to better predictability of the deliverables of the team. And that in turn will lead to higher customer satisfaction. The spreadsheet I mentioned should not drive the team meeting. Instead it should just reflect the outcome for future reference. The team builds their body of completed stories that can serve as reference points for new stories for which a relative size is required.

Therefore: Experiment with this tool until it works for you. If it doesn't feel right chances are it is not working yet! Be courageous, try something, don't be disappointed if it doesn't work, try something else, then improve.

Good luck and have fun!

What to test in a web application?

2010-02-12T22:48:00.001+13:00

Sometimes I'm asked what to test, in particular when I explain that testing the happy day scenarios is not sufficient. For example in web applications I'd certainly expect that everything that has a link to a different page actually brings you to that other page.

Another example would be any kind of control for entering data, e.g. text boxes, radio buttons, drop down lists, check boxes, and more. Let's take a text box for a product number. The valid range might be a positive number that has 6 digits. In that case you would also want to test whether you can enter less or more digits. The system should have a defined behavior. Then try entering spaces, e.g. 2 digits, then a space, then 3 more digits. Test whether you can enter nothing. Test what happens if you enter a mix of digits and characters. I'm sure you can think of more depending on the system you are working on.

One less obvious case are routes. A route allows you to enter a link that the system can interpret and translate in a specific way into a url. Routes allow certain items to be bookmarked. For example: you may want to support a url such as "http://nirvana.org/Product/246337/View" (of course your domain name would be different). The concept here is that you have the domain class name first ("Product"), the specific instance id next ("246337") and the method ("View") last. In essence a route is then: "http://nirvana.org/Product/{productId}/View". Depending on the technology you use to implement this route, somewhere you will have to extract the product id and create a url to the page that can handle this request.

The point I want to make is this: A route like this needs to be treated like a method. In essence it is similar to a method and hence there are quite a few test cases. Some examples of test you should consider:

No product id: "http://nirvana.org/Product//View"
Non-numeric product id: "http://nirvana.org/Product/foo/View"
Negative product id: "http://nirvana.org/Product/-123456/View"
Product id too short: "http://nirvana.org/Product/12345/View"
Product id too long: "http://nirvana.org/Product/1234567/View"

And this is just a selection for this very basic example. I'm sure you can think of more tests. The point is, sometimes things like this are easily overlooked and as a result your system may contain defects that you are not aware of. In the case of a web application it means, that if you allow people to bookmark certain pages, be aware that people not only can but will enter invalid URLs! Be prepared!

Key Elements of Automated Tests

2010-01-30T11:12:00.005+13:00

This time I'm writing about an item that is admittedly very specific to software development. More than once when I spoke to a members of a development team I was told "yes, we have an automated test suite". And yet, further along the conversation it turned out that despite a significant test suite the resulting quality wasn't where all the efforts put into creating those tests indicated it should be. And in all these cases when we then took a closer look at the tests themselves it turned out that at least one key element was missing.

That begs the question: What makes up a good test? What key characteristics should a good test have?

Setup, Execute, Validate

The first key ingredient is that a test consists of three parts: The first parts sets up the data that is needed for the test. This could be restoring a particular database content, it can be setting up a few objects in your programming language, it can be launching a particular user interface (e.g. browser) and many more. The second part is the actual execution of the test. This means you invoke functionality that modifies data. In the final third party you validate whether you have the expected outcome, e.g. the actual data is equal to the expected one.

Occasionally I've found, though, that people forget about the third step. I don't have data but suspect that this happens when people come from a background where executing a piece of code without crashing is almost a success. Think early/mids 90s of last century. C and C++ were still very dominant in the PC industry. Exceptions in the midst of running a program were nothing completely out of the ordinary. (Maybe you are the only one who never experienced them?) However, we can do better. Just because it doesn't crash with a nasty null pointer exception doesn't mean it performs as expected. Therefore at the end of a test always validate the outcome! The typical tool for that are the various assertions that come as part of test tools.

Repeatable

Not strictly a requirement but there are quite a few scenarios where running the same test more than once reveals and thereafter prevents certain bootstrapping type issue from happening. Assume your service implementation does some sort of housekeeping upon startup. The first time you invoke an operation on the service everything is still fine. But then perhaps as you repeat the same test (or set of tests) using operations on that service things go off track. Maybe connections are not properly closed. Maybe the service cannot handle more than 10 open connections at a time (rightly or wrongly). By repeating the same test over and over again chances increase are that discover a hidden issue and resolve it before your product is shipped.

Random Order

Tests should not depend on each other. A test should not require a different test to run first. If they do changes to one test may trigger further changes to other tests in the suite thus making changes more expensive and time consuming. You don't want to lose time. You want to be fast.

For example, lets assume you are working on a system that has Project as a concept and the name of the project becomes a unique identifier for each project. If all tests use the same project name for their tests, then each test would have to check during setup whether the project already exists. If it doesn't it would create it. The alternative would be to use a generated name in each test such as a string with the value "ProjectName" + RandomNumberAsString(). That way you make the tests independent from each other.

A corollary to this is that you can run each test in isolation, meaning you can run just that test focusing on the specific task at hand. You don't have to run other tests first and you don't have to remember the sequence for those other tests. You can - and probably want - to run the entire suite anyways once you have finished the coding part of your task.

Fast Equals Cheap

Why do tests to be fast? To an engineer time is money. The longer a test or test suite needs to execute the less likely it is that people will run the suite or portions of it. It a suite runs takes 1 minute to complete you probably run it before each commit. If a suite takes 5 hours you won't run it before each commit. So keep them fast, for example work with the smallest possible dataset, avoid or mock costly operations like talking to remote systems, databases, filesystems, anything that requires mechanical parts to move. Use in-memory databases (e.g. SQLite) instead of client-server systems such as Microsoft SQL Server or Oracle.

You may also want to continuously refactor your tests as well. Keep them lean and mean. Split the test suites into the ones you definitely want to run each time before you commit and those that are more expensive in terms of duration. Platform tests or scalability tests fall into the latter category.

Automated And Integrated

Tests have a value only when they are executed. As long as they are just sitting in your version control system they are useless. Make them work. Make them work hard. Use all those machines that sit idle while the developers using them during daytime are at home enjoying live. Integrate the execution of your automated test suites into your development processes. When tests and their execution are automated and integrated they are executed more frequently and each time a change in the code base has been committed.

Are Automated Tests Orphans In Your Team?

Automated tests are first class citizens and equally valuable as the product that you ship. Don't even think for a second that they are just an unavoidable side affect. It's not a tax report that you do because law says so. Instead fully integrated automated testing is the mechanism that allows your team to operate at full speed. Depending on your team size maintaining the testing infrastructure can well turn into a full-time job for a motivated engineer.

Treat your testing infrastructure at least as well as the other parts of your development infrastructure. Make all of it part of an end-to-end integrated development process that starts with a customer suggestion and ends with a deployed system operational for the very same customer. Automated testing is a key ingredient and the rules are simple to follow. No excuse any more for not improving software quality. Happy testing!

Where to start?

2009-12-12T08:17:00.002+13:00

A question that I've been asked several times is where to start with improving your software engineering practices. Based on my experience, my answer typically is "It depends." Let me explain.

In one of my previous roles the release cycle was very long. This was not because we didn't want to release more often. It was simply because the system was very large and there were only few customers. Typically the upgrades would require significant manual intervention anyways. On the other hand, quality was a real issue and starting the improvements in that direction was a good choice by introducing a set of new tools, new designs, new technologies, new equipment, and new process. It was very focused on the inside of the development team.

In my current role we moved from one major release per year to monthly release cycles earlier this year. And although there were some concerns with it we were able to mitigate the impact in such a way that our clients can choose their own upgrade cycle. Whenever there is a feature of interest in a new release they can upgrade from their current version to the latest version in a one-step process. There is no need any longer to upgrade to the any of the versions in between. So, while we still offer new features each month, no client is force to upgrade on a monthly basis. There are, though, some clients who do, and each month there are clients who upgrade to that monthly release.

With this background it has become clear that just moving to monthly releases wasn't enough. Instead we combined it with significant efforts to simplify the upgrade process for our clients. And the feedback we get from clients in different geographies is very positive. Therefore we will continue improving the upgrade process so that it becomes even easier for our clients to move to later and even better versions of our software. With this ever-improving upgrade process in place we have established a delivery mechanism that allows us shipping new features faster to the market place. New features are picked up sooner and we receive feedback and suggestions faster as well. Our clients benefit from earlier availability of new features that in the turn allow them to run their business more efficiently.

In the second example I focused on the delivery process first - short release cycle combined with easier upgrades - while in the first example I focused on an improved engineering environment first. In the second example think of this: What if you had the perfect product but it would be a nightmare to upgrade? It would be very difficult to get improved versions installed on client's sites. If on the other hand you have a very simple upgrade process (and hence delivery process) you can roll out product improvements much faster.

There is no hard and fast rule what to do in each scenario. The key learning is that you need to identify what the determining factors are for your team's environment. Then create options and see how they would address the biggest challenges in your situation. Start in one place, and start small. Then observe and take the next step. And make sure you line up your team members. In particular their creativity and innovation are key elements to selecting the right starting point and to successfully move from there.

Mini SWAT Team

2009-07-25T13:31:00.003+12:00

Similar to the build master role - I posted about that a few weeks ago - you may find occasionally that there are other topics that you want to overemphasize for a certain period. The build master is specifically taking care of continuously improving the engineering and build environment.

But you may have items that are either to beyond the available build master capacity or don't even fall under the build master's duties. Or you want to speed things up. Let me give you two examples.

Let's say you want to introduce a new testing tool that you haven't used in the past. The tool arrives. While rolling it out you find that there are challenges and issues that need to be addressed. Not that you are surprised but the amount of work is way beyond of what your build master (or build master team) can do within their time. So what do you do?

Or you want to migrate your build environment towards a substantially improved environment, more powerful, more flexible, maybe involving virtual machines, new technologies, and so fourth. A steep learning curve is guaranteed. What do you do?

In both cases you can create a "Mini SWAT Team". This can even be as small as one person. The mini SWAT team would be dedicate to one particular subject for a period of time and then wrapped up. In the first example the introduction of the testing tool could be sped up by working with the QA team and by working with the developers. In the second example the mini SWAT team could work with IT on the environment improvements.

Who would you put on your Mini SWAT Team? Certainly you'd look for someone who can work independently but also in a team. People who can work with different functions are certainly advantaged. But then, you also have a quite different option as well: Give it to a more junior member of your team. Provide a lot of support and you'll find that the person steps up and grows with the job, enjoys the responsibility and the opportunity to pull something through that is of value to the whole team.

Food for thought? I hope so. It's all about trying something new and then adapting as you go!

Taking turns in being the build master

2009-07-02T15:03:00.004+12:00

The build master is a quite important role in an software development team. Responsibilities include ensuring the build works all the time and chasing down people who are fixing a broken build. Other items may include improving the build process which should also include the execution of comprehensive test suites in all test beds.

While on one hand it is a big help if a person in this role has prior experience with these tasks. On the other hand - and that doesn't have to be a competing goal - it is also valuable if team members take turns.

Let me explain. In all teams that I have coached I have found that different people have different strengths. For example one person might be excellent in writing Perl scripts while a different person is extremely proficient in relational database systems. By taking turns each individual can emphasize their area of expertise in the build master role. That way, if the skill is important to the whole team, the skill is also important for the build master role. Eventually all areas of expertise will get addressed eventually.

One more benefit of taking turns is that all team members walk in "the build master's shoes". There is a much better understanding of and buy-in by the team for build master related tasks and challenges. The response to being chased down because of a broken build will be tainted quite differently than if the same person is in the build master role.

At the moment I'm experimenting with swapping the build master role at the end of each release cycle (currently one month). And already the above mentioned effects have become visible.

Also check out "Manfred's DotNet Blog"

The Choice of Not Being an Elephant

2009-05-30T09:50:00.005+12:00

Lou Gerstner described in his book Who Says Elephants Can't Dance?: Leading a Great Enterprise through Dramatic Change
how to make even a very large organization more agile, more adaptive to changing conditions. IBM had no other choice since some of their old business models stopped working. When I speak with people who were decision makers in the 1970s they unanimously told me that there was a time where the sales guys in dark blue dresses almost walked in to their customers and just said "sign down here". The customer had little choice.

Even if these stories are exaggerated - I'm not a sales guy but I'm sure their stories are always true! - there is one interesting aspect to this. I'm also mentioning this since I just came back from a trade show and there I spoke to a manager of one of the largest vendors in that particular industry. Somehow that person made me think of those stories from the past about IBM.

Like IBM in the IT industry this person's company is a key player in their industry. And the way the person came across was almost as if he was saying: "We know what is good for the industry, for you. Just do what we say, sign here and everything will be right." Sounds to me a little bit like "We are the center of the universe and all other companies better lign up around us."

The conversation left me wondering by when their CEO will write a book about how she had to turn their company around? Maybe they haven't noticed yet that the downturn in the industry probably requires them changing their attitude as well. But maybe I'm totally wrong and they still have full order books and the customers are lining up to the horizon. Not long ago, however the news were saying they are in the process to make a large number of people redundant.

That doesn't sound to me like full order books... The news of redundancies along with the attitude of the person I spoke to appear more like a company that isn't yet set up flexible and adaptive enough. Maybe reading Lou Gerstner's book helps.

Also check out "Manfred's DotNet Blog"

How Pair Programming Reduces Distraction

2009-05-20T05:52:00.003+12:00

Pair programming is not for everyone. Some people love it, some people hate it. It almost seems there is nothing in the middle.

I'm more in the camp of people preferring pair programming. For many different reasons but I keep the discussion for a different post.

In this one I'd like to describe an example for what happened to me yesterday. I was working with one or my fellow software engineers, Jason, and while we were looking through a nasty C++ link problem we discovered a small item in an adjacent code area that we felt should be cleaned up. So I took a card and wrote it down as a story and returned back to the problem at hand.

Jason was surprised and made comment saying that by taking a note we would actually avoid being distracted. Although I have worked like that for years my colleague is newer to pair programming and that was probably the reason why he noticed what I did. For me it was just normal mode of operation. I did it unconsciously.

Based on my colleagues observation I think there is a lesson to be learned: First there is the specific case. When you come across something that should be done then just take a note (create a 'story' card). Don't let yourself get distracted. That way there is only a small interruption and then you are back on the problem at hand. Secondly, don't assume that the way you work is normal in the sense that everybody knows all the techniques you are using. It pays off to make yourself aware of this and sometimes it takes a good observer like Jason making a comment to become aware of what you are actually doing. So keep your ears open!

How fast do you adapt?

2009-05-01T07:03:00.005+12:00

Here is a quote from today's online edition of The Wall Street Journal:

President Obama said that Chrysler has been "a pillar" of the industrial economy but that the company moved too slowly to adapt to a changing market.

(Source and more details: The Wall Street Journal, retrieved 01 May 09)

What caught my eye was the word "adapt". By the looks of it - I agree with the assessment - Chrysler didn't adapt fast enough. Now it has filed for Chapter 11, a bankruptcy process that protects it while going through a restructuring.

I'm not happy to see anything like that because many people will be severely affected in their personal lives. However, this is an (extreme) example of what can happen if you don't move fast enough as a company. Chrysler's product mix is no longer a good enough fit for what the market demands. The economic downturn just amplified that.

What can we learn from it? If we don't adapt fast enough to changing market demands and conditions it could mean very bad times for the company or the end of the company. Need any more incentive to adapt?

Can you make it right for everybody?

2009-04-30T21:18:00.001+12:00

Yes, you can try as hard as you want. Don't we all try to provide an environment that allows people to grow and be their best professionally?

I think this is an important ingredient for a high-performing team. There are limits, however. For instance if you have a team member who isn't particularly keen to actively support changes. Not that I would be surprised by that. People have different personalities and while most are fine with change for a good reason occasionally there are people who resist all kind of change since they may have different preferences and experiences. And that's fine.

If you have a team member with an excellent skill set and huge amount of knowledge and experience that's fantastic. But what if that very person isn't able to proactively work with other team members to help them becoming better as well? What if you have a team member who doesn't attend the first daily stand-up meeting (aka daily Scrum) and comes in late once the meeting is over? What if on day two the same person comes in late but doesn't join the Scrum although it is still on? What if on day three the person is in the Scrum but doesn't participate actively? What if on top of that you observe that it even seems to have a negative impact on the rest of the team?

I think at some point you need to consider your options. Having one-on-one's for coaching is important and helps in most cases. Attempting to consider individual preferences is good, too. But once the overall team performance is affected, you need to act. And don't let anyone hold you hostage. As a leader and coach you need to keep in mind the future of the entire team and the project and objectives the whole team is working on.

An agile environment is not for everybody. There are organizations that work differently and it seems to work for them. Based on my experiences, however, I believe that agile principles work better if properly applied. In some cases this could mean that you may have an individual on your team who has a different perspective, and you should be prepared for that individual moving on. That's just fair and part of the overall change process for the team (and in fact for that individual, too!). Both the individual and the team are most likely better of.

If you have tried everything you can think of and still it doesn't work out, don't feel like a complete failure. You are not! Think of your team and about where you want to take them. And then adapt and move forward. Don't look back unless you want to learn from the past!

Projects - Do you need them?

2009-04-29T06:53:00.003+12:00

In some companies projects are an important concept since they represent a piece of work, well defined at the beginning, maybe with a business case outlining the commercial benefits, with a project to sequence the tasks and to track progress, and with known deliveries at certain milestones and at a specific date. So far so good. There might be a problem with that, though.

What if your projects are too large? And by large I don't mean the projects that run for several years. More than a month can already be too large depending on your circumstances.

For example suppose you would like to be in a position so that you adapt as quickly as possible to changes in your environment. Customer's preferences can change. While maybe two years ago best use of limited resources was important maybe today it may be cost reduction to get through the recession.

For instance here in New Zealand the new fiscal year has started at 1 April. Many companies have taken this as an opportunity to rethink their position and options. I have spoken to many friends in different companies and to recruiters. It seems as if quite a few companies have made substantial changes triggered by the planning of the new fiscal year and as part of the approval process for new budgets.

There are many other events that change the environment in which you operate. And it appears as if those changes come in shorter intervals than maybe ten years ago.

A project of 2 months might already be too large as it might force you to lock in your team's capacity for that entire time frame. Then what do you do if something changes and you'd like to direct your team onto a different piece of work? Put the project into the bin?

Maybe there is a different notion, a different concept that you can use. What if you could split up the work required to be done by the team in even smaller chunks. For example in the company I currently work for we have many customers who work with us as a partner. Through this work, based on mutual trust and interest, we gain a lot of insights into how we can improve our products. Many small though very valuable enhancement requests are generated through this process, many of them only a few days work, a couple of weeks at most.

What if you'd look at the set of enhancement requests as a stream of small work items (one item batches) as opposed to projects that combine many such requests (large batches). Moving towards using smaller batches, ideally one item each, works better if you optimize towards processing those. Toyota calls this one-piece flow.

I think that is worth considering. Thinking small instead of massive grand schemes. There is more to that, in particular how you get started, what tools to use, and how to make it work. Stay tuned!

Navigating: What do you mean, captain?

2009-04-24T17:42:00.003+12:00

OK, I can't speak for all industries but I can understand that you'd like to hear a few more concrete things you can do navigate these times. Let me share a few things from my software engineering perspective.

One of the options you could look at would be virtualization of parts of your development environment. An area that often proves to benefit is everything that has to do with testing. For instance if you have physical machines to test your application it might be very time consuming to set it up from scratch. You can speed this up by using an image that you can play back on the test machine. With virtualization you can become even more flexible or faster.

Some solutions allow you to create templates of virtual machines. Examples include a server with a specific database server product or a client machine with a particular browser version. If all it takes to select one each and instantiate it you can significantly speed up testing by reducing the setup time. And on top of that some virtualization products have features that allow automating a large variety of setting up virtual machines. And if you don't need them anymore just throw the VMs away. Just like that!

Another area that is worthwhile exploring for becoming leaner is everything that has to do with documents in particular internal documents. Look at all graphs for instance that require manual updating. Is there a graph that can be replaced by a simpler version or by a graph that is automatically generated and updated? Also, in some cases you may be able to simply some documents by replacing some text by tables.

Tools is yet another one. Are there tools that you can upgrade or add that will help your team to off-load more tasks to the tools? Do you use an out-date version control system? How about your automated testing tool? Automation and simplification are key regardless of whether you look at processes, tools, technology, or others. Can you simplify the design or implementation of your product? Can identify a technology that you use in your product that has outlived its usefulness?

There are plenty of options. Keep your mind and eyes open. Observe. Challenge. Put practices under scrutiny. Do they still make sense? Experiment. In small doses. Try out. Maybe you fail. But chances are that what you try will help you to focus even more on what is important in these difficult times.

And at at the same time you will become even more flexible in terms of how to respond to changes in these uncertain times. It's not the changes that hurt. It is how we respond to them.

I'm sure you got my point and are able to translate this into your industry and your specific situation. In particular in difficult times it pays off to have plenty of options for how to navigate through them!

Navigating Difficult Times

2009-04-01T06:57:00.005+13:00

I chose the word "navigating" deliberately. The current economic climate is very difficult for many people and companies throughout the world. And chances are that you are affected in some shape or form as well.

It appears that no 'rule' that worked in the past applies to the current situation. Is that really true? I think it doesn't really matter. The important bit is that if you carefully choose an approach that lets you quickly respond to whatever is waiting for you around the next corner then you will be better off in all likelihood.

Some people and companies still try to come up with a grand plan for how to go forward. And as long as that plan is really more like a description of the direction and the principles to be used I think that is fine. But what good would it do to you if you would spend planning time right now on what you would be working on in 12 months time if all that matters is what you are going to do next month, three months from now, or six months from now!

Respond and adapt. Do both as quickly as needed (but not faster!). Instead of locking down your plans for the next 12 months use rolling plans (a planning tool, actually), e.g. for the next 3 months or for the next 6 months. Then update these plans on a regular basis, either monthly or triggered by new relevant information that warrants a revisit of your plans. If your plans cover 3 months they are much easier and faster to adapt to new insights than plans at the same level of detail that cover 12 months. Trying to update plans that cover a larger time frame tends to result in a lot of waste.

Navigating these difficult and uncertain times is definitely easier if you choose an approach that allows for much faster response and adaptation to the changing environment. At the same time you will be much better off once your markets start to improve again.

Encouragement

2009-03-25T12:17:00.003+13:00

How do you know your team is making progress? And how can you support them in doing so? I think it is not that hard.

One technique is to observe what they are doing and how they operate. Keep a log of your observations in particular of successes and to a lesser degree of the failures. Of course not in the sense of big brother. But more in the sense of helping people realize where they are coming from, what journey they have already behind them, what successes they had, etc.

A few weeks ago I noticed that one of my teams started to use a backlog for prioritization and planning and a burndown graph for tracking progress. Recently I observed the first stand-up meeting that took place in the team area instead of taking place in a meeting room with everybody sitting down.

It is successes like these, and acknowledging these, that helps people seeing things in perspective and understand how they are moving ahead. Encourage your team if you see positive things happening!