I really don't recommend that you get a book to read about the agility; it will be a contradiction to read a book as long as the Agile methods emphasize working software as the primary measure of progress. It is better you spend the time understanding your working environment and maturity to apply the best process that can fit with it.
I lived a similar experience with eSpace when they were aiming to get a CMM certificate, CMMI or whatever they will call it after couple of years.I think that finally the people here got the good decision by putting this plan away, and put their own standards, the standards best fitting with their teams and their environment. I doubt their was a need to some white collar guy to supervise our documents and our working styles to decide whether we fit to Mr XYZ standards or not. I also got the chance to meet some guys from another company having this certificate. What I found is that they modified their hierarchical structure just to accommodate the standard although their team wasn't capable at all to support this hierarchy.
Anyway, let's move to another point...
When we talk about the agile process we should identify very well any possible limitations before adopting it. It is very clear for me that it needs mature people, and this can be considered as one of the limitations.
Another factor that may limit the agile adoption is the "distributed software". Lately all our projects are distributed. Customers are from Europe, USA, Gulf. Developers are working remotely from different areas.
What are the challenges behind such distributed agile work???The answer of this question can be summarized in knowing that agile methods mainly rely on informal processes to facilitate coordination while distributed software development typically relies on formal mechanisms.
Challenges in Agile Distributed Development
- Communication need vs. communication impedance: How can we achieve a balance in formality of communication in agile distributed environments?
- Fixed vs. evolving quality requirements: the Agile relies on ongoing negotiations between the developer and the customer while Distributed Development often relies on fixed, upfront commitments on quality requirements.
- People- vs. process-oriented control: We appreciate the people-orientation the most.
- Lack of cohesion: Generally speaking about the distributed environment, people may feel In distributed development, participants are less likely to perceive themselves as part of the same team when compared to co-located participants. the agile adds some more excitement to it :)
Practices
- Process Refactor: Continuous process adjustments instead of following strictly the agile practices. It is also recommended to document the requirements at different levels of formality.
- Knowledge Spreading: the team should share their knowledge regarding different domains(business, code, test cases..etc). Alot of tools were developed to reduce the overhead of knowledge-sharing activities. Code/process Repository is a must. the Wiki also is a very important way to share the How-Tos between members. I can't neglect the Bugzilla with its role in creating database to help teams report issues and assign priorities.
- Short Iterations: any iteration should not exceed 2 weeks. short iterations help to detect any misunderstandings for the project business and prevent any time waste.
- Start with well-understood functionalities: In order to create the best atmosphere for developers there should be a solid sand to start to be familiar with the processes, tools, and the application. this can be some kind different that the agile which advocates the development of features prioritized as critical by the customer.
- Improve Communication: Synchronized work hours are very important for the team. Also try to make the informal communication be done through formal channels. for example, let it through the emails so that it can be archived. In the distributed Projects it is recommended that the project leader/manager should be involved in the communication and the synchronization process than the Agile practice. finally, some daily mechanisms should be done to maintain minimal communication like morning online meeting.
- Building Trust: trust involves both the team and the customers.
References:
1. Ebert, C. and Neve, P.D. Surviving global software development. IEEE Software 18, 2 (Mar./Apr. 2001), 62–69.
2. Highsmith, J. and Cockburn, A. Agile software development: The business of innovation. IEEE Computer 34, 9 (Sept. 2001), 120–122.
3. Matloff, N. Offshoring: What can go wrong? IT Professional (July/Aug.2005), 39–45.
No comments:
Post a Comment