Category: Agile

Cost is one of the important corners of the Project-management triangle. This factor is especially important for decision-making from business perspective.

Let’s look at one of the techniques that will help us take more informed decisions about various operations we as developers do.

Consider a scenario when we have to automate the deployments in your project. One natural approach these days, is to automate everything. But let’s take a closer look at the things more closely.

Let’s put some numbers on a graph. On the X-axis we have the percentage of automation done in the project and on the Y-axis we have the cost needed to automate it.

Let’s put one more graph on it, that of “doing things manually”, indicated by green curve.

As it turns out, the cost of doing everything manually is too high. It would require a step-by-step manual intervention many personnel (typically Devops). So if we have 0% automation in our project, the cost of doing everything manually is quite high.

On the other hand, the cost of automating everything, every single step is also high, since doing this will take a considerable amount of time and effort for developing it. (indicated by orange curve)

However, if everything is automated, the cost of doing deployments manually tends to be zero, we can deduce this by comparing the curves.

Now let’s do something interesting. If we add the values of these 2 graphs, at every single point, we would get a curve of something like this (indicated by dotted red curve)

This red U-shaped dotted curve, indicates the total cost if the deployments are done in combination (manual and automation). As you can see the cost tends to be minimum at Point(X,Y).

We can therefore infer that you should:- “Automate X parts of the system by investing Y amount in it“.

Why is this statement important?

Simple, cost. You don’t want to overspend on one particular aspect of the project. Instead prioritize things, (which in this case is X %) and automate them first. And then if you have time, money and will, go for the remaining (100-X)%.

Find your minimum dropping point. It could be way off on either sides. But having a rough idea of where you stand, can help you optimize your business.

Please note the above curves are approximations for explanatory purposes, the actual values may vary, scenario-to-scenario, team-to-team…..

This technique can be used in many other decision-making processes, such as “How much code coverage should we have?”, “How good product quality we want?” and so on…..

The most important part in this thought process is “Prioritization”. Do not plan big upfront. Instead, go step by step. Look where you stand after regular intervals and then do course corrections accordingly. After all, that’s what “Being Agile” means….

On Friday morning, Shrikant, the Manager, came to Naveen, the software engineer, asked about “Password reset functionality”.

Naveen had implemented the “Password reset functionality” using test-driven development and replied to Shrikant that he had checked in the code into TFS.

So, Naveen with a great smile said: “Yes, the feature is Done“.

Shrikant was happy and said “nice, let’s deploy it into the staging environment for client’s review”.

However, Naveen was hesitant and looked doubtful since the use cases and the code was not reviewed by another developer and QA was still waiting for his turn to verify the functionality in QA environment.

Ah! Who is responsible for this situation. Who is right or wrong?

You may come across such a situation.

This situation may occur because everyone (developers, reviewer, QA, and product owner) could have their own version definition of done.

One person, ‘done’ may be ‘deliver a feature in production with ZERO bugs’.

To me, it will create use cases, prepare the design, follow TDD practices and so on.

To the product owner it may  be “meet the need, get it verified against business rules”.

Remember the definition of done is a comprehensive checklist of necessary, value-added activities that establish the quality of a feature.

Below is sample definition of done:

1. Prepare use cases that will cover use needs.
2. Write code that covers all use cases.
3. Peer-reviewed (or produced with pair programming) and meeting development standards.
4. Unit tests are written and passing.
5. Builds without errors.
6. Code checked into TFS/git source control.
7. Deployed to test environment and reviewed by QA.
8. Passed UAT (User Acceptance Testing) and signed off as meeting requirements.
9. Any build/deployment/configuration changes implemented/documented/communicated. (Database changes etc.)
10. Relevant documentation/diagrams produced and/or updated.
11. Remaining hours for the task set to zero and task closed.

To avoid above situations (mentioned in the first paragraph) in the team, it is very important that everyone knows and follows guideline mentioned in the definition of done that was created by the development team and product owner so that features get delivered completely with good quality.

https://blog.beingcraftsman.com/datta/