Likewise for Agile Software development methodology, I believe many Agile consultants forgot to emphasis the point that Agile is not a silver bullet. It can not perform miracle, in fact, with the concept of transparency, it always try to demystify a lot of misunderstanding regarding software development. Example of common magic where many non software people believe are: Multitasking improve productivity, The more time Programmer spent in front of their PC means higher productivity, Put more programmer into the project during crunching time could bring the project schedule back on track and etc etc.
Here I am sharing a few slides I used to explain the different between water-fall and Agile to those season project manager.
I will first start with something they all very familiar with, a water-fall project management process. We gather requirement (as if customer know exactly what they want, which is often not the case), insist on a sign off on the requirement specification before we start the next activity. At this stage, we may use a lot of prototyping, diagram, picture and etc to make sure we understand what the customer say. Then we proceed to the design, development and testing phases. Internally we make sure the developer design and develop according to the requirement specification. At the same time, we work with customer to identify the user acceptance test (UAT) criteria. Aiming for a smooth UAT session.
And then it come the big day, where the product is completed and tested internally. We prepare and organize the UAT session. Customer start testing the system using the acceptance criteria list, tick off one by one. However, how many time we have customer telling us something important is missing at this stage? That the customer refuse to sign off the project and proceed to Go Live because of the missing items? We started to explain and sometime argue with customer on whether the missing items were in the original scope or it is a change request. As the deadline for Go Live is already round the corner, tension is high in this discussion. (I would normally get a nod from the project manager at this stage of presentation)
The project budget have already spent, any additional efforts to make changes or add new functions become a tough decision. Most of the time, cost on these additional efforts would be split between the supplier and customer. Supplier may agree to perform some of these changes free of cost, while customer will raise additional fund request for other changes. Cost is an easier problem to solve compare to Time. Unless the Go Live date is postponed, there is very little time left to incorporate those changes. The team is again call to work overtime and naturally, the most intangible constraint is sacrifice. i.e. Quality. Most of the time at this stage, if the project manager has manage the customer expectation well, customer would understand these last min urgent changes would introduce quality issues. It may even cause some of the already built function to fail. It end up the important features are released with least quality.
Now, what if we could run our project this way? With similar cycle that they are familiar with, we run short iteration (I would tell them 2 weeks is just an example). We continue to do this until the customer feel they have enough features and functionality built to launch the project. One common question raise at this point is, would that not means too many change request at every iteration? I would explain that customer will be make aware that every change to already built features or function, some trade off needs to be made. However, if the change is something not built yet, that should not incur any additional cost. I will tell them that this is how Agile project management works, I could not cover all detail in this introduction. (My intention is to get their buy-in, understand Agile in the shortest time possible that it is not something totally new)
I will explain to them, all project would still have to face the 3 project constraints. However, the environment would be a bit different now. Customer could make sure most important features are built first while they still have sufficient project budget. Project manager would still expected to discuss with customer during each quick UAT whether the change request is a bug or new changes. However, because it is still at the early stage of the project, the tension will not be as high as before. Customer could also start to plan for fund request earlier if they realize the initial project budget could not buy them all important features. Since most important features are built first, customer would definitely have something to launch when the fixed Go Live date arrived. With automated regression test in place (continuous integration), the most important features are tested repeatedly with more test cases build for them in each iteration, the overall quality of the project would definitely be much better.
No comments:
Post a Comment