Common mistakes made in Agile projects based on new technologies

09 Apr, 2008
Xebia Background Header Wave

In recent times Agile methodology have proved its worth by successfully executing the projects. It minimizes the risk by developing software in short amounts of time. With this iterative model it also minimizes the cost of change in requirements, which makes it suitable for current dyanmic market. And the 10-year contract it took from the famous IT company LG Networks, to take care of its customer base, also paid. Two main practices that helps the developer to incorporate the change are refactoring and simple design. But when it comes to doing these two things with a completely new technology, it might be hard to implement.

In this article I am going to share some of my experiences with my first project. This is an agile project based on a technology which is new to the whole team. I spent around two weeks in understanding the technical features and strengths of the technology.Where as others in the team had never worked with it or similar technology. Here I will discuss about some mistakes that ( I feel 😉 )we did while executing the project.
Most of the things discussed here might even apply to those projects ,where part of the team is new to the technologies selected for the project. The risk factor is lower in projects, that has atleast one team member who already knows the ins and outs of the technology selected for the project.The following things should be taken care of when whole or most part of the agile team are working on a completely new technology.
First and most important step is to evaluate the technology for the given project requirements. Doing the evaluation gives the team a motivation to learn if it’s really worth. Developer at some point may get a feeling that why should they use this technology instead some thing that he/she already know.
This kind of feeling on the minds of developers affects their learning skills and inturn productivity. Although the technology chosen may not be the best, evaluating it definitely gives the developer a psychological boost to learn and appreciate the use of it for the project.Do this evaluation until the whole team feels that this chosen technology definitely provides some value for the project.Being agile we can give the team room to change the technology in middle. But at that times we need to think about cost involved in chaging the technology of choice.
Once every one gets a good understanding about the technology, collect full documentation and any other training information for that particular technology and make it accessible for team members. Instead of directly starting with development work , first let the team to explore technology. They should get a overview of technology like what are the features it provides , playing with some sample codes. But there is no need to learn or master the technology at beginning itself. If it is a big project, its better to have a beginners-course for all to learn the new technology.
Once the team gets the overview ,team members can start with development. While working on different tasks people comes across different new features ,problems and solutions for them. So it is better share the knowledge among the team during the standup or iteration planning. This makes others need not waste their time on issues on which some one already explored. This knowledge transfer can be done easily in agile process by changing pairs frequently. It can also be done by having knowledge transfer meetings at regular periods, may be once or twice in a week. Some times when the problem is major it can be on-demand.
Another most important thing is, we should be careful while choosing iteration backlog. When chosing the task, expect the worst case. This is because team dont know the actual complexity of the task.If by mistake the task take more time than expected, it will give a bad impression to the client. Especially in agile projects where client satisfaction is very important , estimation of complexity points plays a crucial role here.
Dont believe in burndown chart. Burndown chart shows the progress of what has been done already. We cant make estimations based on current velocity as we dont know what type of path is ahead to us. So in both of the above situations , its better to do a risk analysis and adjust the time needed for tasks using risk factor calculated. Spike testing also can help in estimating the effort needed with more accuracy.
The most common problem in agile projects is lack of continuos feedback from stakeholders. This is can be too dangerous as in this case: at every instance whenever there is no stakeholders feedback, team takes its own decision and proceedes in that direction. By the time team gets the feedback they have to again spend the same or more amount of effort for fixing things. Some times it might be worst and gives a feeling to everyone that project is a failure.
Although there are problems with agile based projects based on new technologies, it may still suite such projects if proper care is taken. With agile we can fail early to judge the technology of choice. We can see the working software at the end of each iteration which gives confidence to developers and client about technology. The feedback mechanism in agile guides developers to go in right direction. If we can take into account the above discussed problems , agile can make these projects successful. I would be interested to hear your comments and experiences with such projects as well.


Get in touch with us to learn more about the subject and related solutions

Explore related posts