Ignorance is Not Bliss

~ Danny Kwok ~ Leave a comment

It is not surprising to know that ignorance can be quite a force to be reckon with. In every project, information gatekeeper can make or break your project. This is why Agile advocate retrospective on each sprint. My conclusion is that ignorance is not bliss at all.

Ignorance is Risk

Alarm bells are ringing loudly when your technical team starts to flag the following items or the PM (Project Manager) is hearing the comments from users during workshop.

  • This is an IT project.
  • There is no SOP.
  • Resources are busy and only 1 user is available for the project.
  • Please follow the same requirements as legacy system.
Ignorance is a Root Cause

In the initial phase, inexperienced PM or “nice” PM will not be sensitive. In fact, many will ignore to avoid conflicts. After all, nobody wants to negotiate such mindset or do change management. When there is a delay, everyone seeks to explain the reason but not the root cause. After all, it is really hard to admit ignorance is a root cause.

In many years of project implementation, ignorance continue to remain a key root cause. As management retrospect each project, it is a must to acknowledge that ignorance can either be ignored or be tackle head on. Only then, ignorance can be minimised for the project benefits.

Agile Is Close Collaboration

~ Danny Kwok ~ 1 Comment

You know that your project is not Agile enough when your user collaboration is not as close as you wish! User commitments is high in Agile project. Many have failed to consider the level of commitment required for Agile project.

Collaboration is Mandatory

In waterfall project, the project task is step by step. Users are not involved in all the tasks. On the contrary, Agile requires close collaboration from Day 1 with the users and developers. It is mandatory that collaboration started from start to the end of each Agile sprint. Without collaboration, your Agile will not be effective and you will not face difficulty in completing your story points.

Collaboration is Two Way

In a typical user developer setting, users often steer their requirements to their wants. Communication becomes one sided and left little room for negotiation for the developers. In Agile, users and developers encourages collaboration in a two way communication manner. Users collaborate in a non authoritative way and developers proposed the best solution at the point of sprint.

It is time to educate users when you are running Agile project. Users mindset will need a new change to adopt a collaborative two way communication approach to the developers. This will help to derive maximum benefits from each sprint.

The Dilemma of UAT

~ Danny Kwok ~ Leave a comment

UAT (User Acceptance Testing) is one of the flawed processes in Waterfall project model. This is why UAT no longer exist in Agile project. As it happens, UAT is a subjective processes and based on the users approval for the system to Go Live. This creates a major roadblock if you are changing or upgrading your system. This is because users resistance contributes to the failure of UAT, creating a dilemma!

UAT is Bad for Change

UAT is notoriously bad for change management. By default, majority of human do not have high tolerance in change, especially those who are in operational role. You will find many test results referencing the expected behavior of the old system. Another common issue is the required update of SOP (Standard Operating Procedures) which is not updated resulting the confusing test steps to the users.

UAT is Seldom On Time

It is ironic that many users are have a day job and not full time testers. Thus, it is really hard for users to commit 100% to the testing schedule. Any fixes will result in regression testing for the users. As a result, testing fatigue sets in and develop into frustration for the users. It is normal to see many UAT delays due to the users commitments. If you really want a full time tester, you will not get a true user.

Many UAT process faces constant dilemma to pass X number of test cases working a Y durations. Delays are foreseeable and expected. UAT also do not fit change management and SOP changes well. Therefore, the push for Agile testing will be harder as a replacement of UAT in waterfall project.

Project Boundary Tips

~ Danny Kwok ~ Leave a comment

In every project, scope creep is so common that we have to set boundary with project scope. Some users will request for all requirements with no understanding of story point. Others may become information gatekeeper to reveal scope a little at a time. So, how should we set project boundary?

Vague or Clear

Requirements are always vague in project. Clear requirements are referring to known story points. Soon, you will notice that there are often no issue for clear requirements. You should focus to preempt your vague requirements, if you choose to work on them. Thus, this is where your boundary will start.

Far or Near

If in doubt, do KIV. In reality, this is difficult if you are running on a fixed cost outsourced project. You will want to implement as much as possible. This is where you need to draw your boundary as near to the scope as possible. If the boundary is set too far, the likelihood of this scope acceptance will be very low.

Project boundary and scope creep is a never ending push and pull battle. You can decide this by setting the limits of your boundary. Clearer requirements will often lead to nearer boundary to scope and higher success in your project.

Agile Template

~ Danny Kwok ~ 2 Comments

Agile templates are getting popular now. There is no need to build many things from scratch. You can easily setup eCommerce shop within a day. Template are developed with Agile in mind and vice versa. Thus, you should start to develop Agile Templates instead of projects.

Why Template

From many legacy applications, templates comes from the ease to reuse and the need to reduce cost. Project is a mash up and gelled need to address a focus objective. In contrast, templates address a particular story point and suit Agile perfectly. Agile team will gain most from towards templates more than previous project implementation exposure.

Shift to Template Management

The role of project manager (PM) will be on a decline as teams shift towards Agile approach. Instead, this role can move to a focus on template management. Some organisations will have similar approach like COE (Center of Excellence). Another big push is Cloud which emphasis a lot on templates for rapid deployment.

The shift in IT landscape is huge for the past few years. The COVID-19 pandemic is also a major push factor in accelerating these changes. We will see more of templates design and model from major cloud organisations. Their template libraries will be the key factor to lock in the customers, including me.

Do Not Digital Transform

~ Danny Kwok ~ Leave a comment

