My grand daughter, who is 5 year old, operates my Samsung note better than me. Contemplating on why is it so – I spend almost couple of hours on note everyday myself – I realized that what makes her better is her childlike curiosity.

This curiosity to learn something new, day after day, every day.   When was the last time you learnt something new?  When was the last time you took a conscious step towards self-development? Curiosity to learn something must be backed by an innate desire to improve oneself, to become the best version of ourselves. It is the only way to remain relevant in the hyper-competitive markets today.

The same concept should be applied in the Agile projects, we are always running after getting the user stories done and churned out for the product owner. Yes, this is required, but one should step back and take a different view, are we learning anything new, have we added value to our existing knowledge base, are we much better skilled as compared to the start of the sprint, can we proclaim that we now know a trick or two.

When speak of adding value to our customers, shouldn’t we not add value to ourselves, as we are the first customers to ourselves

We always talk and speak about the improvement in velocity and team work, that cannot happen automatically, the organization needs to invest in this area, by providing and allowing a time-box element to each and every member of the team, I recommend a time-box of 5-10% of the sprint time allocated to each team member of the development team (on a different thought, it should include the scrum master and the product owner also). If the sprint cycle is 2 weeks (10 days = 80 hrs.), then the minimum time-box would be 4 hrs. / sprint to a maximum of 8 hrs. / sprint.

Organization should be aware that providing this time to learning and development will reduce the velocity in near term, but there would be major impact in terms of quality, knowledge gain, productivity improvements, team collaboration.

This time allocation should be used by the team members to improve their skills in any area of their interest, which would ultimately help the product to develop and grow better and thereby improve the required velocity. It should be the task allocated to the Scrum Master to ensure that all the team members are using this time-boxed element in the most productive way. One also needs to understand that a Scrum master would also be required to improve and master the skills that are important to the role that he / she is playing to.

Each sprint , the team should have a dedicated time and name it as – ‘Learning with Agility’.
• Define a dedicated time slot. It would be a good idea to have a time slot of 4 hrs planned in the early part of the sprint cycle in week 2
• This week, every sprint, learn a new thing – pick up a functional skill from a colleague, or improve the product knowledge, master an automation tool, learn new elements of coding (do a little unsaid spike)
• learn about a behavioural skill

Learning is not about mastering the hard skills, it includes all those elements that make you a better team member, a team player and more so a better person

Your learning is in your hands and you are the product owner of the product that is you. Take advantage of the fact that you spend 8 hours every day most of the week in an organization that promises you learning opportunities. You have, at your fingertips, access to a whole host of behavioural learning through social media , hundreds of thousands of articles in web, , ride the huge wave of Massive Online Open Courses with the many courses that are available online freely – make use of all these resources to better yourself today.

The above mentioned are but a few of the avenues for learning. Such platforms are present everywhere – the internet, libraries, even in day-to-day interactions with colleagues, it’s you who has to take the first step.

At the risk of re-iterating, I’d say again – that the onus of your learning lies with you. No one can help develop you but you yourself. This week and for the ones to come, promise yourself a week full of rich learning.

The day you stop learning, is the day you stop practising Agile ….. So Learn each day and be agile every moment

You are reading this blog for two reasons. First, you are a tester / developer. Second, you want to be a better tester / developer. We need better testers and developers in our small little world

If you have been a developer for couple of years, you have probably been significantly slowed down by someone else’s messy code. If you have been a developer for longer than two or three years, you have probably been slowed down by messy code. The degree of the slowdown can be significant. Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added. Over time the mess becomes so big and so deep and so tall, they can not clean it up. There is no way at all.

Better Test would have aided to prevent the above stated problem to some extent , but cannot prevent it completely


Clean tests follow five other rules that form the above acronym:

Fast Tests should be fast. They should run quickly. When tests run slow, you won’t want to run them frequently. If you don’t run them frequently, you won’t find problems early enough to fix them easily. You won’t feel as free to clean up the code. Eventually the code will begin to rot. For these reasons, your test should be automated

Independent Tests should not depend on each other. One test should not set up the conditions for the next test. You should be able to run each test independently and run the tests in any order you like. When tests depend on each other, then the first one to fail causes a cascade of downstream failures, making diagnosis difficult and hiding downstream defects.

Repeatable Tests should be repeatable in any environment. You should be able to run the tests in the production environment, in the QA environment, and on your laptop while riding home on the train without a network. If your tests aren’t repeatable in any environment, then you’ll always have an excuse for why they fail. You’ll also find yourself unable to run the tests when the environment isn’t available. E.g. Have the same tests run across different browsers on different machines

Self-Validating The tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell whether the tests pass. You should not have to manually compare two different text files to see whether the tests pass. If the tests aren’t self-validating, then failure can become subjective and running the tests can require a long
manual evaluation.

Timely The tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test. You may decide that some production code is too hard to test. You may not design the production code to be testable.


It’s not enough to write the tests well. The tests has to be kept clean over time. We’ve all seen test rot and degrade as time passes. So we must take an active role in preventing this degradation.

It is always important to remember, that job of a tester is always to prove that the programs / SW is not working, but the current thought process of our testers is not in the same line.

The concept of 5 developers to 1 tester is never understood by me (may be I am less educated), it is important to note that testers require to think from multiple angles , that of the business or from the developers view, of how the code would have been written.

The concept of 5:1 ratio is a gross mis-match in our industry, It is important to note that testing can only confirm the presence of bugs and the absence of it.

We have barely scratched the surface of this topic. Indeed, I think an entire book could be written about clean tests. Tests are as important to the health of a project as the production code is. Perhaps they are even more important, because tests preserve and enhance the flexibility, maintainability, and reusability of the production code. So keep your tests constantly clean. Work to make them expressive and succinct. Invent testing APIs that act as domain-specific language that helps you write the tests. If you let the tests rot, then your code will rot too.

Keep your tests clean.