Tag: Agile

Co-creation 101

~ Danny Kwok ~ Leave a comment

Have you tried Co-creation process with your consumer or contractor? It is a form of collaborative method where two or more parties work to contribute to the product development. Open source software is a good example of this approach. With Cloud platform, you can also adopt this method to actively digital transform and create your knowledge capabilities in-house.

Why Co-creation?

Self-service and satisfaction are the major push for co-creation. The need of self-service allows users to create products with closer fit to their expectations and requirements. This brings increase satisfaction and commitment to the success of the product. Co-creation also allows greater participation throughout the product lifecycle. It is best aligned with agile process to adapt to changes.

Setting Ground Rules

The approach to implement co-creation depends on your needs. It is important to set ground rules if you wanted to engage your users or contractors for co-creation process. Some of these ground rules involves the level of control or access the co-creation can cover. Other forms of collaboration involves the communication and risk entails by the participants. The most important portion is to ensure information transparency among the collaborators.

Co-creation approach works well with Agile for Cloud. It is the best middle ground approach between outsourcing and insourcing model. You can gain internal capabilities and ensure better satisfaction for your users with self-service technologies. However, do take note to set ground rules before you embark on your first co-creation project.

Advertisement

Upgrading 123

~ Danny Kwok ~ Leave a comment

Upgrading remains a major project for many on premise and legacy applications. It is really quite a pain and this is one reason why I favor Cloud platforms. In the meantime, I hope that I can do upgrading for the last time. These are some tips that the future may not be using for upgrading exercise.

Get the Right Team

The upgrading team is usually a separate team from the support team. This caused a disconnect with miscommunication and the need of knowledge transfer process. There are also instances where upgrading team miss out key components. After all, we suppose the upgrading team to be well versed in the new application. However, the team must involve a right mix of support team to understand the application landscape.

Agile and Systematic

Unfortunately, many upgrading projects follow waterfall model. I favor Agile and systematic approach. In all upgrading project, you need to be systematic in the changes you are doing. You must also be agile to adapt to new options of the upgraded components become a showstopper. Therefore, waterfall model is painfully slower and subjected to delta changes.

As long you are having legacy or on premise application, you will still be having upgrading nightmare. A move to Cloud will cut these costs and time as upgrades are done seamlessly backend. Hopefully, we will not suffer more upgrades in future.

Project Rules of Engagement

~ Danny Kwok ~ Leave a comment

In many projects, the rules of engagement is often vague and undefined. This is because standard communication plan assume a constant and stable environment. This is how waterfall projects are being run in the past. In agile projects, close collaboration is required and this blurred the formality of communication. To avoid misunderstanding, it is recommended to set some guidelines for rules of engagement with one another.

Standup Meeting

If you are familiar to Scrum, standup meetings are timeboxed to last 15min. In reality, this often overruns if you have more than 3 people. You should review this communication internally and give a realistic timebox. There are some who are not able to articulate the objectives within 5min. If so, there should be other breakout sessions to handle this. Thus, you must be disciplined to time box accurately.

Sprint Retrospective

The sprint retrospective is another good concept that can be used rules of engagement regardless of project type. Some will remember it as AAR (After Action Review), “post-mortem” or project review. The key communication objectives are to understand what goes wrong and ways for improvement. You can also share the good points and reinforce project communication for the next one.

The basic project rules of engagement can be classified loosely as daily standup and post review like sprint retrospective. These encourage project team to collaborate and communicate closely with one another.

ORDS 101

~ Danny Kwok ~ 3 Comments

ORDS (Oracle REST Data Services) is a cool feature to extend your Oracle database for integration via HTTPS. It will change and digital transform the way you interact and integrate to applications. This is why you need to enable ORDS for your database for future API.

Why Change to REST?

REST is changing the way applications can quickly communicate with each other. It is much simpler to setup than SOAP/XML. In a way, it can replace many of legacy integration with XML and flat file. ORDS helps to enable access via RESTful web services to data and stored procedures in your Oracle database.

Time to ORDS

Another key advantages of ORDS is security and real time performance with your Oracle database. The REST API endpoints are quick and simple to setup. The quick deployment reduces traditional integration method by eliminating the need of complex middleware setup. JSON format and paged results helps to support the ease of data responses.

If you are using Oracle database, it is time to ORDS and enable your REST capabilities. This will digital transform your integration method for other applications and agile your development.

RAD with Apex

~ Danny Kwok ~ Leave a comment

Rapid Application Development (RAD) is around since the days of Visual Basic (VB). Since then, there is a preference of lightweight and low code framework with Agile approach. APEX (Application Express) is one such framework offered free with Oracle database. What does this signal for heavyweights like Spring or J2EE framework? Should you switch to low code like APEX?

Ease of Maintenance

The key push factor to switch to low code framework like APEX is the ease of maintenance. This helps users to focus on solving business problem rather then creating technical solution. Changes can be made and deploy quickly. This suits high complexity and exploratory problems where scope is largely unknown.

Business Driven Skillset

Low code environment places emphasis on outcome instead of being expert in thr programming language. Thus, platform like APEX suits users who are not technically inclined to setup entire infrastructure like servers and database. This emphasis business driven skillset like problem solving instead of technical skills. Users can also realised business solutions quickly with low code deployment.

The switch to low code platform like APEX will be growing. This is driven by the need for agile solutions to solve changing requirements. Usage of APEX also allows citizen developers to co-own and maintain the development.

IT Outsource to Co-Sourcing

~ Danny Kwok ~ Leave a comment