Digital transformation may be the trend now with many rushing to transform their digital technologies or implement new innovations. There are many success stories reported but many have comes with trial and error. The key is to identify what not to digital transform and avoid unnecessary wastage of time, money and efforts.

Inclusion Criterion

The evaluation for digital transformation is vague in many instances due to various results and differences of business domains. What works for banking industry may not be applicable for logistics domain. Thus, you need to have clear inclusion criterion to be setup for your digital transformation program. This will allows you to pinpoint the necessary system or tools to be transform.

Exclusion Criterion

The inclusion criterion is the first step to understand what are the key things that you can digital transform. It is highly recommended to run multiple pilots to understand the nature of the tools you going to use. With deeper knowledge through realistic applications, you can form the exclusion criterion on what cannot be digital transform. For instance, voice recognition may not work in heavily accent Asian countries with different dialects.

Digital transformation could be for the good, better or worst. You need to have a clear picture and understanding of the tools that you are using. Always seek to run pilot study to know the tools well before you embark on a major digital transformation program. In this way, Agile approach is for the best.

Delta Migration 101

~ Danny Kwok ~ Leave a comment

Have you ever face with delta data during migration process between upgraded systems? There are several standard approach to manage these delta. These approach can from simple to complex.

The Simple Way

The simple approach is usually relative to cost. This suits small and mid volume transactional data. You can choose to do a straight cutover from source system to target system. The focus will be on the delta data that reside between the two systems. There are two ways to handle this.

  1. Reconciliation of data between two system till the delta is cleared. These usually will take 2 to 4 weeks for the target system to reach a steady state.
  2. Stop processing of delta data in source system and to proceed in target system.

The Complex Way

If you have high transactions and a huge system. It is time to invest to manage the delta automatically. Complex way will usually involve tools or transient ETL (Extract Transform Load) integration between source and target system

  1. ETL tools are the most common approach to synchronise data at application level. It is automated and can be removed once steady state is reached.
  2. Another method is the building of a transient application to handle the delta data. This application is focus to manage the delta data and ensure a smooth transition between the two systems

Anyone and everyone will overthink Delta migration. It is always wise and wiser to consider the approach based on your transactions and budget. After all, you cannot request to fly to the moon with an aeroplane.

Oracle Email Delivery Services 101

~ Danny Kwok ~ Leave a comment

I was testing Oracle email delivery services when I realise certain constraint on the receiving end. One of them is the email security policy of the organisation. This can be quite painful where email services are blocked constantly. Thus, you should not rely on email as your only mode of communication with your customers.

The Good Part

It is pretty simple to setup and test email delivery services. Oracle provide a sample send email on GitHub to be use together with its Cloud functions. Disclaimer that I mention easy after spending days to understand Oracle Cloud Functions and API Gatway. So, I will suggest that you start studying Oracle Functions and API Gateway first before testing Email Delivery Services.

The Constraints

Some constraints I found while testing and it a stark reminder to email delivery failures. A simple list here:

  • You cannot use public email like gmail as your sender.
  • You will need access to your email configuration to update your SPF records.
  • Majority of organisations blocked relayed email.

Some improvement I will like is the ability to setup its own simple mail sender or access to public email as sender. Other features that can be added will standard email test can be trigger on the console, template for responses. The test trigger will remove the need for functions and API gateway setup.

Backlogs or Issue Logs

~ Danny Kwok ~ Leave a comment

Backlogs or issue logs can be quite a conflict if you are running waterfall Agile for your project. Usually, issue logs are created for UAT and dictated by users who are not well versed in priority setting. Thus, the issues log will conflict the backlog handled by the product owner (PO).

Priority or Business Value

It is not surprising to see users set high priority to all the reported issues. On the other hand, backlog focus on how to derive maximum business value as its condition. As a PO, you can align both backlog and issues log by comparing business value against issue priority. The lowest business value with high issue priority should be delegated to the bottom of the backlog. Vice versa, maximum business value with high priority can be reviewed on the top of backlog.

Issues Impact or Story Points

Issues impact have a tendency to be blown out of proportion. This is why story points in backlog provided a better value and evaluation over issue impact. You can counter weight issue impact to the respective story points. Good story points can lead to better details and provide you a better understanding. From these details, you can derive the actual impact of the issues relative to the story points.

Issue logs have notorious name to blow everything out of context in waterfall project. You can apply strengths of Agile backlog as a countermeasure and sanity check with waterfall Agile.

Macros Tips

~ Danny Kwok ~ Leave a comment

Wonder if anyone just remember Visual Basic (VB)? If you have, you will feel at ease with Excel Macro and its IDE (Integrated Development Environment. Macro is a strange world that exist between developer and users.

KISS

Keep It Short and Simple is the first and most important tip of macro. If you find yourself building an entire application, it will mean that you are using the wrong solution. In many ways, macro is similar to RPA (Robotics Process Automation). You should not solution full fledged data driven application with dependency to your system.

Breakpoint, Add Watch and Step Into

The second most important tip you need to learn is the mastery of breakpoint, add watch and step into debugging. Owning to the local copy of each macro, you will find yourself checking every copies of macro floating around your ecosystems. This can really a be pain in the maintenance process. One way to manage is to master the debugging features. This is really the highlights as these features enable you to trace your macro issues quickly.

Macro is a legacy chapter in development which will be phase out in future. Meanwhile, I still need to manage and maintain my love hate relationship with Macro. These two tips are the most useful for anyone who want to maintain macro till it goes away for good.