Natural Law

Laws, rules, process. They are all related and they are all around you. You don’t consciously think about them from moment to moment, but you are reacting to them moment to moment. They are second nature to you and you don’t have to think about them. On your way to work you drive on the correct side of the road, you stop at stop signs, and you stay in your own lane. When you go to lunch, you pay for your food. After work you go to your house instead of going to somebody else’s house.

It is easy to remember the laws, rules, and processes because you interact with them every day and you get reminders and possibly even unpleasant consequences when you go astray. A great example of this is the rumble strip that is commonplace on the side of highways these days. If for some reason you start to drift off the road, you’ll hear a loud warning noise as your tires hit the rumble strip. If you are really violating the law, you’ll hear an even louder sound accompanied by flashing lights. This is also known as feedback.

We get feedback our whole lives. When we first come into the world, we need constant feedback in order to learn how to survive. Touching something hot is painful, going without food is painful, falling down stairs is painful. In school we get feedback as to which subjects we are good at and which subjects we are not so good at. We can use this feedback to decide what to do more of, what to avoid and as an aid to improve, if we are able to.

An important part of absorbing all of these laws, rules, and processes is that they are clearly defined, easy to understand, and easy to remember. Once you have mastered basic physical laws such as running at full speed into a door is painful, it is easy to understand the reasoning behind having an upper limit on the speed of vehicles on public roads. You may disagree with that limit, but you can generally guess what the limit is for a given stretch of road and it is posted at regular intervals to help you score your guesses.

Somehow, the powerful combination of clearly defined process and reinforcement through immediate feedback are absent in most software development organizations. This is surprising considering that two of the main ingredients in software itself are rules and feedback.

One of the ways that Agile development helps is by providing frequent feedback, both to you as a software developer, and to the customer which in turn provides feedback to you. This makes it easier to learn about your market and your internal process and to make constant improvements in your product and your product development process.

Next: Agile Development is People Oriented

The Role of Defect Management in Agile Development

There are some who recommend against using a defect tracking system. Instead, it is recommended that when a bug is found, it is fixed immediately. While that is certainly one way of preventing an ever growing inventory of defects, the tracking of an inventory of defects is one of the smallest benefits of a defect tracking system. Overall, a defect tracking system serves as a facilitator. It simplifies the collection of defect reports from all sources. It isn’t just the developers responsible for fixing the defects that find problems. Customers, developers working on dependent systems, and testers also find defects. Even if you have a policy of fixing defects as soon as they are found, it isn’t always logistically possible to do so. For instance, if you are currently working on fixing a defect and in the process of doing so you find another one, you don’t want to lose track of it. Thus, a defect tracking system coordinates the collection of defect reports in a standard way and collects them in a well known location, insuring that important information about the functioning of your system is not lost.

A defect tracking system also manages the progress of work through the development life cycle from reporting, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. It simplifies the answering of customer questions such as “what is fixed in this release” and “what release will the fix appear in.” A defect tracking system also allows for the collection of metrics which aids in the spotting of trends. I have heard from multiple sources that metrics collected from a defect tracking system are worthless because developers will just game the system. That may be true in an unhealthy environment where the metrics are tied to compensation. However, in an environment where developers are actively participating in the improvement of the process, they will want this information in order to help to find and fix problems, including the root cause of individual problems.

Next: Designing Software is the Same Thing as Predicting the Future

Podcast: Open Source Technique for Agile Development

Check out this podcast to hear about how "meritocracy" allows developers to contribute outside of their traditional areas, to build trust in their capabilities, and to allow them to naturally gravitate to the areas where they are the most effective.

Podcast: Mainline Chaos

Here's a podcast which covers these topics:

• More on the practice of a "development hierarchy"
• Checkpoints
• Gatekeepers
• Atomic Transactions

Podcast: Hyper Agile Development for Compliance and Distributed Development

It might seem like doing Agile Development is not compatible with compliance requirements. However, Software Configuration Management (SCM) plays a vital role in any compliance effort that involves software development.

This podcast covers the following topics:

• How SCM and Issue Tracking can help with compliance in an Agile project
• Process is a dirty word
• The Hyper Agile practices of "development hierarchy" and "one virtual site"

Podcast: Winning the Jolt Award Using Hyper Agile Development

Here are some thoughts about winning the Jolt Award as well as a discussion of Hyper Agile, the new methodology that enabled AccuRev to deliver AccuWorkflow on time with high quality.

Primary vs. Secondary Agile Development Benefits

Agile is generally talked about as a single package: if you adhere to the principles, you get the benefits. I believe there is another way to look at Agile. Agile introduces a whole new set of practices to the development toolkit. These practices include: product backlog, pair programming, on-site customer, continuous integration, refactoring, test-first development and many others.

While all of these practices have been either associated with or created as a result of Agile, their application and resulting benefits are completely independent of your chosen methodology. Use Scrum or "Waterfall" and you still get the benefit.

For instance, refactoring is a standard feature in Eclipse. Eclipse is an IDE and is completely orthogonal to your methodology. The benefits from these practices are secondary benefits when practicing Agile. In my opinion, the primary benefits of faster turnaround, realizing business value sooner, and quality increases above and beyond the quality increases from the individual practices comes from the single practice of short iterations.

