Tag: Agile

Where is my Backlog?

~ Danny Kwok ~ Leave a comment

Year 2022, it is still common to find project management using excel applications. It seems that much have changed for past decades. Of course, there are many project management tools that are bought and forgotten. Like all users, IT project management follows the path of least efforts. This is why I prefer the Agile approach to keep a backlog as a single source of truth to store all matters to be addressed. How should you start your backlog?

Role of Product Owner

Agile in practice differs greatly from theory. Scrum master, product owner and developers may span multiple geographies. There may also be vendors running this role. Or in some case, there is no product owner role. Organisations are slow to realise that backlog belongs and are maintained by product owner. Without this role, it is common to see emergence of multiple excels from your waterfall approach. Therefore, it is time to realise that you need this role to start your backlog.

Backlog for External Parties

A common challenge for backlog is accessibility to external parties. This happens when you have contractors as developers. Thus, you need a secured space with version control to store your backlog. There are many cloud applications that provide agile backlog maintenance. Another approach for product owner is to restrict by view only and assign backlog accordingly. This is the standard approach for many agile implementation.

To avoid multiple trackers and problems of versioning changes in excel, you may want to adopt Agile and backlog. The role of product owner is critical for backlog maintenance. Backlog provide a single source of truth for all to review and avoid missing tasks.

Advertisement

Resource Management 101

~ Danny Kwok ~ Leave a comment

Interestingly, resource management is a basis of several project management. However, there is a common gap between user expectations and actual resources. Users do not have notions of how resources are acquired and utilised. There are also middle layers or coordinator teams who portray a misconception of unlimited resources. This is where you need to emphasis the reality of resource management.

Fluid Resources

In the Agile world, we need to upskill our resources to be multi talented. This will allows you to manage your resources pool with ease. To achieve fluidity, many organisations are turning to in-house resources to support core projects. Common IT support or infrastructure should be outsource accordingly. This way, you can build and retain critical knowledge within the organisation.

Agile Planning

If you have adopt Agile, you can easily ensure a constant Agile team for your projects. Agile planning are fast and allows consistent load in sprint. You may also choose DevOps as another option to reduce the gaps in user expectations. Unlike waterfall project plan, you will not be subjected to Big Bang delivery and need to load additional resources.

Resource management have come a long way from the era of waterfall. You must reorg for Agile team structure. This way, you can retain consistent deliverables within a sprint and also key knowledge among the team. It is also time to scrap project management or coordinate role who try to arrange for resources. If you can agile, go for it and build your team.

Software Upgrade Testing

~ Danny Kwok ~ Leave a comment

In many software upgrade, 80% of the efforts should be spend on testing. This is because software upgrade testing can be tricky. You have to decide whether to test in depth or cover in breadth. For many project teams, the lack of application knowledge will be obvious in the execution of testing. How should you select and determine what are to be tested?

Set your Testing Objective

The key objective of testing during upgrade is to ensure all is well. Thus, there is a conflict on how much we should test. You can use objective to determine your testing coverage. I like to set my testing objective to ensure a smooth UAT (user acceptance testing). In order to achieve this overarching goal, I will need to focus on tests on common break points for software upgrading.

Agile Testing

A key issue of waterfall process is linear testing. This is the process of unit testing, system integration test (SIT) and UAT. I usually mitigate this approach by using Agile testing to raise user confidence. From experience, test are designed to passed within a set scripts and will fail during free style user testing. The duration to deploy fix during user testing will not meet the desired timeline for waterfall. Thus, I will choose to deploy knowledgeable support to role players as users to keep testing within an agile process.

The mindset of traditional testing in software upgrade aim to test for pass. This is why many issues surface during the user testing. You should allow knowledgeable support members to test to break the software. Following test scripts may not be useful in the agile world of today.

2022 Clouded Space

~ Danny Kwok ~ 1 Comment

2022 will see a year of COVID normalisation. Similarly, the “clouded” space will see emergence of key players. Every organisations are expected to deploy application in at least 3 major cloud platforms aka multicloud. By then, teams are expected to be equipped with cloud skills that are generic across different cloud platforms. The clouded space will continue to increase during 2022 as major software shifted to cloud.

Cloud Transformation

