Is it a Defect or is it an Enhancement?

It is very common for software users to categorize every single unpleasant experience as a Defect.

With the same logic, it is also very common in Scrum project, that a Product Owner classified every things deem "missing" from a "Done" product as Defect.

For me, it is important that a Scrum Master, or an Agile coach to make sure this expectation is set during the project kick off. Recommend the usage of Extreme Programming method of user stories to capture requirements, emphasis on the important of acceptance criteria in the user stories. Make it a point that, any scenario that is not being thought of as acceptance criteria will be classified as enhancement. They will be added into the Product Backlog for prioritization and to be work upon. System behavior that does not match the acceptance criteria will then be classified as a Defect for the team to work on them as soon as possible.

The development team hold the responsibility to make sure all acceptance criteria in the user stories are handled. While the main purpose of the UAT is to discover more new scenario that the system needs to handle and add them as enhancement into the Product Backlog.

Avoid the situation where the development are encourage to make their own assumption and code them into the project, as there is high chance that those will be a waste to the project. All assumptions are to be clarified with the Product Owner before any single line of code is written on them.

Everyone in the Scrum Team should be encouraged to contribute to the acceptance criteria all the time. It will just make the product better.

Human Brain And Quantum Physics

I would like to share this youtube video, I have been very puzzled by people who does not accept reality and I guess some part of this video explain why. As one of Agile's key element is transparency, you will often come across stumbling block of people who cannot accept that they need more time to get things done. Those people would prefer to use traditional approach where the reality could be postponed.

Very interesting, indeed.

What to look for when hiring a Scrum Master?

A friend of mine just posted this question to me, and my answer to him as follow.

If your company has achieved high maturity level on Agile, i.e. When your company has embraced the spirit of Agile, and that you have enjoy all the benefits Agile can bring to you, you can dominate anybody with proper Scrum knowledge to be your Scrum Master. In those scenarios, the main activities of Scrum Master would be purely facilitating Scrum Ceremonies, remove impediments. Anyone from your existing Scrum team could take turn to play that role.

However, if your company is new to Agile or have some bad experiences in past "Agile" projects. It would be wise for you to engage an experience Scrum Master. Below are tasks that a Scrum Master need to perform, which I copied from Scrum Alliance.

1. "The ScrumMaster is a "servant leader" who helps the rest of the Scrum team follow the process. The ScrumMaster must have a good understanding of the Scrum framework and the ability to train others in its subtleties."
- This task is pretty easy to perform, as long as the person is a Certified Scrum Master, either by Scrum Alliance or Scrum.org, he/she should be ready to perform this task. A good Scrum Master would be able to explain the reason behind each component in the Scrum Framework. This is important for your team to tailor the process components to suit your environment yet still keeping the same value.

2. "The ScrumMaster helps the product owner understand how to create and maintain the product backlog. He or she works with the entire Scrum team to evolve the Definition of Done. The ScrumMaster also works with the development team to find and implement the technical practices needed to get to Done at the end of each sprint."
- This task would require an experience Scrum Master to perform it. First of all, he/she would need to educate the Product Owner, understand business language so that the Product Owner could appreciate why good product backlog is important to the project. The Scrum Master must not take over the creation and maintenance of the product backlog from the Product Owner. After that, the Scrum Master would need to understand the business good enough to guide the Scrum Team on developing the Definition of Done. There are many factors to be considered during this list, as business is always under pressure to deliver, certain technical debt would be unavoidable.

3. "Another responsibility of the ScrumMaster is to remove impediments to the team’s progress. These impediments may be external to the team (such as a lack of support from another team) or internal (such as the product owner not knowing how to properly prepare the product backlog). That said, the ScrumMaster fosters self-organization, meaning that the team itself should remove issues wherever possible."
- To perform this task efficiently, it required high level of people skill. He/She also needs to make intelligent decision on whether an impediment reported should be resolved by the team themselves or the Scrum Master should step in. This is not an easy decision, required a lot of experience to make this important decision right. If the Scrum Master remove all impediments by him/herself, then he/she is taking away the growing opportunity from the team, however if the Scrum Master pushes every impediments back to the team, then he/she is not serving the team right.

4. "The ScrumMaster may facilitate meetings and always acts as a coach for the Scrum team, helping it execute the Scrum process. He or she helps team members work together and learn the Scrum framework, and protects them from both internal and external distractions. The ScrumMaster keeps the Scrum team on track, productive, and growing in ability."
- On this note, one must be able to differentiate between facilitating and taking over.

