Backlog Priority

~ Danny Kwok ~ Leave a comment

Backlog priority is a product owner responsibility. Agile technique state that priority must focus on deriving maximum benefits. However, there are many perspectives that a product owner can learn to derive the benefits. These are some quick practical ways to derive maximum benefits for your backlog priority.

Align Product and User Value

All users view maximum values from their perspectives. This is why backlog priority must never be provided from only the user view. Product owner must always match user values with the product values. You should not seek to please the users but look at the overall product. This is a simple rule of thumb, yet difficult to negotiate for backlog priority! The key is to align these values to a common ground. This will take a lot of practice for product owner and you must not get discouraged by unreasonable users.

Is the Story Logical?

Story mapping is a good technique to review the product and user values. There will be a good logical flow for a good story. A disconnected story will indicate a lower value. Some story appear as exception scenario and this will order it to the bottom of backlog. Thus, the story points or logical importance will help you to determine the backlog values. Subsequently, this will order your backlog in a logical sense.

Backlog priority is one of the fun moments of product owner. It will take a lot of practice to prioritise the backlog for maximum values. Agile do not provide a clear hard rules for backlog priority for a good reasons. As product owner, you will know what is maximum value and order your backlog in a clear manner. Of course, product owner decision is final and there can be only one!

Standardised or Customised

~ Danny Kwok ~ Leave a comment

Standardisation is taking shape in place of cusomisation as organisation move to reduce exponentially cost in technologies. The mindset to customise is outdated and not cost effective. Digital Transformation is driving these standard approach in the form of Agile Templates.

Resistance is Futile

The efforts to standardise will be met with a lot of user resistance. This is a normal human behaviour that must be taken into consideration for all standardisation project. There will be a lot of comparison between customised featues and the standard ones. Often, lots of behavioral efforts will be expected to resist and lament against standard features. Ultimately, benefits outweighs customisation in terms of cost and maintainability. Users must be educated or be realised that resistance is futile.

Tips to Standardise

There are a few tips to smoothen your standardisation project easier. Many of the tips will involve mindset and behavioural acceptance.

  • Find a strong sponsor and champion to drive the user acceptance.
  • Remove or deny users as key stakeholders if they are too negative or unsupportive for standardisation project.
  • Assign a SME (subject matter expert) with deep knowledge of change management and business process re-engineering.

Standardisation projects are not technically challenging but more on change management and business process changes to accommodate customised features. Strong user resistance must be broken down or removed as a key critical success factor for such projects. Good champions can help drive the success and gain management confidence in your standardisation approach.

Toxic Tester

~ Danny Kwok ~ Leave a comment

There are many interesting project experiences involving testing. It is sometimes strange to see encounters that are déjà vu. This particular project is always repeating the same set of testing incidents with the same type of toxic testers. Like the previous project, nothing are willingly shared during the requirements workshop. The real project started in the testing phase where the user is known to test repeatedly the unknown datasets. For reference, we are running Waterfall Agile approach.

Testing is not Sharing

The test cases and scope should have been known but these people are well known information gatekeeper. In addition, you may encounter inexperienced noobs who cannot gather the right requirements or collaborate closely to break through the gatekeeper. It is always easy to feedback why have all these issues not be tested beforehand. Indeed, this would have been a useful comment if the information gatekeeper is willing to share the test scenarios.

Signs of Battling Testing

You will find these common tell tale signs of toxic tester when the user start to test on exception scenarios that are only known to the information gatekeeper. Do not be surprised or discouraged by the massive issues flagged. A typical development team will be battled by these type of toxic testers. The typical testing feedback will always be brief discouraging and laced with acidic comments. The key to handle toxic tester is to hold your ground and focus on fixing the critical issues.

Toxic testers will always be around in many projects. You are expected to see this type of testers when you have very brief workshop and limited information. You will also need to gear up with an Agile team to agile the high influx of reported issues.

Digital Supply Chain 101

~ Danny Kwok ~ Leave a comment

