From a collection of writings I wrote when I first got exposed to this methodology around 2007.
At the workplace, there has been a sudden impetus to adopt this methodology. Whether we like it or not, we would eventually have to adopt this as there is a tremendous push from the top.
Hence have been reading up some stuff and trying to relate it to apply it to my daily professional way of work. From what I have observed, I believe the methodology is promising. It would invariably help in the kind of work we do. Some of the inherent positives I see include:
But, I think there are going to be sufficient challenges for this adoption:
Bottom-line is that, it looks to be a good methodology to adopt for the kind of work we do (product development-enhancement-maintenance). But the adoption process is going to be challenging. I am planning to log my experience of that. So keep tracking this column.
At the workplace, there has been a sudden impetus to adopt this methodology. Whether we like it or not, we would eventually have to adopt this as there is a tremendous push from the top.
Hence have been reading up some stuff and trying to relate it to apply it to my daily professional way of work. From what I have observed, I believe the methodology is promising. It would invariably help in the kind of work we do. Some of the inherent positives I see include:
- The focus on the working software over extensive documentation - Most of the time documentation is out of sync with the software and is created more as a ritual than as a knowledge base.
- The incremental Development approach - Will provide better control and tracking of the projects.
- The collective responsibility on the team - I expect the peer pressures to build accountability to the members of the team and would hopefully helping setting higher standards for individuals.
- No changes during iteration - This provides sufficient cushion for the team to execute the committed tasks without hindrance and with certainty.
But, I think there are going to be sufficient challenges for this adoption:
- Resistance to Change - I think everyone would not willingly take to any new process. The F.U.D factor is going to play a big role during the early days of adoption.
- Politics - A new methodology is going to bring in changes in Roles and Responsibilities of different individuals. Not everyone is going to be game for this and hence politics is going to raise its ugly head. At least, at this stage, I believe the biggest antidote for this would be a strong sponsor, who can stand firm and enforce the process.
- Learning curve - We will begin by taking baby steps. We are bound to fall and learn. But patience should prevail. Every fall should not be used as an opportunity to tout the previous two challenges.
- Maturity of the team - From the look of it, the strength of the methodology lies in the concept of team work. The expectation is team is mature and skillful. Need to see how the behavioral aspects play out.
Bottom-line is that, it looks to be a good methodology to adopt for the kind of work we do (product development-enhancement-maintenance). But the adoption process is going to be challenging. I am planning to log my experience of that. So keep tracking this column.
Comments
Post a Comment