You will soon see that digital transformation will be changed to cloud transformation. The stabilisation of COVID pandemic will give rise to future cloud transformation that will work well across geographical locations. The increased usage of cloud creates demand for skills that can adapt and transform applications to cloud based platform.

Agile Applications

Applications time to market will continue to be DevOps and Agile. The redesign of AMS (Application Managed Support) towards DevOps will continue throughout 2022. Organisations will continue to invest for in-house capabilities and obtain the optimum Agile application and team. We will expect to see continuous struggle to eliminate traditional project managment approach in favor for Agile methods.

In 2022, it is near impossible to escape from the “clouded” space. Cloud transformation is expected to dominate with increasing usage of in-house generic cloud architect. We will continue the battle for full Agile approach to align with cloud capabilities.

Apex Dashboard

~ Danny Kwok ~ Leave a comment

After weeks of tearing hair over Oracle Apex and REST, I finally understand the basic approaches of using REST in Apex. Now, I finally can have fun with Apex Dashboard. Transactional data can now be presented nicely with Apex Dashboard. This is not to be mistaken with analytical Dashboard like Tableau. These are my review of Apex Dashboard which I manage to setup within a day or two.

Photo by Ethan
Why Apex Dashboard?

Data always comes in two flavors: a list or diagram. Thus, it is nice to see dashboard as a standard template in Apex. We do not really need complex dashboard like Tableau. This is because we are dealing with operational data. Therefore, a chart presentation in dashboard format can easily relate to the user. A flexible part of Apex dashboard is the ability to use SQL. Viola! That is why I can churn out a decent dashboard within a day!

Agile your Dashboard

The quick and lightweight dashboard suits operational users and agile method. I can easily pilot the dashboard and update user requirements with ease. The rapid iteration allows users to visualise the data in an efficient manner. Sometimes, I even redo my dashboard quickly because the older version is not to my liking. You can even mix and match dashboard in region in Apex page.

It is good to have a tool with simple lightweight features like dashboard. I do not need to separate dedicated dashboard tools for operational users. Finally, the dashboard template adds a nice additional and visual appeal to users. After all, we like to be appealed with good UI and visual data.

Why I Need a Cloud Platform

~ Danny Kwok ~ Leave a comment

It is my third year of having a cloud platform. Year 1 happened due to major project. Year 2 was exploratory and I started to use simple features like object storage. It was only on the third year that I managed to explore and build an entire cloud architecture. There is no turning back because Cloud platform has provided me freedom to Agile and configured applications quickly. These is a reflection on why I need a Cloud Platform.

Self Service

The reality of self service finally reached the IT community. That self service comes in a Cloud Platform. As product owner, we usually need a box in the past to initiate any new product features. Such request takes a long time from procurement to deployment of the application module. All these efforts can now be self service at a cloud platform. You can quickly spin up a compute within minutes. You can even setup entire eCommerce architecture in a cloud platform.

Finally Agile

Another favourite advantage in having a cloud platform is to be fully agile. I am no longer constrained by dependencies like network, computes or storage. These are now easily available with cloud platform. In another words, you can agile innovations with high uncertainty. You can also RAD (Rapid Application Development) or DevOps your changes because cloud is configurable.

The freedom of being agile and ability to self service are key reasons on why I will continue to need a cloud platform. If is also rare to find organisations that are still on-premise. I am excited that the next years will be spend to migrate the needed to cloud platform one way or another!

Why PM is Outdated

~ Danny Kwok ~ Leave a comment

In the world of Agile, there is no PM (Project Manager) role. I have questioned on the relevance of PM in Agile project. With Agile gaining grounds, it is time to determine that PM role is outdated. These are reasons why you can run your Agile project without PM. To be specific, it is time to put a stop to freeloaders working as PM for Agile projects.

Why Agile Obsolete PM

In waterfall project, PM is required to work on project management e.g. schedule, scope. There is a lot of trackers to track schedule, gaps or issue logs. In contrast, Agile focus on self empowerment and self organising. There is no need for PM in this framework based on this key principles. You will not need a PM to chase or track after deliverables. As an analogy, waterfall is like a baby with constant minding from the guardian. Agile places the collective accountability to the Agile team.

Adaptability Outpace PM

