Great Expectations
A lot of participants in my training workshops ask me about the fastest way of deploying Agile ready teams. But the question that has by far stumped me the most is: What are the Agile Best Practices that my team can “quickly” learn, implement and succeed?
While going Agile is certainly a good way forward for any organization, the expectation of these organizations is to get the time-to-market as low as possible and guaranteed success the first time.
Some teams feel that knowing about agile concepts in theory, and learning the principles by heart is going to make them agile implementers overnight. There are many published success stories for companies that have gone Agile. A lot of attendees of my workshops believe that the same will work for their organizations too.
Hard realities
I strongly feel that in the case of process of going Agile, ‘best’ practices can be misleading. There are practices that work for many but in several situations they fail miserably. That being said, let’s have a look a few of these hugely popular agile practices and see when they apply and when they might not be that successful.
Test Driven Development (TDD):
TDD relies on the repetition of a very short development cycle. At first a test case would be written to define the desired requirement (in a user story). The next step would be to write minimum possible code to pass this test. This makes the developer think about the requirements and functionality before actually writing the code. This is a deviation from the usual waterfall model where Unit and system test case are written after all the code is developed. The code is continuously improving in TDD.
TDD might not be a good fit for highly complex algorithms that tend to change too frequently. This would mean the code would need continuous tweaking for every additional or change in existing scenario. Also in some cases where certain UI elements or CSS need to be incorporated, TDD can be an overhead and difficult to implement.
Programming in Pairs
Pair Programming as the name suggest is a practice where two programmers work together preferably on a single workstation. It usually consists of an expert and a novice, although this is not set in stone. Pair programming will have an active developer who would write the code while the other is an observer. This practice has evolved from the age old idea of “You will never notice your own mistakes in code” or software terms “Peer reviews”. Here the peer review goes hand in hand with the development process which will ensure better code quality than two programmers working separately.
While agile highly advocates co-located teams, if this is not a possibility, Pair Programming might not be the right fit. Also for pair programming to work, the team dynamic should be such that it favors appreciation of mutual feedback.
Continuous Integration (CI):
CI is a practice of merging all working code to a single code repository or build; one to several times a day. CI was developed as a part of the Extreme Programming (XP) Framework. It was added as a practice to avoid any build integration issues. The justification is that if the code is integrated into a build several times before the final build, it will not lead to any last minute integration issues. This requires teams to adopt Version Control (maintain a shared repository), automate builds, adhere to a baseline, and test in a sub-prod or clone environment.
Continuous integration might not work for teams with very, very large number of programmers. Sometimes when code gets red-flagged by the master build, teams learn to ignore some of these over the course of time; not having the time to fix all the errors. Moreover product owners might not understand the severity or the urgency of fixing integration problems if they see a working product on the UI.
Evolve with Agile: Create your own “BEST” practice
Agile is as an empirical process. And the agile principles emphasize this simple fact. Teams and organizations that have been successful in going Agile have not done so overnight, or even during the course of several projects. Agile depends on experimentation for the most part. There will never be a single process, method or practice that will work for two teams or even two projects in the same team.
Start small. And build from there. Stick to the base frameworks like Scrum, Scaled Agile Framework (SAFe®), etc. and believe in the philosophy that is Agile. That’s all it takes.
Be Agile, Scale Up!
About the author:
Vineet Patni is the Founder and Principal Consultant at ScaleUp. An avid learner and a passionate facilitator, Vineet has been assisting enterprises and individuals in becoming truly Agile. Check out his upcoming workshops @ http://www.ScaleUpConsultants.com/events/ .
Please feel free to connect with him at [email protected].
Disclaimer: The opinions expressed in this post are the author’s own. The author welcomes and respects any difference of opinion.