You don't have to do pair programming, use 3x5 cards, collocate, only use small teams, or have a customer on site to get to short iterations. These may help, but they are not the only practices that will. For instance, test driven development is very easy to adopt, contributes greatly to enabling short iterations and does not require any experimentation with personal boundaries.

Let's say you give me the benefit of the doubt and are willing to believe that there are benefits to implementing Agile. Why should you personally spend any time thinking about it?

Next: Agile Development, What's in it for Me?

The Dangers of Moving to Agile Development

My previous post received this comment:

"We have use the scrum process for about 6 months and I feel we are still practicing mini waterfalls. I really need help to defining the role of QA from start to finish. Are we suppose to write test plans? While we are waiting for development, we are unable to write test cases because the specs are not fully define and items that are being added are changing. In the end, we have the product not fully testing and catching up with the next sprint. No test cases are done and no automation is done. Seems like it is what we were doing before."

To me this sounds like a case of going to short iterations too fast! Most of my thoughts on the role of QA in an Agile project (Scrum or not) are articulated in the two recent posts I've already made on this topic, but here are a couple more thoughts...

Opinions may vary on this, but IMHO, if there are no test cases and no automation, you're just not going to succeed with any Agile methodology, Scrum or otherwise. One of the major principles of Agile is that you have working software at the end of every iteration. If it hasn't been tested, how do you know if it is working? It sounds to me like you've got complete chaos.

Do you have an Agile coach on the team? Do you have certified Scrum Masters on the team? If not, I'd highly recommend getting one or both of these.

I believe that for any Agile project to succeed, each story must go through a full and complete mini-lifecycle prior to the end of the iteration. That is, whatever process it would have gone through in your old methodology, it should still go through and it should happen during the term of the iteration. My preference would be that it go through those steps in immediate succession. That is, before code begins on any story, you are clear what you are setting out to accomplish (requirements), you have a plan for doing it (design/spec), and you have created as many test cases as possible. I'm not saying that all of the requirements are known at the start, but that you do as much as you can. Same for designs, specs, test cases. Worst case, all of these should be done for whatever code is done at the end of the release.

For instance, if story 1234 has code associated with it that performs 4 functions, then you better have the requirements, design, and test cases rock solid at the end of that iteration and those test cases better all be automated and passing. By "rock solid" on the requirements and design I mean that at a minimum, the coder better be able to articulate it to you. If they avert their eyes and hem and haw, how will anybody be able to use it?

If at the end of the iteration you don't have near 100% of what you have come to expect just prior to starting your release process (delivery to customer), then you need to stop immediately, do a retrospective, and take immediate corrective actions!!

Good luck and be sure to keep post updates on your progress.

Passing the Baton from Iteration to Iteration

My experience is that with automation, branching, and the supporting process, the goals of determining the quality of an iteration and creating stable baselines can be achieved in parallel. The first step is automation. Without a high degree of automated testing, I'm not sure it makes sense to try to do this in parallel. However, with continuous integration which includes full builds and full test suite runs, there should be few if any problems at the end of the iteration.

Some might say that their automated build and test takes a very long time. That’s a whole separate topic. In the meantime, let's assume that the full automated build and test cycle takes on the order of hours.

By branching, you can start the next iteration without disturbing the previous one. If QA finds any problems, development can fix them on the previous iteration branch. At some point that branch will be declared "done." Those changes are then merged into the current iteration. At that point, there is very little if any difference between where things are and where they would have been if development had started from the "done" baseline.

The advantage here is that development did not have to stop, and you still have a stable baseline. My experience is that once a team gets into a rhythm, the amount of time spent on "touch-up" is minimal.

This also applies to iterations that become releases. The "previous iteration" branch becomes work towards the release and then hopefully soon thereafter the release itself. Meanwhile, work continues towards the next release.

The Role of QA in an Agile Development Project II

At a high level, you should work to keep the ratio of development to QA balanced. The ratio will vary from project to project, so I'm not commenting on that, but once you have a ratio there are several ways to maintain it. In an Agile project, you may quickly find out that the ratio itself is off and need to adjust the ratio. In a project with long iterations, you might not find out that the ratio is out of whack until it is "too late."

In any case, once you find that you are short of QA resources, there are a couple of options. The first option of course is to get more QA resources. Failing that, you can use development resources. It may also be that you have a short-term need for more QA and in that case using development resources might be exactly the right short-term solution.

I think a common rule of thumb, which especially applies in the context of compliance, is that different people do the development and testing of a particular requirement. That is, if Sue is responsible for issue 12345, then Sue doesn't do the testing of it.

As to the exact use of development resources, I advocate that developers take on a sub-set of QA activities, thus allowing for better leveraging of the existing QA resources. For instance, creating automated unit tests or the general generation of automated test cases.

You can of course set whatever policy makes sense for your organization. Having people only write test cases for other people's code is always a good idea. Beyond that, I would assume that QA would take what the developers had done as a starting point, supplementing with additional tests, reviewing what the developers had done, running the official test cycle according to the test plan and reporting on the results.

Next: Multi Stage Continuous Integration