Software Best Practices

Change is inevitable on a project. It doesn't matter if you using agile or plan-driven techniques, you must embrace change. Agile embraces change by being very responsive -- they point out that the future is unknown, so they just look to the near term. 

Plan-driven techniques are used when the customer values predictability. So plan-driven has to embraces change by anticipating them.  Two common techniques for anticipating change are to include a change buffer in your plan and to use design-for-change design and construction techniques.

What other techniques have you used to anticipate change?

Thanks

Change is a very broad term. In my experience the high level requirement (i.e. an online ordering system) is rarely subject to much change. The detail of what has to be delivered changes enormously over time but a lot of this “so called” change is in fact the process of developing a high level requirement into a product.

I once led a team of four developers and gave them the freedom to change the functional specification whilst they were coding. This was done without seeking customer sign-off. Whilst this sounds dangerous, I genuinely believe that it empowered the developers to take responsibility for ensuring that the product met our customer’s requirements rather than just coding what the functional specification dictated (whether it made sense or not). The customer in this case was delighted by the results and the project was delivered within tight time constraints. I do not think we would have achieved that if we had insisted on time consuming formal sign off for every alteration.

In my opinion real “change” only occurs when you are not talking about a refinement of the high level business requirement. This could be a total alteration of purpose (i.e. online ordering system becomes radio controlled caterpillar) or, more usually, environmental changes such as developers leaving your team or a new operating system no longer supporting your development environment. These changes are very difficult to plan for and therefore I think contingency is the only way of allowing for it.

David,

My observations is the same as yours -- the high-level requirements are pretty stable. I like your solution of giving the developers the freedom during coding.

Of course, your post raises several questions.

• Are you using this technique on plan-driven projects?  If so, how did you account for this in the plans? (e.g. Are you creating estimates off the high-level requirements that includes assumptions about the down-stream work? Or are you using some other technique?)
• You mentioned contingency.  How did you account for the uncertainity in your assumptions about the continency buffer?
• One problem with buffers is many managers view them as unneccessary and delete them from our plans. Sounds like this didn't happen to you. Was it hard to sell the need for buffers to your management?  How did you protect it from being cut?

Thanks for your insights and I'm looking forward to hearing more about your techniques.

Hi Jerry,

Some good questions! I will do my best to answer...

On that project the original estimates were created by breaking down the product into components and then estimating best and worst case effort for code and unit test of each component. My management required a single figure rather than a best and worst case and so this was “translated” into a single figure with sufficient contingency to cover the worst case. Standard percentages for design, system testing and project management were added. Risks were assessed separately and quantified so that they could be accounted for in the contingency as well. Justifying contingency to management was significantly eased by the use of best and worst case estimates and the identification of risks.

As one might expect once technical design work started in earnest it became apparent that the original component breakdown bore little resemblance to the work that was to be done. Once we had a firm technical solution separate areas of the design were allocated to each of the developers (enabling them to take responsibility for those aspects). Each developer was able to re-estimate their work based on this new information and these new estimates formed the basis of the plan.

I think that often plans are based on estimates that no longer reflect current knowledge about the work to be undertaken. My view is that when you start a project estimated to include 300 person days of development the plan may as well have a single activity of 300 person days to reflect this. Once a further stage of design is completed it will be possible to refine this. To start with more detail on the plan gives a skewed impression of how much is known about the state of the project at that stage.

As it happened all the development work was completed well below “worst case” effort estimate. However a problematic roll-out had not been accounted for anywhere in the estimates or risks. In the end the contingency was used for this. So on the one hand this proved the value of having contingency. On the other hand the justifications for contingency were proved incorrect! That is why nowadays I believe that contingency should be used to account for the unexpected and therefore adding a standard percentage is the most correct way of doing this. You can take account of things that you think might happen by considering them as risks or using best and worst case estimates but you will NEVER be able to take account of things that you do not identify at the outset.

David.

David,

You provide some more good techniques for anticipating changes. Here's how I would summarize them:

• Component Level Estimating
• Estimating Best, Worst, Expected Cases
• Using standard percentages for downstream activities
• Active risk management to build your contingency
• Re-Estimating when more information is known
• Refactoring the plan to reflect current understanding
• And the best technique -- Think First