A PM mainly function like an observer to the project. Monitoring and tracking does not provide the adaptability required by Agile. Often, PM is outpaced by Agile team. The additional communication layer of PM becomes redundant. Users or customers can work in close collaboration with Agile team. This is a key reason why Agile do not require PM. If you are running an Agile project, do expect to be frustrated by the placement of the PM.

It is time to realise that you no longer require PM for Agile projects. We should not continue to be in self denial mode to have this role for historical reasons. Agile team is highly independent to get things done and adapt quickly with users or customers.

P.S. Self declared PM continued to exist during digital transformation period. It is time to wake up and transform PM role as well!

Test Grouping Tips

~ Danny Kwok ~ Leave a comment

With the increased migration of Cloud or upgrading activities, testing efforts are increased exponentially. Full testing is often ideal but unrealistic and costly. Thus, you will need to strike a balance in your testing coverage. One method is to group your test cases to reduce the testing duration. However, there are ways to prepare for this approach.

Preparing for Test Group

The purpose of test group is to reduce cost and efforts. You can also maximise testing coverage with minimal test cases. However, you will require deep understanding of your test cases before you can conduct a proper grouping. There are many approaches to group your test cases. A common way is to group the application features. Other methods involves functional grouping or customer groupings. You can also group by user base or locations. While there is no right or wrong, the key is to obtain the most efficient grouping.

Agile your Test Grouping

There is a misconception that test grouping is fixed when testing is on-going. This statement is true for many waterfall projects. On the other hand, you are encouraged to iterate your test groups if you are running on Agile. The testing process will gauge the effectiveness of your test grouping. It is important to update your test grouping to maximise your test coverage. As opposed to waterfall mindset, test groups process will lead you to design a better testing approach for your next Agile sprint.

Testing is most efficient and effectively if you can group them properly. Preparation is a key part to start your test group on the right track. You should also be prepared to amend the groups accordingly for your next Agile sprint.

PMO for Agile?

~ Danny Kwok ~ Leave a comment

PMO (Project Management Office) will be facing a dilemma soon. This is because many of the standards from PMO derives from waterfall model. As organisations shift towards Agile for project implementation, can we transform these PMO for Agile approach? This is one area that digital transformation can consider!

Photo by Ethan
PMO Relevance

Like all trends, project methodology moves towards Agile as mobile apps and Cloud become prevalent. PMO functions as “enforcer” or standards for standards like PMP or PRINCE2. It also serves to facilitate, support or even control project implementation. Relative to Agile, this is like a scrum master role! Does this means that PMO is no longer relevant with rise of Agile? Should PMO be transformed to scrum master roles?

Transforming PMO

For starters, I will advocate the transformation of PMO as scrum master if your organisation is going to adopt Agile as the main project approach. There will be a gap in project alignment when you are transitioning from waterfall to Agile. Rather than digital transformation, I will deem it as a project transformation journey. The new scrum master (formerly PMO) should be in charge of guiding the project transformation to Agile.

The adoption of Agile become stronger and stronger as organisations require speed and adaptability for projects. PMO will no longer be relevant because of these digital transformation. Thus, project transformation should be driven by the transformed PMO (scrum master). By now, you will realise that digital transformation involves the need for PMO to transform for Agile.

Composability 101

~ Danny Kwok ~ Leave a comment

Composability is an interesting term I came across in this article. It will redefine how teams are structured and managed in organisations. In summary, composability is a design principle to view the interaction between different systems. Organisations must move towards highly composable architecture to satisfy continuous user needs. Basically, it is how you are able mix and match your components together with ease.

Being Composable

The shift to composability is not new. Web services or SOA (Service oriented architecture) are earlier design of composability. The push to be highly composable is triggered by COVID-19 pandemic to be resilient and adaptive to business requirements. Unlike SOA, composability aims to be modular yet stateless. It is the vision to fully plug and play with quick and minimal cost.

Composable Technologies

Cloud platform is the best example of Composable technologies. You can quickly deploy and configure different architectural model within a short time frame. Different services can also integrate quickly using REST API. These technologies disrupts the traditional way of implementation business requirements. You will need to utilise Composable technologies to accelerate your collaboration and system delivery.

Organisations are now digitally transforming to composability mindset. The typical approach is to migrate to Cloud. Teams will be formed to be Composable and Agile. The ability to react will be the future way on how we develop our technologies as enabled to business needs.