In the world of agile methodologies, we find ourselves facing a constantly-repeating scenario: teams that decide to become agile after more than 2 or 3 months of work.
Certain difficulties arise and need to be overcome in order to accomplish this goal. A few of them come to mind and I wanted to comment on these:
Understanding methodologies and their goals
The agile practices proposed by each methodology or process have a purpose: they attack particular problems and provide solutions to them.
It is vital toward correctly implementing an agile process that the team be accompanied by somebody with experience, who can interpret the needs of the project and its members.
If we talk about
Scrum, the role of ScrumMaster is necessary for correctly implementing the process. Many teams that decide to use Scrum designate a person from the team to be ScrumMaster and all they do is read a book and get down to work.
This is not always enough, it is possible that the person designated as ScrumMaster does not interpret the texts properly or that they draw erroneous conclusions based on previous experiences with non-agile methodologies.
In order to ensure a correct implementation, I absolutely recommend hiring a coach for a few months to train the team to work in an agile manner, and having the person designated to be ScrumMaster work alongside the coach during that entire period. One possible alternative (if hiring is not an option) would be to contact people from the local agile communities in gatherings or through mailing lists and describe situations that could be of aid to the team. Agile communities are generally willing to help simply out of love for agile practices.
Many teams fail at implementing Scrum because they lack professional help, and not only that, when they fail they are left with a bitter taste of Scrum and agile methodologies and they end up falling into the old and inefficient project organization models.
In short: hiring or at least keeping close at hand an experienced coach to guide you through the implementation of agile methodologies can determine the team’s success or failure. It is always important to participate in local agile communities.
Implementing continuous integration
Continuous integration is a set of practices that help toward the team’s efficiency and solve frequently encountered problems in a simple way.
Continuous integration may prove difficult to implement correctly if the team lacks experience. The recommendations from point 1 also apply to continuous integration.
Some of the problems and fears that I detected while talking to development teams mostly have to do with automated testing.
NOTE: I am going to take the liberty to use testing and automated testing as synonyms, but bear in mind that they are not the same.
Automated testing of applications is unfortunately not taken into account when educating developers. They are generally used to manually verifying that a piece of code actually does what it should do, which becomes impossible in large projects, resulting in regression problems and a great deal of bugs.
Testing helps solve this problem and is a vital organ in implementing continuous integration and, at the same time, is perhaps the practice at which most teams fail and flush everything down the drain.
It is common for projects over 2 or 3 months old to find themselves facing the dilemma of incorporating automated testing because the work implied by testing the code already programmed would stop development for a long time, which is unacceptable.
My recommendation for this scenario is fairly simple and it is based on the idea that something is better than nothing.
I propose that teams do the following: starting today, all new code must be tested. This will allow us to at least begin trusting our new code.
So what happens to old code? It cannot be trusted, clearly. But we can do the following: let us assume that old code works well, and every time the need arises to make a modification, we write tests to verify that piece of old code. This way, you will see how in a short time you will have achieved a very high coverage on the old code.
The experiences I had using this technique made me see that 2 or 3 months after starting to implement it, the application’s
coverage approaches 80%, which is not bad at all, and the best part is that there was no additional expenditure in order to reach this percentage.
I have a favor to ask: if anybody implements this, please send me your statistics. All I need to know is the initial coverage status and how long it took you to reach an acceptable percentage (75-90%).
Another issue that makes teams flush agile practices down the drain is the use of TDD. To TDD or not to TDD, that is the question.
TDD requires previous knowledge about test creation. Writing tests that verify the application (and satisfactorily at that) is not an easy task, not easy at all.
My recommendation to teams is that if you do not have experience in writing tests, then seek implementing TDD as an ultimate goal, undergoing an intermediate process in which you make it your business to learn how to write automated tests.
This process should not last longer than 2 months. Achieving familiarity with unit testing frameworks, understanding the use of mocks and stubs, implementing functional and integration tests is something that can take a long time. In fact, I am not too sure that you can ever learn it all, but it is not necessary to be an expert in testing in order to do TDD.
On the other hand, if we are not doing TDD, we have no way to make sure that ALL the important code in our application is being tested. In order to analyze this and detect possible lines of code that are not being tested, we can make use of coverage tools. Each language has its particular coverage tools, and it is up to the team to find one that they like and that suits their needs well.
Thanks marquete for the translation!
Then I recalled an old project I built in 2005. It was a regular polygon generator that used the n-th root of unity. The interesting thing about that project was that it generated an SVG using the vertices from the equations.
RSS
Twitter
Tumblr
Facebook
LinkedIn
MySpace
YouTube
