I went through the posts in this thread, not sure if I get everything. And thank you Adrian for your response to me in another related thread! I read the 3 articles you recommended, tried to discuss it with my coworkers here and have been trying to read some articles about Agile methodology. I know I may still have a lot of principles of Agile that I have not got yet. Here are some of my thoughts in those several days. Any opinions are appreciated.
1. Collaboration
I am all for more interaction and collaboration of business and development teams. I guess that is also one of the kernels of Agile. I actually think for any projects, no matter which methodology the project adopts, both IT and business sides should work together as more as possible. Programmers should be able and allowed to talk to business representatives or end users directly to get information s/he needs. One of the main reasons for failed or not-so-successful projects is lack of communication and involvement of business and end users. I guess the problem and reality for many projects is company can not afford to collocate and have the business team and development team sit together. Or even if they are physically at one floor or in the same building, business people can not allocate that much time for different IT people to constantly ask questions or they repeatedly answer the same questions. In this case, the more traditional requirement collecting methods might still be the main approach. Having said so, Agile approach does remind those more traditional practitioners including myself, that the importance of more collaboration and involvement of business users. From our IT side we, BA/BSA in IT team, need to present end users the detail requirements, functional specs, mock screens, and not-so-final-yet application periodically and more frequently to get their feedback, to make sure the application which IT team is developing is what they want as early as possible and as much as possible.
2. Change Request Control
Now another piece of thoughts come to my mind. When we have more interaction with business, mostly likely they would have new ideas or even contradictory thoughts on previously agreed requirements. Should we still have change request control? For Agile approach, it seems that the change request control is not as important as traditional methods. I agree that in order to save time, depending on the severities and influence, not all of the changes need to go through the whole formal and slow process. But I still think for most changes, a centered person or team (ex. BA) should be responsible to analyze if necessary, decide and control, in order to make sure the change is within the scope, within timeline, within budget, consistent within the system and not affect the architecture or infrastructure of the system. And also I think all changes, although it might not need to go through formal Change Request Control process, still need to be documented; related requirements need to be updated.
3. Detail Requirements
Now my 3rd piece of thoughts. Maybe I miss something here, I am not sure if I agree with Agile principle on that detailed requirement or functional specs are not as necessary or costing time. Detailed requirements are actually very important in terms of application maintenance, getting common understanding among all parties, etc. If we don’t do detail requirements or do very little, it might save some time at the beginning and developing stage, but it causes a huge time wasting for later maintenance, and easily causes communication confusion, especially after years’ running and possible turnover of resources. This is also one major cost for many projects to do the as-is model when it needs to be upgraded. So it is better we spend some time right now when we have better and clearer information to document, rather than some people spend much longer time to figure out what it does many years later.
4. User Stories or Use cases
Similar to my 3rd piece of thoughts above. I understand for most users it may be just easier for them to understand user stories. I think it is OK to use either user stories or use cases to communicate with business users, or to use user stories as the 1st step, depending on the project’s management and business analysis process. As I mentioned above, I think we still need to use detailed requirements or functional specs to define how the system should be working. Also I suggest presenting detail requirements or functional specs to business users including screen mockups, although some users might not be patient enough to read though. I especially like to show them the screen mockups since I believe screen mockups give them a better and direct vision of the system; and it is also a good chance for them to verify the system.
5. Finalized Requirements
Lastly, I like the idea from Agile that we can not wait until we get the “finalized” requirement to move to next phase. After a certain point, we need to start our system designing and coding. Changes could be done with a more flexible change request control.
To wrap up, I think we can adopt some agile idea to improve our current process or a certain period of process of software development. Waterfall can be more agile. But at least for now I am not sure if all projects at current stage and in current environment can purely adopt Agile methodology.
I appreciate any comments from anybody. I would appreciate more if you would also like to correct my English and tell me some better ways to express. :)
Thanks, - Irene