5. "Ultimately, the ScrumMaster is responsible for ensuring that Scrum is understood and in place, inside the team and outside. He or she helps people outside the team understand the process and the kinds of interactions with the team that are helpful (and those that are not). The ScrumMaster helps everyone improve to make the Scrum team more productive and valuable."
- It is important for Scrum Master to understand the value between each actions in the Scrum Framework. Not to take them by the face value. Every project are unique in the environment and process must be tailored to suit the project.

Our education system has fail us

Afraid of failure, our school system never encourage us to make mistake and learn from it. We have exam system where you will be punished by your failure. Exam has turn from assessment purpose to punishing failure. That makes the whole system focus on exam score rather than the meaning of education. I came across this quote from Martin Luther King which I fully agree with.

The function of education is to teach one to think intensively and to think critically. Intelligence plus character - that is the goal of true education.

Martin Luther King, Jr.

The result? I do not know about other industries but I do believe our current education system is the main culprit of many failed software projects. Almost in every software project I stepped into, I have to undo the team's mindset which they inherited from the school. I need to educate them to think intensively and critically to every single decision, not be afraid of making mistake because that is the only efficient way of learning. Let me cite some examples of how this has affected successful project delivery.

1. Project Status Report
- Almost in all failed projects, the cause of failure does not due to a single incident that happened over-night. How would these "symptom" not being picked up by the project organizations that were involved in the project? In most cases, they were not even reported by the project manager in his status report. It can be certain that the team would have been aware of these "symptom", for example, customer keep changing mind, too many work that almost everyone need to work over-time constantly, the quality of the code is giving problem to the progress and etc. Project manager might think that to report these "symptom" will reflect badly on him/her capability to manage the project, hence they were ignored. They do not want to get punished for reporting the problem. While the management also graduated from the same system, they will indeed "punish" any project manager who reports such problem. The management did not create an environment to encourage those "symptom" being reported. If attention were paid to those "symptom", solutions will be generated and no one needs to face the consequences. i.e project failure. Our education system has turn the status report from an assessment to a score card, no one want to see bad things in the score card.

2. Refuse to clarify
- Be it traditionally or even with Agile methods, I still see many programmer refuse to clarify the items in the specification document or product backlog/ user stories. They are afraid that the clarification action will make them looks bad, hence they are making a lot of assumptions by themselves on what actually those requirements mean. Again, they treated the clarification event as an exam rather than an assessment if their understanding of the requirement is correct. They are afraid of being wrong.

There are many more other examples where a project team/organization demonstrated these behaviors or habits that they pick up from the individual's education. They adopted certain methodologies (water-fall or Agile) simply because someone has used it and it kind of work. They do not think intelligently why and what a method work. When they started using it, they refuse to think that they might have understood the method wrongly. They just continue to do it the same way and hope for a different result.

There are much more on this topic that every project organization should think of. It does not means that you "implement" the Scrum Framework, using Extreme Programming practices means you are Agile. It is more than what meets the eye.

Programmer is not factory worker!

I am always proud to tell people that I am a software programmer, simply because a programmer's job required frequent exercise of both right and left brain. They constantly required to transforming abstract idea into concrete implementation. It's a job that would require both art and science skill. Hence it's not something that anybody could easily perform.

However, most of the software programmers are badly underrated; they are treated like a factory worker. It is not a surprise that most business people believe 10 inexperience programmers will always 10 times better than 1 experience programmer. So when they are looking at how to cut operation cost, they go all the way to create off-shore development centre. This is similar to manufacturers who setup factory at places where salary is lower.

Wait a second! Am I contradicting myself here? If every programmer is smart, then what is wrong with the off-shore development centre? When they are equally smart and lower cost, isn't simple math and economy suggests we should all do that?

Don't get me wrong, I am not against the idea of off-shore development centre. It makes perfect sense for any business to seek every opportunity to lower down their operation cost. What I am trying to say is, while the action has a valid reason, one must know the goal and core principle. I have seen such action give birth to certain mind-set that back-fire on the business themselves

1. Off-shore programmer, they are pay less, hence they are less smart. We cannot trust them with important task!
- This is a very common assumption in this whole off-shore development game, the result is, most inexperience programmer will end up transforming themselves into what other perceive them to be, they become/behave like factory worker. It is largely due to they are not empowered or being encouraged to be autonomy. They work like a machine operator and required high precision of instructions to produce a good outcome.

2. Communication with the off-shore developers will not be a problem since we have comprehensive documentation!
- There are still many people who believe in this statement. Most of them are experience and senior "management" level. They believe that document is a good and efficient way of communication. They truly believe that long distance communication challenges could be resolved easily using specification documents, email and min phone call. Although majority of them have participated the Chinese whispers game when they attended communication training.