Outsourcing will be on the decline as Cloud architecture grows with adoption. Many organisations are now turning to co-sourcing model because Cloud allows you to self service very quickly with configuration. This allows you to Agile quickly and adapt to different business needs. So, how should organisation make the switch to co-sourcing?

Recalibrate your Team

The first step to co-sourcing is to recalibrate your team skillset. This means your team will need to start to utilise their technical skills. A good start is to take on some enhancements changes internally instead of outsourcing to vendors. However, there are some teammates or management who cannot make the switch to this model. You will need to make the hard choice to rotate your team for co-sourcing inclined resources.

Co-sourcing with Vendors

The next step is to leverage your vendors for co-sourcing needs. You will also need to communicate to vendors your co-sourcing objectives. Both parties must build on mutual trust and work towards open knowledge and transfer of skillset. There is a misconception that co-sourcing will lead to a decrease of business for vendors. On the contrary, business will increase as more innovations can be implemented.

IT Co-sourcing is expected to overtake or even replace existing outsource model. There are two key steps to convert your organisation to co-sourcing. First, you need to recalibrate your team to build on technical skills. Then, you must communicate to your vendors for this vision and work mutually to achieve this model.

Configuring Software Product 101

~ Danny Kwok ~ Leave a comment

Configuring software product is the key trend and reason of moving to Cloud. Some key characteristics of configuration approach are real time changes, hotfix and self service features. Many traditional project manager have misalignment to apply development methods for configuration model. If you are one of them and new to configuration approach, you may find these tips useful.

Digital Transform Mindset

Digital transformation is a main component for configuration model. Many will think digital transformation is about application changes. In reality, this is transformation of your mindset to a configuration approach. You should be inclined to review products that are highly flexible and configurable instead of turnkey method. This is a commonly seen in many local offices where stakeholders try to engage local solutions to solve a global problem.

Tips for Configuration Project

If you are new to configuration project, you will likely need to adapt these few tips.

  • Configuration suits Agile.
  • Cloud allows configuration at various levels like infrastructure, applications or services.
  • Train insource SME (subject matter expert).
  • Organise your teams for configuration capabilities.
  • Engage management support to adopt configuration platforms.

The constant market changes and COVID-19 is spurring the configuration market. Many resources and education stay entrenched in software development practices. It is time you switch your mindset and embrace configuration practices. This way, you can stay relevance and adaptive.

What is Project Closure for Agile?

~ Danny Kwok ~ Leave a comment

A project closure is a last step in waterfall project. It usually signal the start of financial depreciation. If you are employing an Agile model, the view of project closure will not exist. How should this be justifiable for financial view? You may need to operate in a waterfall agile model to fulfill the financial concerns.

Relating Sprint Review

Perhaps a more appropriate and foreign terms for finance is sprint review. This is the end of sprint. It will take a lot of understanding to educate the financial how sprint review relates to project closure. You may group a few key sprint reviews into milestone for the purpose of financial obligations. A typical grouping could be a major version from sprint. This may usually be a monthly to quarterly frequency.

Agile Closure

The project closure view is different to Agile. The view to close an Agile project will mean the end of product life. You may want to communicate this end as early as possible. This will allows financial to compute from a budgeting standpoint. Thus, product owner may consider roadmap visibility for the product end.

Project closure have a different meaning for Agile projects. Meanwhile, finance numbers remained entrenched in waterfall mindset. It will take a few more years before a sound finance instrument is geared for Agile. For the moment, I will need to use waterfall agile for my reporting and implementation.

No Downtime Approach

~ Danny Kwok ~ Leave a comment

Application downtime is getting lesser and lesser with Cloud computing. Users are more demanding without the need of downtime. Thus, we need to move to the approach of hotfix and high availability environment.

Picture by Ethan
Shift to Zero Downtime

The design of zero downtime will require a digital transformation approach to your entire architecture. Another consideration is utilisation of the Cloud platform for different high availability approach. As this approach will incur additional cost like licences, you may want to evaluate a switch to pay as your use model instead of fixed licensing.

Development with No Downtime

Another key change is your development approach. This must be changed to reflect deployment with no downtime. Instead, hotfix and patches must be applied seamlessly without any downtime or impact to user operations. Therefore, your development will need Agile and DevOps to enable this approach.

If you have intention to move to a services with no downtime, it is time to reform your architecture and development approach. This involves utilisation of Cloud platform and Agile development to achieve this vision.

Agile Stakeholder Analysis

~ Danny Kwok ~ Leave a comment

Business analysis have process that involves the understanding of stakeholder. This process is called stakeholder analysis. This process is covered with assumptions made during during projects formation in Waterfall SDLC. Similarly, these stakeholders analysis can be conducted with Agile approach.

Agile your Knowledge of Stakeholders

In traditional project, we usually set a baseline on the understanding of stakeholders. As project progress, we seldom revisit or update our understanding of stakeholders. In an Agile project, stakeholder analysis become similar to your project cycle. Your knowledge of stakeholders are constantly updated with each Sprint.

Agile in your Stakeholder Analysis

Agile is result driven and focus on positivity in clearing the backlog. There is always a bad or black spot in all stakeholders. Like Agile, your stakeholder analysis must be aligned with positive nature and definition of done. Another key area in your analysis is to seek out close collaborator among your stakeholder. Not all stakeholder suits Agile and your analysis must identify Agile stakeholders.

Stakeholder analysis differs from Waterfall to Agile approach. You will need to seek out stakeholders who suits Agile in the course of your Agile project. The stakeholder analysis requires deeper understanding and iteration similar to your Agile.