daviddaly:

You can take account of things that you think might happen by considering them as risks or using best and worst case estimates but you will NEVER be able to take account of things that you do not identify at the outset.

Thanks for sharing your techniques and I look forward to hearing how other people anticipate change. 

Another requirements related idea I like (which I know you already know about) is Tom Gilb's idea of the requirements "landing zone." Some requirements are binary -- the software meets the requirement or it doesn't. But others are "scalar." These are the requirements that are traditionally called "non-functional requirements" or "quality requirements." The software has "more" of the requirement or "less," but it isn't black and white. The definition of scalar requirements include several elements:

• The "gist" of the requirement (this is what many organizations are currently treating as "requirements")
• A "scale" for the requirement, i.e., some way to assess what qualifies as "more" or "less" of the requirement
• The minimum acceptable level of the requirement
• A range in which "more" of the requirement is "better"
• A maximum at which "more" stops providing additional value

The range between the minimum acceptable level and the maximum useful level makes up the "landing zone." (There are a lot more details to Gilb's approach (called Planguage) than I'm describing here, but this should be enough to communicate the basic idea.)

It takes a mental shift to think of requirements this way, but Gilb has convinced me that it truly is possible to define a quantitative scale and a landing zone for every single scalar requirement. (As Gilb says, bad numbers beat good words.) Once you've done it for awhile, it doesn't take much longer than defining requirements in the traditional (aka sloppy) way, and the increase in clarity is striking.

A common example would be response time. You could imagine a system in which a response time greater than 2 seconds is too long. Therefore 2 seconds will be the minimum acceptable. An improvement in response time in the range from 2 seconds to 1/10 second is valuable. But once you get response time of less than 1/10 of a second, there's no additional value. For example, improving response time between 1/10 and 1/100 of a second doesn't add value to the system, so there's no point in developers working beyond that upper limit. This example is hypothetical, and real systems have different worst and best acceptable response times. But the point is that you define is explicitly instead of leaving developers to guess about what's useful.

The great "embrace change" support you get from landing zones is that they inform the development team about how much of each scalar requirement is good enough, how much is better, and how much is a waste of development effort -- and they can do that on their own initiative without further involving the business stakeholders. Moreover, when landing zones are defined across multiple requirements, it allows the developers to make technical tradeoff decisions as new requirementes are added about how to support the set of requirements as a whole, again without necessitating time-consuming back-and-forths about the old requirements with stakeholders outside the immediate dev team.

One thing that we do is having the analyst always with the team. Our application is a commercial application, it is not tailored for a specific customer so requirements comes mainly from the business analyst alone. 

The analyst is always with the developers and the testers while working.If someone sees an illogical requirement he can discuss it with the analyst at once. This decreases the requirements change cycle very much. When a developer sees a small requirement that can take a lot of time to implement he can discuss it with the analyst to determine if it deserves the effort and time, or the level at which this requirement can be acceptable.

The downside of this approach is that it is difficult to use with big teams or with applications that serve a specific customer - at least this is what I think. For a big team you need to have a big number of analysts to support the developers. With a big number of analysts conflicts can easily creep into the requirements if they change requirements on the fly without discussion with each other and putting it formally.

Thanks for joining our conversation! 

MuhammadAdel:

having the analyst always with the team

This is a great tip. I'm often asked where the requirements engineer (aka business analyst) should reside – on the business side or the development side. I personally prefer them being on the development team. In addition to being the bridge connecting the development team, they become a walking spec. This cuts the wait time when the teams uncover a requirements error.

It is also a great technique for embracing change. It fosters closer communication among the team members. It provides opportunities for the requirements engineer to keep the team aware of upcoming changes.

One key thing, the requirements engineer must understand that he is only speaking on behalf of the business side. This means they need to get back to the business side to confirm the answers he provided to the development team.

MuhammadAdel:

The downside of this approach is that it is difficult to use with big teams or with applications that serve a specific customer

I have a different opinion on this point. I have seen teams with multiple requirements engineers. The key is to clearly define what areas each is responsible for.