How to decide if a "quick, small change" should be implemented?

Question

In my blog I assert that (in software projects) the quick, small change does not exist.

Let's define the quick, small change as a 30-second task.

Let's take a simple task: Deleting the extra period at the end of a sentence, or changing the hue or text size.

Why is that a big deal?

The answer is: the amount of work the software engineer has to do:

She had to:
read the Change Request,
find the correct file,
check-out the latest revision from the Revision Control,
make the change,
do a Diff on the file to ensure nothing else accidentally was changed,
and then Check it back into the Version Control and compile.
She then had to assign the Change Request ticket to QA to be tested and the Automated Scripts updated.

By now she has completely forgotten what she was working on, and will have to get back into her original project.

How is a PjM to decide when to sneak in a quick, small change, and when to push it through the official procedures for change?

Or should it be an inviolate rule that no quick, small changes, not matter what?

While this question deals with the question if you are using Agile, I'm wondering if people have other opinions for non-Agile projects for which no stories and tickets are going to be created for tiny tasks.

Answer 1

I am assuming that this question is describing a "change" that is implemented bypassing a controlled change process. If true, then I would agree there is no such thing as a small, quick change. The issues of adopting the alternate point of view are many:

1. Many small, quick changes equal a few large slow changes.
2. The lengthy negotiations of what constitutes small will be entered into many times during the course of the project.
3. Even if the definition of small and quick is agreed to, then there will be incentive of optimistically valuing a change in order to meet the small and quick criterion. E.G., the definition of small and quick is 10 hours and 1/2 day duration. A change comes across a developer's desk where the proper planning value might be 15 hours and a day or day and a half duration. The planning value is reduced to hit the criterion putting the team at further risk.

This is an ingredient to scope creep.

Answer 2

I agree with you, quick changes do not exist. But it also depends on how good your team is. If you have a good team then it is okay to take small changes. But please don't take it without a CR/Bug. It is helpful to track such changes.

Once I was working with a careless team that would not focus on the issue at hand. A simple change like deleting space before the colon and making the text - "State: NY" got failed by QA as the space was not properly deleted. The team took 2 hours for the first time and another hour for the second time. 3 hours is a lot of effort just to remove one space. With my team if I had a choice to defer such changes I would do that.

We track all changes in TFS and have to check-in code with the associated Task or Bug. I suggest you do too.

Answer 3

I hate to tell you, but developers do these quick changes all the time and never tell you (the pm) about them.

If you are getting push back, its because you are not accepting, or appearing to accept the risk of the change.

Accept the risk that the change will cause the release to fail or introduce career ending bugs OR follow your change control process and stick it in the back log with all the other changes.

Answer 4

In my experience (incremental waterfall development/technical projects) there are two parallel models running in sync:

1. The Formal Model: This is what the published project plan says coupled to what the methodology says should be happening
2. The Unwritten Model: This is what actually happens “at the coal face”

The first one is what gets published and reported upwards and outwards in the organisation in the project manager’s progress reports, both formal and informal.

The second one is kept private within the project team (including the project manager).

In the formal model, which is where the formal and agreed change control method lives, no change should be unaccompanied by formal change control that understands the cost, both in time and money, of any change or deviation from the plan and specs and maintains approval of all stakeholders at all times.

The problem is that strict adherence to the letter of formal change control, with all the attendant information gathering and approval cycles, is costly. In this world there is no such thing as a small change because of all the consequences have relatively far-reaching effects and costs.

So in the informal model both the technical personnel and the project manager operate with greater flexibility within their circle of trust. As has been documented elsewhere here, developers will make unapproved changes without engaging Change Control if their risk is low. This can be a problem when the developer does not fully understand the risk and underestimates it. This can and does happen. The project manager will recognise it and seek to limit the damage because we absolutely don’t want anyone above the level of PM sniffing around at this level commenting on unapproved changes. However, for anything above a trivial change one hopes that the developers would seek the advice of the PM before making such changes.

Here is where the natural balancing act comes into play for PMs. Yes they know they may not allow changes through without going through Change Management approval. But they also may know that this will involve greater time and cost or even just a lot of painful hassle for all, with no clear benefit. A PM may sometimes, under these circumstances, allow a change to proceed “under the radar”. But the PM will also know that the buck for that stops with them and if the wheels fall off the wagon then they will have to take the responsibility for it. So the PM will probably think long and hard about it, and take several options into accounts. The point is to balance risk against reward and, in my opinion, it takes considerable PM experience coupled with domain experience before you get this right. Most PMs will have the scars from earlier in their career when they allowed through a “simple” change which then grew arms and legs, failed in testing and ended up breaking the budget to put right when it shouldn’t have been allowed in in the first place

Anyone that denies that the informal level exists is either incorrect or they exist at a level that just doesn’t see it. Any PM knows that they have to be in the loop of the informal level and will play the game of give and take it requires. If a PM is not in that loop then life will get very hard for all parties.