I am supporting the idea to recruit developers from foreign country, but you may want to bring them to your work place so they can be co-located with the users. This will allow them to use the most effective communication tool "face-to-face" when come to understanding the requirement. On top of that, give them the equal respect as you will give to any professional. They are smart people!

You should insist your client to take up the Product Owner role

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.

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?

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.

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.

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.

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.

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.

Why Developer Hate Unit Test?

You probably can find the answer from the behavioral science, the present environment where the developer works on does not demand that. Every developer knows the benefit of doing testing during development, or the disadvantage of not doing it. But since it is not giving immediate effect, emotionally there is no motivation of doing it.

We have to come out with a method to provide immediate demand for the testing while development happens. Writing production code gives immediate demand, because that has something to show and that is what the work required. Can we find a reward mechanism to make the developer write unit test while or before production code? A review session on the unit test case may be the answer. That will give the developer an instant reward on doing the unit test.

Similar type of short term reward should also be developed for acceptance test and other sort of test.

I started doing TDD just because I want to learn how it is done. After that, I have never successfully made that into my coding habit. I am always curious about why, since I am fully aware of the benefit of unit testing and the disadvantage of not doing it. I think I found the answer when I come across Dan Ariely’s Predictably Irrational, Revised and Expanded Edition:The Hidden Forces That Shape Our Decisions. After implementing the unit test case review session, it actually encourage the developers to build unit test into their coding habit.

You can not Scrum without XP practices, especially Continuous Integration

When I started my first Scrum project back in 2008, I am not very familiar with Continuous Integration (CI). After all, CI belongs to Extreme Programming and not Scrum, it was not being introduced to me properly during my Certified Scrum Master course.

When I got back to office and start implementing Scrum process, I hence overlook the important of CI. It went pretty well for me with the product backlog, sprint planning session, daily scrum, sprint review session and retrospective. The team and company enjoy tremendous benefits from those activities. We have a sprint before each release to perform hardening (more throughout testing and etc).

I realize something is wrong during the first sprint after the first release, the team's velocity is getting slower and slower, QA need more and more time to complete their testing. Items in the product backlog has become harder and harder to implement. It reaches a point where it almost halts the entire project.

It was not clear to me what went wrong, how would such a great framework turn out to be like chewing gum? It was sweet in the beginning but soon turn bitter. I only come to conclusion and the answer when I come across the topic of CI later on. My question is, why is CI not being emphasized in the Scrum course? I would expect the Agile community practice what they peach for on the transparency, trust, honesty. So Scrum courses should introduce and emphasize the important of CI, even though it is "invented" by other Agilists.

What is Agile Project Management

Many people asking me, what is Agile Project Management? What is the different between Agile Project Manager vs. Traditional Project Manager? Aren't they all managing projects? Would PMI-ACP certification turn out to be another PMP certification which just massively certified unqualified project managers and contribute to Software project failure?

My typical answer to the certification related question is: - Yes. My opinion is, PMI-ACP certification could not perform miracle that other agile certification such as Certified Scrum Master (CSM) and etc. also failed to do. Certification exam should be treated as theory assessment for individual and not more than that.

For the question about differences in Traditional Project Management vs. Agile Project Management, I would say one is focus more on process and the later focus more on people. Traditional Project Management believes that once you follow the processes tightly, your project should be executed according to plan and the result should be as expected. After more than 40 years, I believe the software industry has come to conclusion that Dr Winston Royce is correct about his assessment regarding the water project management methodology. People have finally realized software development is more art than science and hence paying attention to human factor is extremely important.

I always started my Agile PM training by asking the project managers what is software project management. Typical answers I hear is: to deliver project in time, within budget and with good quality. I am afraid whoever set their focus on those targets is most likely not going to have a good project. My personal point of view is: I think software people management is managing people, both the team and the customer. After managing more than 100 successful software projects, I have come to conclusion that the only one element that contributes to all my successful software projects is people. No one in the project team (either customer or team) started a project and wishes it to fail. The only challenge for me is how to keep this level of moral throughout the project.

Many software project managers do not set the right expectation during the start of the project. i.e. Project Kick-off Meeting. They normally presented the project charter, project plan and project schedule. For me, I always focus on delivering the message that it is a software project, it is going to be challenging, we have a challenging timeline, limited budget, but we are not going to sacrifice on quality. I believe we have a great project team established to take up all these challenges. Expect more surprises throughout the project but we will defect them when we see them. This will set the entire project team ready for surprises, everyone is mentally prepared.