Digital Supply Chain (DSC) will be gaining a big leap due to COVID-19. As part of social distancing, there is a huge reduction in physical transfer of goods. This leads to various digitalisation outcome. Many of goods and services emerge and evolves into Digital Supply Chain. These industries are involves high touchpoints like media, publishing and education.

Photo by Ethan Kwok
Parts of DSC

Digital Supply Chain have similarities to Supply Chain. The key parts will be the focus on digital components. These main parts comes together to form the Digital Supply Chain.

  • Content Providers
  • Content Delivery
  • Content Security
  • Content Storage
What it Means for Consumers

Goods that can be provided in digital format can be sold quickly via online platform. Consumers will need somewhere to store and access their digital goods securely. Suppliers can extend its reach to get digital goods via supply chain network. A major breakthrough is the usage of NFT (non-fungible token) for Digital Arts, games, music or even collectibles.

We will see more of digital supply chain as I look forward to buying more digital goods. This helps save physics storage space and digital goods can be easily shared to my family.

Reopen Status

~ Danny Kwok ~ Leave a comment

Should we have reopen as our status value? If you are familiar of status lifecycle values, you will realise that this is a very ambiguous status value. If you have the option to reopen, there will be no end to status. This is because your statistics will mess up due to this reopen.

State Diagram

If you are in engineering, you will learn about state diagram. It is a very good concept to manage your status value and its logical flow. Users love to provide various value for your status. Very soon, you may find overlapping status or conflicting status for your application. Give this method a try if you are facing a status meltdown.

Status Tips

Setting good status value is key to analysing your transactions. These are some good tips to setting good status and its values.

  1. Keep your status type to less than 3 if you want to remember the status dependency.
  2. Set your status value in a forward logical flow.
  3. Avoid ambiguous status like reopen that will mess up your statistics.
  4. Do not create conflicted status value for status type like Done for a status and “Pending” for the other.
  5. Always have a start and end state to your status.

Status are key method in all data gathering and analysis. Users may not be the best person to determine the status. You may want to review and use state diagram to illustrate your status flow. Keep in mind the status tips to extract the best results in your data.

Issue Log is Not Incident

~ Danny Kwok ~ Leave a comment

Some projects loves issue log and issue reporting a lot. I greatly discourage these as they are a negative reporting compared to backlogs. You will also know this issue log comes from a waterfall approach. Thus, someone will try to run issue log like incident management. Although this is not wrong, there are some distinct differences between issue log and incident management that you must take note.

Incident is not Issue

An incident is an occurrence of event that stop the user from completing your task. This usually have priority and severity to the incident. Not all incident are issues, as they will need to be classify further. Usually, RCA (Root Cause Analysis) will be performed for severity 1 incident. The objective of incident is to clear the incident as fast as possible. This is also known as SLA (Service Level Agreement). Unlike incident, the objective of issue log is to permanently fix the issue. This is a key reason why incident management is different from issue log.

Incident is not a Change

Users often raise changes as incidents. A change is not clocked to SLA but classify as enhancement request. An experienced PM will be able to flag these request if this is a small project. Similarly, issue log is not for change. Any change to the intended scope will be logged as a change request (CR). The CR should not be critical to the project timeline.

Management of issue log must not be confused with incident management. If you really want to apply incident management to your issue log, then you must be aware that the rules are changed.

Pandemic is Endemic

~ Danny Kwok ~ Leave a comment

Moving a pandemic to endemic is a model that will be done for COVID-19 in Singapore. Being a port city, trade and travelling is most important and sustain isolation will do more harm than good. While I look forward to this, there are many things we are learning from pandemic.

Photo by Ethan Kwok
Mindset Adaption

There are a few mindsets that needs to be recalibrated for us to be adaptive. Work From Home (WFH) will stay and jobs are no longer constrained to office space. Many jobs also cannot be totally relied by external workers. Food security have been accelerated to reduce dependency of food imports when borders are closed. Digitalisation have also been ramped up to enabled automation.

Mask and Hygiene Culture

Have everyone realise that flu is lower as well? Seems the mask culture will be here to stay if anyone fall sick. Tray return is also mandatory as we move to a hygiene approach to keep the country clean. This also helps to increase focus of cleaning to sanitise instead of picking your trash.

