I just read an article posted in Scrum Alliance, by Patrick who thinks otherwise. However, I strongly disagree with his point. Perhaps due to both of us working in a similar environment (development efforts provider) provide me an opportunity to better understand where he is coming from.
I have coached a few Scrum team, all of them are very new to Scrum Framework, some may have individual member who have previous Scrum experience but not the entire team. In each team, I have always insisted the Product Owner role to be played by the client side. Preferably from the same person, who sponsored the project, however this is always difficult because the project sponsor are always too busy to commit themselves into this role.
I always use the metaphor that if you want to buy something that is highly customized, and you are paying it, would you want someone to decide every single detail on your behalf? Or you would like to be able to make every single design decision by yourself? Who can know what you want better than you? If you are too busy to make all those decisions by yourself, won't you entrust someone who you know better on that role than let the supplier decide?
In my cases, I experience the following benefits when Product Owner role is played by my client representative. I focus on coaching the person to be a good Product Owner (CRACK)
C: Committed (to the team, the project and the business)
R: Reliable (has time and is available when needed)
A: Authorized (can have the final decision and can have it fast)
C: Communicative (knows how to bring the message across)
K: Knowledgeable (needs to know what it is all about)
Benefits:
1. Client feels that they own the project
This is one of the key reasons why Scrum advocates the user to play the role of PO. They should not throw the responsibility of the project over the wall. With the PO create and maintain the product backlog, direct the team on what to build on each Sprint, decide on the product backlog priority, it give them the feeling of ownership of the project. It also make the communication of the project status and certain decision making reason easier in the client organization.
2. Client enjoy the transparency and hence difficult project decision are made easier
Having the PO from the client side also encourage transparency, hence there should not have many surprises when a challenges (technical / non-technical) pops up. Should a particular user story needs more efforts that could impact the project budget and schedule, that decision was made easier with the PO having full information and visibility to it.
3. Better team spirit
You really want to eliminate the feeling of vendor vs supplier within a project team. The project team (PO, Scrum Master and Dev Team) has only one goal, i.e. to make progress to the project. Having PO from the client side will eliminate a lot of unnecessary political red tape along the way. Make all them temporary forget which company they draw their salary from will encourage them to make decision that benefit the project.
Monday, February 17, 2014
Tuesday, February 11, 2014
Programmer - Asset of a software company
Unfortunately, many business owners actually think the same as the CFO. There are still many company treat source code as their sole intellectual property, this is a misunderstood concept by the non-technical business owner.
A software company can still function without all other roles (Sales, Admin, Finance and etc.), but they cannot call themselves a software company if they do not have any software programmer. Hence, I think it is fair to think that software programmer is the asset of any software company. The source code is a side effect or by product.
If you ask any business owner, would you like your business assets to increase in value, or decrease? I am sure they will look at you as if you must be really silly to even ask such question. However, if you ask them again, do they have any process in place to make sure their software programmer attending training, or even allow to attend any skill enhancement program; they probably will say no. Is this not weird? I have seen most company have the process that their software programmer needs an "approval" to attend training, let alone having hours set aside every week to perform self-study. Why would you create a process to prevent your assets increase in value? Do you think like the CFO in the quote above?
Thursday, February 6, 2014
Budget Calculation for Agile Project
This has been one of the most widely ask question I have encountered. How to perform budget calculation for Agile Projects where scope is variable?
I can understand why businesses would like to know how much it would cost them for a particular project. They will feel more comfortable to know their "risk" or investment boundary. While I always reminded them that they should focus on both Profit & Lost of the project rather than just the cost alone, I do share with them some approach of Project Investment model that they could consider.
1. Using the traditional way of project budgeting, while in traditional project budgeting where they need to dive deep to get accurate estimation, they should just stop at high level estimation and apply some extra percentages for buffer. For example, they should be able to derive some guesstimate at the feature level. First by determine number of feature they wanted to build, estimate efforts for each feature, apply 30% onto the estimation as buffer. They do need to remember that they need to allow the scope to change and hence not all features may be built when they the budget is finished. They need to make decision to trade off feature for every change.
2. Extension to the method above, the business should make decision after every release. They could just approve the budget for first release, at the end of first release; they then decide again the budget for the next release. In this case, they do not have to approve a big amount up front for the entire project. This would help better cash flow control of the company. With Agile project management, it allows the business to have early release compare to traditional approach. The business could then use the feedback gather from the release to decide the budget for the next release.
I can understand why businesses would like to know how much it would cost them for a particular project. They will feel more comfortable to know their "risk" or investment boundary. While I always reminded them that they should focus on both Profit & Lost of the project rather than just the cost alone, I do share with them some approach of Project Investment model that they could consider.
1. Using the traditional way of project budgeting, while in traditional project budgeting where they need to dive deep to get accurate estimation, they should just stop at high level estimation and apply some extra percentages for buffer. For example, they should be able to derive some guesstimate at the feature level. First by determine number of feature they wanted to build, estimate efforts for each feature, apply 30% onto the estimation as buffer. They do need to remember that they need to allow the scope to change and hence not all features may be built when they the budget is finished. They need to make decision to trade off feature for every change.
2. Extension to the method above, the business should make decision after every release. They could just approve the budget for first release, at the end of first release; they then decide again the budget for the next release. In this case, they do not have to approve a big amount up front for the entire project. This would help better cash flow control of the company. With Agile project management, it allows the business to have early release compare to traditional approach. The business could then use the feedback gather from the release to decide the budget for the next release.
Monday, February 3, 2014
Young Software Product Company's Challenges on Scrum
The company is small and young, they are trying to build a product, after the first release, and they receive many "project" requests from almost every new opportunity coming in to them. The team end up throwing the Scrum out of the windows to fulfill every single request for each project. They are adding on technical debts and have no time to clear the debt.
Does this sound familiar to you if you are in a small software start-up? Balancing between product development and business development is a tough game. On one hand you are consciously aware that you should not turn your company into a System Integrator where every deal is a project and required significant modification to your product. You know that you are not charging the customer using the System Integrator rate, and you are fully aware that you will be forced to maintain separate code base for each "project". Hence the maintenance cost is much higher compare to normal product sales. However, you are desperate to have some reference account to kick start your business. What could you do?
Could we treat the project Change Request (CR) the same way as we treated the support request? In normal Scrum project, I will reduce the capacity of the team to take on new items from product backlog after the release. For example, I will only cater say, 70% of the team capacity (base on average velocity from previous sprints in Release 1) for task allocation in 1st sprint of Release 2. I will communicate with the Product Owner that the remaining 30% will be reserved for support activities. However, rest assure that the team will not stay idle should there have no support requirement. As a standard Scrum practices, team will continue to work on user stories on the next sprint if they had completed earlier for the current sprint.
In this scenario, I will make every CR for projects into a support ticket. In this case, they will go through the investigation phase, appear in the product backlog and etc. The Product Owner should then take those support case into their product design consideration just like any other support request.
Does this sound familiar to you if you are in a small software start-up? Balancing between product development and business development is a tough game. On one hand you are consciously aware that you should not turn your company into a System Integrator where every deal is a project and required significant modification to your product. You know that you are not charging the customer using the System Integrator rate, and you are fully aware that you will be forced to maintain separate code base for each "project". Hence the maintenance cost is much higher compare to normal product sales. However, you are desperate to have some reference account to kick start your business. What could you do?
Could we treat the project Change Request (CR) the same way as we treated the support request? In normal Scrum project, I will reduce the capacity of the team to take on new items from product backlog after the release. For example, I will only cater say, 70% of the team capacity (base on average velocity from previous sprints in Release 1) for task allocation in 1st sprint of Release 2. I will communicate with the Product Owner that the remaining 30% will be reserved for support activities. However, rest assure that the team will not stay idle should there have no support requirement. As a standard Scrum practices, team will continue to work on user stories on the next sprint if they had completed earlier for the current sprint.
In this scenario, I will make every CR for projects into a support ticket. In this case, they will go through the investigation phase, appear in the product backlog and etc. The Product Owner should then take those support case into their product design consideration just like any other support request.
Sunday, January 26, 2014
Common Questions from System Integrator in the Agile Journey
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.
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.
Tuesday, January 21, 2014
Agile Transformation - Product Company vs System Integrator
After having the opportunity to lead the Agile transformation in a software product company, I have an opportunity to join an Agile transformation team in a big system integrator company.
Here I would like to share some of my observation when come to Agile software development transformation, differences between a Software product company and an IT System Integrator (SI).
Motivation
While a software product company's transformation is mostly driven by being more productive and efficient in product development, a SI is driven by customer demand. However, traditionally most SI are making most of their profit from project's Change Request (CR), there is little motivation for them to be more efficient in software project (deliver high business value items first). A lot of them are forced to provide low quote during the project tender phase in order to win the deal. The CR is the only source for them to recover the cost and make some profit. However, with Agile being the trend and more and more customer demand arrived, SI will have to start preparing themselves to meet this new market demand.
Contract
There is little concern on contract in Software Product Company; most of the traditional form of contracts is just simply Product Requirement Specification and etc. between the product management team and the development team. However in SI environment, legal contract between Customer and Supplier is one of the key elements when come to Agile transformation. Agile contract strive to reach a risk sharing situation. Where traditional fixed price, fixed scope and sometime fixed deadline contract delegate all the risk to the supplier. There is always a struggle from the customer to start taking more risk. The biggest challenge in this scenario is, most of the Agile contract benefit are intangible. The supplier needs to find way to quantify those benefits to convince the customer to move to Agile contract type. While the sales person from the supplier side does not really welcome Agile contract because they could not be rewarded with the full revenue upfront.
Support
In a software product environment, the support is pretty straight forward. You set aside certain percentage of the available work hour from the team to cater for post release support. However in SI environment, they have to identify if the support is due to bugs or changes. This is especially true in a Fixed Cost per Iteration (a type of Time & Material Agile contract) contract environment; the customer is pay for the team's time. If it is a bug, the support cost should be bear by the supplier. There is always a challenge to identify this and efforts spent on identify each incident's category is sometime a waste when the goal should be solving the incidents as soon as possible and move on.
Team
In a software product environment, team were recruited for a straight forward purpose, i.e. to build the product for the market. Software Product Company could easily start recruiting team once they decided they need to build something. However in SI environment, until a project is rewarded, there is no certainty that the project is real. The moment a project is rewarded, the customer expected the work to commerce almost immediately. Hence it is very common to see team working on multiple projects at the same time. Which is again against the Agile advise to allow the team to focus, avoid task switching to minimize waste. It also has bigger challenges in building high performance team since all team only form when there is project, and before a particular team could reach the high performing stage, the project might have already ended.
Here I would like to share some of my observation when come to Agile software development transformation, differences between a Software product company and an IT System Integrator (SI).
Motivation
While a software product company's transformation is mostly driven by being more productive and efficient in product development, a SI is driven by customer demand. However, traditionally most SI are making most of their profit from project's Change Request (CR), there is little motivation for them to be more efficient in software project (deliver high business value items first). A lot of them are forced to provide low quote during the project tender phase in order to win the deal. The CR is the only source for them to recover the cost and make some profit. However, with Agile being the trend and more and more customer demand arrived, SI will have to start preparing themselves to meet this new market demand.
Contract
There is little concern on contract in Software Product Company; most of the traditional form of contracts is just simply Product Requirement Specification and etc. between the product management team and the development team. However in SI environment, legal contract between Customer and Supplier is one of the key elements when come to Agile transformation. Agile contract strive to reach a risk sharing situation. Where traditional fixed price, fixed scope and sometime fixed deadline contract delegate all the risk to the supplier. There is always a struggle from the customer to start taking more risk. The biggest challenge in this scenario is, most of the Agile contract benefit are intangible. The supplier needs to find way to quantify those benefits to convince the customer to move to Agile contract type. While the sales person from the supplier side does not really welcome Agile contract because they could not be rewarded with the full revenue upfront.
Support
In a software product environment, the support is pretty straight forward. You set aside certain percentage of the available work hour from the team to cater for post release support. However in SI environment, they have to identify if the support is due to bugs or changes. This is especially true in a Fixed Cost per Iteration (a type of Time & Material Agile contract) contract environment; the customer is pay for the team's time. If it is a bug, the support cost should be bear by the supplier. There is always a challenge to identify this and efforts spent on identify each incident's category is sometime a waste when the goal should be solving the incidents as soon as possible and move on.
Team
In a software product environment, team were recruited for a straight forward purpose, i.e. to build the product for the market. Software Product Company could easily start recruiting team once they decided they need to build something. However in SI environment, until a project is rewarded, there is no certainty that the project is real. The moment a project is rewarded, the customer expected the work to commerce almost immediately. Hence it is very common to see team working on multiple projects at the same time. Which is again against the Agile advise to allow the team to focus, avoid task switching to minimize waste. It also has bigger challenges in building high performance team since all team only form when there is project, and before a particular team could reach the high performing stage, the project might have already ended.
Thursday, January 16, 2014
My Project Manager Does Not Want Unit Testing!
When I first hear that from a programmer who attended one of my training, I was speechless. It is quick in my mind of what sort of software project manager would not want unit test in their project? When I ask further in what situation his project manager said that, the reply is quite expected. His project manager actually did not say explicitly he does not want unit test, instead, when he assigned the task to the programmer, no time is allowed for unit test. When I drill down further on who provide the task's estimate in the first place, he said it was from the team.
I come to a conclusion that this is what happen when the team does not have a Definition of Done (DoD) established in the project, before any estimation process. Hence when a project manager asks an estimate from the team, the estimate he often gets is just code complete. I have seen this happen all the time, both in waterfall project or even agile project. When DoD is missing.
When come to the task delivery phase, Project Manager is often under pressure to deliver according to the promise they gave to the customer. And they took the estimate from developer to make promise. In this case, how would it be a surprise that the task duration does not cater for any testing activities? Very often the testing effort is provided by the QA team, in this case, QA would only provide estimate for all other test but not unit and integration test, since that is not in their scope.
This is another lesson to show the important of DoD, be it you are running a project using waterfall method or Agile method. Making sure no ambiguity in the communication is always the key.
I come to a conclusion that this is what happen when the team does not have a Definition of Done (DoD) established in the project, before any estimation process. Hence when a project manager asks an estimate from the team, the estimate he often gets is just code complete. I have seen this happen all the time, both in waterfall project or even agile project. When DoD is missing.
When come to the task delivery phase, Project Manager is often under pressure to deliver according to the promise they gave to the customer. And they took the estimate from developer to make promise. In this case, how would it be a surprise that the task duration does not cater for any testing activities? Very often the testing effort is provided by the QA team, in this case, QA would only provide estimate for all other test but not unit and integration test, since that is not in their scope.
This is another lesson to show the important of DoD, be it you are running a project using waterfall method or Agile method. Making sure no ambiguity in the communication is always the key.
Subscribe to:
Posts (Atom)