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.