The announcement to endemic will come soon as vaccination gain momentum. We will likely continue to practice what we learn during the pandemic. Have an open mind to continue the goodness learnt during COVID-19.

OTM Dilemma

~ Danny Kwok ~ Leave a comment

OTM (Oracle Transportation Management) can be a big dilemma if we are moving to cloud or upgrading. It is a configurable system that allows customisation from small degree of change to major one. A major part would be your decision to upgrade or migrate to cloud from the amount of configuration or customisation done to OTM.

Photo by Ethan Kwok
Cloud Dilemma

Many organisations would prefer to migrate to cloud for future support and upgrades. separate the customisation Cloud, like its name, really is cloud. You cannot foresee what will happen in Cloud until you are in Cloud. Your risk appetite will need to be high if you have done a lot of customisation on OTM. Prior your move to Cloud, a major task is to separate the customisation into REST services. How much time and effort will you invest? Should you forgo your customisation instead?

Upgrading Dilemma

Upgrading OTM major version can be quite a slow painful experience. The 6.4.3 is the last available version that is non Cloud based. The decision not to move to Cloud usually lies with the amount of customisation done. The biggest changes from old version to 6.4.3 version are architectural, user interface (UI) and report server. The dilemma comes in the sequence of upgrade you want to take. Report server is now mandatory after the removal of embedded reports. Should you move your embedded report first or do together with upgrade? How much training period should you allow for the new UI? How much time will it take to fix your customisation during the upgrade?

OTM upgrade or migration to cloud is a painful dilemma. There is always a temptation to status quo the version due to the massive efforts to factor risk and change management. In many cases, you need lots of patience and alternate plans while you are upgrading or migrating.

Vaccination in Progress

~ Danny Kwok ~ 1 Comment

COVID vaccine seems to be a norm now. At the rate the virus is mutating, it also seems that booster shot will be required at a yearly basis. The Covid pandemic have accelerated the development of vaccine at a tremendous pace. How will this impact technologies in future?

Vaccinated Society

Technology are now in place to identify the vaccinated. This will soon creates a divided view on those who choose not to be vaccinated. These technologies also help to automate the access to certain areas. You can view vaccination as a criterion for many activities. Thus, technology will play a key part in the identity of vaccinated person status.

Herd Immunity

Covid will continue to be persistent. Lockdowns will not continue for long at the expense of economy. The aim of vaccination is to achieve herd immunity. Soon, technology can easily profile regions or even countries populated by vaccinated people. Humans may even evolve from vaccination.

The technology to identify vaccinated people are already in place. The push to remove lockdown will speed up the development of these technologies. This gives you a choice to where you may want to visit or travel.

Testing 123

~ Danny Kwok ~ Leave a comment

Testing a system is a two edged sword for many because it can lower risk or incur cost and delays to the project. There must be a balance to what should be tested. In many instances, users often test whatever that comes in mind with a guiding script. So, what is the true purpose of testing?

Testing for Reassurance

Why test when you already know you are able to pass the results? In the old days, uncertainty is higher as many systems have high cost of rollback. It is difficult to go back once new features are deployed. Reassuring the stakeholders and their confidence are too priority prior to deployment. The present says otherwise as testing is now done at necessity. With Agile and DevOps, you can easily rollback your codes, resolve issues quickly or even create a speedy exit plan. Some may even go for canary testing, AB testing or pilot trial as confidence building.

Testing for Insight

Testing have any key objective that is geared towards insight and curiosity. This is usually done for innovations and new technologies. Testing helps to discover new requirements and uncover risks before deployments. Some Agile team also use this technique for test driven development. Of course, users will lament the failure of test cases even though it is clear that the requirements are unclear!

The basic principles of testing is not a pass or fail from test cases. Human nature seek for reassurance for new things. Testing is one way to build user confidence and “sign off”. Another aspect is the insight that can be gained from testing. In this case, testing is a method for discovery and development. Thus, it is important not to lose sight on the purpose of testing.