I have been posted the similar questions again and again during my training; here are some of them that I would like to share. Perhaps there is better answer to them, which I wish to hear from the community.
Q. How would the payment be made, when the contract are drafted with water-fall payment milestones?
- This is a tricky question that I have been often asked about in a system integrator environment. Right now, I could only think of water-scrum-fall as the obvious answer. Since all payment milestones still base on the waterfall stages (Requirement Specification Sign Off, Design Specification Sign Off, Development Completed, User Acceptance Test Completed and Project Sign Off). I think we have no choice but to produce detail requirement specification, be it in product backlog format or modified version of product backlog version. Convince the customer to sign off the document but still allow them to change the scope. Collect sign off on User Acceptance Test at each sprint review session, use them as supporting document for the final UAT sign off document for payment collection. Likewise for the other documents which you need for invoicing your customer.
Q. How do you perform support?
- There are two common way to handle this, one is to have a separate team handling all the support. Or get the project to perform production support after the release. Either way you need to make sure this arrangement is made with the consensus with the customer before the start of the project. If you plan to have a separate support team (either new recruit or using existing support team from your company), I will encourage you to include them during the project, which means you should recruit the support team member at the same time you recruit your project team member. If you are using project team for the support, then the velocity planning from release 2 onward would need to cater time for the support activities. It is not wise to delicate certain member to fully in-charge of support tasks, the whole team should take up the responsibility of support to encourage the collective ownership.
Q. How to use Agile in the production support?
- If it is a pure support environment where you have no product backlog to plan for release or sprint, you can just use the Kanban board to manage the priority and tasks. Being Agile also means you should understand each methodology under the Agile umbrella and use them according to your situation. Each methodology carries their own strength and weakness, it is important you understand them. Key element about Agile is adapting and responding to changes, to do that efficiently you must be knowledgeable.
Q. How to get customer commitment?
- This question is interesting, but it is common that if the customer does not understand what Agile Project Management is, they may not want to frequently review product that is half done or incomplete feature. I always advice my project manager or scrum master to educate their customer using this story. "You go to a tailor's shop to buy a custom-made suit. If you do not wish to participate in the trial process that the tailor invite you to, if it your fault or the tailor's fault when the suit does not suit you at the end of the day?” Personally I have not come across a customer who are not excited to participate in my project, after I explain the Agile process and how it could benefit them. Using a simple survey at each review session would help to encourage the commitment.
Q. How to perform detail estimation upfront in the tender bidding process?
- This would have to be done similar with traditional approach. I cannot think of a better way to get better initial estimate as all estimation are as good as guessing. You can further improve it with inviting more people to participate in the estimation process and using technique such as planning poker. However, do bear in mind that it is still guessing and maybe it will be a good idea to include buffer in each estimate. Having more people to perform the estimation would encourage a better consideration compare to traditionally done by a single expert.
Q. How to build high performance team in SI environment where project are short and project team resolved once project ended?
- You probably will not be able to do it within a project. This needs to be done at the corporate level to make everyone in the company high performance. In this case, you do not have to start from ground with whoever you gather for your next project. Another alternative is, try to invite the same team member for your subsequent project.
Q. Since Scrum promote cross functional team, how would the career path planning work?
- I believe Agile promote real professional or expert. A real expert should have the T-shaped skills. We should break out from our belief of scientific management since it is no longer applicable in knowledge industry. In the old industry, solo departmental skill increase productivity. However in knowledge industry, you cannot call yourself a true expert if you do not have broad knowledge on areas that are related to your specialized area. For example, if you are a tester, on top of continue sharpen your skill on all testing techniques and tools, you should also learn how project is being managed (learn to be a Scrum Master?), how requirement is being gathered (learn how to create Product Backlog?), how code is being developed (learn how to code?), how the system is being deployed and how support team perform their job. I doubt you can be a good singer if you do not know how to read a music script and play some instruments.
Q. How to perform appraisal for the team in Agile environment?
- This is a much debated topic in the knowledge industry, and I have not see a good conclusion. That leads me to think of, why is a performance appraisal needed in the first place? If we believe the explanation from Wikipedia, the goal of performance appraisal is to align the employee of a company towards the goal of the company, then I think we should do this the Agile way. Traditionally manager set KPI (Key Performance Indicator), normally the KPI will be reviewed either quarterly, half yearly or annually. In my opinion, this is no different from having a project vision (corporate goal), break that vision into project Epic (KPI for senior management), features (KPI for middle management) and then tasks (KPI for ground executives). The review should be done with higher frequent and be flexible to add or change in priority according to market environment changes. One of the side effects with traditional performance appraisal is, it is a score system and link directly to promotion, pay increment and bonus. I believe we have to eliminate this side effect, an employee who cannot perform the task well may means he/she is not contributing value to the company. In the lean principle, I think this is a waste. Company should find way to help him/her to be able to contribute value, by giving him/her opportunity to try it out in other area (department/company). Everyone should enjoy the same share of fruit if the company is doing well. Sounds too idealistic? I believe it can be done.
Q. What will you do when team member leave the team half way?
- Nothing. If you have practice Extreme Programming (XP) practices such as collective code ownership and pair programming, your pain level should be lower. However, you will still need to recruit new replacement and also manage your customer's expectation. Being honest and transparent will help here. There are suggestion that waterfall's comprehensive documentation could help more in this case, which I have to disagree. Reading someone's book will not be more efficient compare to attending the person's presentation. Imagine if you are a new member recruited to an existing project, would you prefer to be thrown a thousands pages of requirement specification and design specification and expect you to read by yourself, or have you attach to some existing team member and learn from him about the project. Which one would be more efficient and preferred?
Q. How to run your project using Agile method if there are other contractors also participate in the same project using Waterfall method.
- If this is the case, most likely the entire project is also run using Waterfall method, otherwise the other contractors can not use Waterfall method to cope with Agile schedule. It is very much like any other normalization, the faster side have to slow down to be in sync with the slower side. The only thing you could do is try to decouple the tasks between your team and the Waterfall team as much as possible, which in reality it is very hard to achieve.
No comments:
Post a Comment