Questioning before Answering

The other day I came across a short video in which a parent is faced with answering a unexpected question posed by her young child. I found this video amusing because, being the parent of a kindergartener, I expect to be faced with many awkward moments like this in the future. I also found it an interesting metaphor for software requirements gathering.

In the video the  parent could have answered the question a whole lot more simply has she just asked taken a moment to try to understand what the real question was, and not taken the question at face value. (I'm being purposely vague at this point in case anyone wants to watch the video.)

Most of us have been on projects where much effort has been spent in an attempt to solve a customer's stated problem, only to discover that that either:

• The program didn't actually solve any of the customer's real problems.
• The team didn't solve the problem that the customer wanted solved.
• There was a much simpler solution.

I'm not suggesting that exhaustive requirements capture is the answer. Nor am I suggesting that you should not start building software until you have complete understanding of a problem. The reason that agile methods work well is that they  acknowledge uncertainty, and provide a simple path to refining understanding: evaluating working software.

Acknowledging uncertainty does not mean ignoring information. In some cases customers might not really understand what they need, and the best way for a team to progress is to take a guess based on the information they have, and iterate on a working system.  In many cases a customer will know the reason they want to do something, but may not be able to step back enough to express it. In these cases, but not trying to ask "why?" your team is ignoring information  that can help them do their work. In more cases than not, a customer can fill in the pieces of  the user story template:

As a (ROLE) I want to (DO SOMETHING) so that (REASON)

and provide insight into the problem that she wants to solve. This will save time, effort, and help the team deliver a better system.

If your team takes customer requirements statements at face value without exploring the reasons why a customer wants a piece of functionality, they aren't holding up their end of the collaboration part of agile software development. 

Had the parent in the video though to ask why the child asked the question that she did, the process of answering might have been simpler.

SCM Tool as Collaboration Tool

A few weeks ago I had the opportunity to give a virtual talk at a product launch for an SCM Tool vendor.   The theme of the talk was basic branching strategies, and preparing for the talk led me to reflect on what  Brad and I wrote in the SCM Patterns Book. This post is based on those thoughts.

When Brad Appleton and I wrote Software Configuration Management Patterns I wanted to focus on how to use Software Configuration Management and Version Control  to improve productivity and collaboration.  In many organizations SCM processes, procedures, and policies are focused on stakeholders other than those who rely on the system most: developers.

A good SCM process can help you to work better as a team, and help your team be more agile. An ineffective one can slow down development, and be an obstacle to progress. Likewise the tools you use, while secondary to the decisions about the way you work, can affect how effective your SCM process is.

Tools are important. A good SCM tool helps you work more effectively as a team and allows you to focus on your work and not the mechanics of the SCM process. But the process needs to come first to use SCM effectively. Here are some brief thoughts on what I think are the core issues to consider when designing an SCM process.

Code Lines

While there are many aspects to Software Configuration Management, the first concept that comes to mind for many is version control. Developers commit changes to a code line, and update their workspaces from a code line. The main role of an SCM process is to facilitate integration, and you want commits and updates to be frequent to avoid complicated integrations.

Frequent commits also give developers the full benefit of having a history of their work so that it is easy to revert to a known state when a coding experiment goes wrong. So you want processes and policies that encourage frequent integration.

The simplest SCM model is to commit changes into a single code line. Working on a single code line is simple in some ways. But it requires discipline to keep a single code line, with frequent commits, stable.

A code line where people have practices such as tests and a discipline of pre-commit builds in place, is an Active Development Line. Not every team can maintain this discipline. And even for those who can there are legitimate reasons to work on more than one code line. Once developers realized the challenges of working on a single codeline, they quickly become interested in the  way a tool supports branching.

Branching

The first question people often ask about a tool is how it supports branching, this question is best answered in the context of  understanding why you want to branch. Branching is a technique for enabling parallel development. When you branch you create code line that is a copy of its parent and it can evolve independently. A Branch allows you to work on variation of the code without affecting or being affected by, changes in  the parent code line.
 
The ability to work in parallel can be an effective tool for enhancing productivity. It can also be a cause of bottlenecks and frustration. The difference between the two results depends on whether you follow branching patterns that address the problem that you are trying to address.

Branching can be a very useful mechanism for making your development process more effective if you do it the right ways, with the right tools, and for the right reasons. A poorly applied branching strategy can have the opposite effect, decreasing your velocity and making it harder for team members to work together. So while how a tool supports branching is important, it's more important to understand why you are branching, and if branching is as helpful as you'd like. As I explain in more detail in a article on TechWell:

Branches are helpful if the enable you to work more quickly than a single code line would.

To make this concrete, here are some examples of solutions to a "fix the release" scenario:

• Use a Release Line: A common branching pattern is to create a branch when you release software, The Release line allows you to deliver fixes to the released software quickly without having to worry about the impact of new development work on the code. Most of the time a release branch is the right choice for managing changes to a release. There are alternatives, but each adds its own cost. 
• Defer the fix until the next release is scheduled. This will only be a viable option if the problem isn't critical, or if the team releases software frequently. In many cases, teams don't release software frequently enough to do this. 
• Fix the problem in the existing code base and release early. This can work only if you have a continuous quality assurance cycle that insures that your code is always ready for release, While many teams strive to do this, few are able to.

So, in many cases, the traditional Release Line pattern is the right choice. But it's good to be aware of alternatives.

Distraction

While branches can be useful, they have costs that you need to be aware of. Team Software development is a balance between integration and isolation. Branching can be a powerful tool for isolating change.

But be aware that not all changes are are isolated as they first appear. For example, much of the time when you fix a problem on released code, you will also want to address the problem in your new development code line. So by working on a branch you have created the need to do the same work twice. And the more branches you have, the greater  the risk of distraction, and reduced velocity.

Software configuration management practices and tools are part of a developer's basic toolkit. Like all tools, the right tool used correctly they can help you get your job done. The wrong one used without understanding can distract you from your goal.

Branching can help improve your velocity, but be sure to be aware of the reasons you are branching, and always ask your self if the branch will  deliver enough value to justify the cost. and always test and integrate frequently to avoid surprises.

Keep in mind that the real goal of an SCM environment is to help your team to work effectively.