Lean or Agile

With Cloud Technologies, there is a hype of Agile methodology replacing Lean practices. As I am of Engineering background and Agile advocate, I am in a best position to bridge and clarify the views for both practices. So, I will raise the awareness that Agile is never a replacement of Lean practices but can coexist and improve existing Lean processes.

What are Lean Processes?

Lean Processes roots comes from Manufacturing and Engineering. The sole objective of Lean is to simplify and reduce wastage in process and in mindset. By doing, you can be efficient and effective, getting the best output from your inputs. It is a way of life, methods, technique, principle or even philosophy. The best examples comes from Toyota “Kaizen” in its car manufacturing and Motorola “Six Sigma”.

Lean or Agile

Lean software development serve as early inspiration for Agile. You will find many similarities between Lean and Agile. Both emphasis on speed by different means. You may wonder which method should be adopted. Existing organisations which practice Kaizen or Six Sigma may find their IT development team using Lean concepts. Overall, the switch from Lean to Agile and vice versa can be conflicting. In some case, Agile is more pro software development while Lean methods can be used for all types of business units.

Lean and Agile

With a simple comparison of Lean and Agile, you can see there are advantages for each method. The key is not to be rigid and follow each method to the teeth. For IT teams who are deep in Lean methods, you can also adopt Agile into existing Lean principles. On the other hand, existing Agile team can introduce Lean into various SOP and relate to other businesses.

For more readings, you can refer to this book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.

Debunking Full Stack Role

Over the years, IT roles have evolved accordingly to technological trends playing catch up at many junctions. As times passed, I have tried different types of roles in various forms of organisations. However, we have kindly seek to divide domain into project manager, business analyst, developer and tester. With emergence of Cloud technologies and Agile, these roles are gradually merging again into a role called Full Stack.

What is Full Stack role?

Full Stack role is nothing new but a rebranding of an old role I used to call Software Engineer! In fact, I would say that Software Engineer can do much more. That will be a debate in another article. To understand Full Stack, we need to delve into a bit of history. Back in Open Source days, a Stack is refers as a set of systems that is required to run the application. The most famous stack will be LAMP (Linux Apache MySQL PHP) in the Dot Com age. Basically, full stack role will involve a mastery of the solution stack e.g. LAMP stack.

3 Myths to Full Stack Role

For those who are in the Dot Com era, we will be de facto Full Stack! This also applies to techies who have worked in Startup. After all, you are expected to setup everything from end to end from Servers to Applications.

Myth 1: Full Stack is a specialised role.

As opposed, Full Stack role involves knowledge to set up end to end solution. This is actually a generalist role to configure the system architecture which is getting common in Cloud Technologies. Only then, the deployed application can be transferred to the Subject Matter Expert (SME) for engagement with users.

Myth 2: Full Stack role is difficult to find.

Once you understand the fundamental of Full Stack Role, you will realise Full Stack has existed in many parts of existing IT roles. This role can be easily found in Agile team or Startups as they are expected to handle a variety of solutions stacks. In many cases, SME or Solution Architect can often act as Full Stack developer.

Myth 3: Full Stack is a competitive advantage.

Sadly, coming from the world of Open Source, it is quite depressing to see the misunderstanding of Full Stack role. One may feel that having Full Stack is a competitive advantage. In fact, this is the opposite. Full Stack knowledge will become a commodity because most of Cloud Technologies offer templates with quick deployment methods that can be setup within hours. We shall see a decrease in this role as Cloud technologies mature. On the contrary, there will be a continued focus on SME and specialisation of domain knowledge. Let us not be sidetrack and go back to being a generalist just because it has a nice ring in “Full Stack”.

Jack of all trades, master of none


Implementing Waterfall Agile

Agile software practices can be implemented with discipline in majority of projects. In many organizations, the project approval and management remains in Waterfall mode. So, how should you approach to be Agile within the Waterfall culture?

Agile within Waterfall

As mention in my previous article, it is a challenge to apply Agile within a Waterfall organisation. As opposed with many bias, Agile is a very practical and disciplined practice. Implementation of Agile will first require a mindset change for the team. However, some teammates are so entrenched to Waterfall approach that Agile becomes a drastic change. Similarly, organisations are resistant if you choose to declare the usage of Agile in your project management. So, a neat approach is the ubiquitous introduction of Agile using its techniques. Two such methods are timeboxing and product backlog.


Timeboxing is a technique to complete the assigned tasks within a fixed time. It is used in Scrum as daily meeting and sprints. Waterfall have a longer time horizon, fixed milestone and timeline. There are similarities of timebox and Waterfall. You can easily apply timeboxing in your development team to score quick wins from Agile. Over time, you will learn how to timebox and coexist within Waterfall plan.

Product Backlog

Product backlog is an artifact of Scrum that can be utilised for Waterfall. It is very similar to feature list, requirements, issues or parking lots. Unlike Waterfall, Agile consolidates anything required by the product into a single backlog. Priority and business value are set as well so that business and IT have a single view of the product backlog.

Be Realistic

You must be mindful to be realistic in your Agile expectations. Go for baby steps if your organization is traditionally Waterfall. Telling your management that there will be no project manager due to Scrum would scare the “hell” out of them. Be bold to apply and fuse components of Agile within the Waterfall cycle. Like Agile, you need to keep iterating to arrive at your definition of “done”. You need self reflect and benchmark your success of implementing Agile. In time, you will reap the benefits as more Agile components replaces Waterfall. Lastly, be resilient and do not give up as Agile is here to stay.

Agile POC with Cloud

It is a fast life now. Setting up server used to be months compared to minutes of provisioning one in Cloud. First, you have to prepare and renovate a server room, if you do not have one. Then, the physical server may take weeks to arrive. After that, you have to purchase the required licences for the server operating system (OS). Installations and configurations will take another week or so before the server is ready for usage.

As application owner, it is a time consuming to conduct new proof of concept (POC) by going through all these steps to acquire a server. In many cases, we skip POC and move directly to project phase to save on these lead time. Now, POC can be easily implemented with Agile by Cloud. It is time to brace ourselves to a brave new world!


The emergence of Cloud accelerates how we can do our proof of concept (POC). With the difficulty of getting hardware, POC is often avoided for conservative organizations. It is less risky to stick to proven technology and applications. Waterfall process also slow down the process as having POC adds cost and time. While these are common excuses of not having POC, the advantages outweighs the cons for new technology like Cloud. This is because POC will lower uncertainty and risk by exploration in real environment for many stakeholders.

Agile POC with Cloud

Cloud technologies have changed the mindset towards POC. The constraints of acquiring hardware are nearly eliminated and thus solving a huge lead time issue. Server provisioning templates or machine images can also be setup to iterate POC quickly with ease. The best timing is the adoption of Agile methodologies and Cloud technologies that fits the implementation of POC.

To POC or not to POC

From stakeholders view, there seems little disadvantages not to conduct POC to mitigate risks for new technologies. Business can evaluate the relevance with minimum costs before making decisions to invest in full implementation. Information Technology (IT) team can review new capabilities without plunging into unknown from preparation with POC. To POC or not to POC, you can easily decide with Agile and Cloud.

Pseudocode as a Job Skill

Java, PHP, JavaScript and C are some of popular programming languages that have been used in application development and widely stated in job requirements. Yes, I deliberately drop Python because I still feel it is trendy due to machine learning (ML). However, Pseudocode is one job skill that has been neglected to be stated in mainstream job ads.

What is Pseudocode?

Pseudocoding is not actually a programming language but a technique to describe readable system steps for users and developer. It is structured in such a way that is readable for end users yet functional for developer to code in any languages.

Sample Pseudocode
Why Pseudocode?

In my “old days”, pseudocode is important and taught as part of computer subject. It is a must-have skill for all coders for its emphasis on algorithm over programming syntax. As such, it is surprising to me now that some coders do not know pseudocode when being asked to demonstrate this skill. A good coder with strong Pseudocode skillset can easily switch across different programming languages compared to one who only know certain programming languages.

How to Choose Excellent Coders

Like all arts, normal coders are easy to find. The excellent ones needs to be sift through the midst of programming languages as they transcend across different codings. One way to identify such developers is to apply the fundamental practice of using Pseudocode. There will be a shift in mindset to reduce the reliance of hard skill and turn to applying the basic logic of programming with Pseudocoding.

Helping Enterprise Architecture (EA) be Agile with Cloud

Strategic and Operational excellence are key objectives for many organisations. It is difficult for organisations to achieve both at the same time. Most organisations tends to focus on one or another, investing resources in either one. Business often emphasis strategic needs while IT focus on operational excellence. There comes a period where an organization needs to bridge these objectives together. Enterprise Architecture (EA) is one such bridge to bring these two objectives together.

Enterprise Architecture (EA)

Enterprise Architecture (EA) aims to provide a holistic view of business and IT with the aim of aligning strategic and operational excellence. It aims to provide a bridge between business and IT with standardized EA framework of common vocabulary, models, tools and content metamodel. However, the notion of EA can be very far fetched and ideal to reality because many of EA program are abstract and conceptual in nature.

Agile and EA

The practices of EA runs contrary to the discipline of Agile. Huge efforts are expended to standardize and collate information at Enterprise level losing sight of Agility. Traditional EA ultimately fails to deliver because it is not able to address the business needs timely. Enterprise strategy become obsolete and irrelevant as technologies innovate faster and faster. As EA continue to remain coupled to traditional waterfall, Agile methods gradually become the mainstay for adapting to business excellence.

How can Cloud help EA be Agile?

Thus, we have seen huge gap of EA in being Agile. Luckily, this can be addressed by Cloud technologies. Any system within cloud platform can be quickly be viewed holistically and automatically be generated as a blueprint of EA. Cloud technologies have also retain its Agile capabilities to fit strategic innovations for business while fulfilling operational excellence.

What is Shadow IT?

I came across a term Shadow IT and find it “amusing” and yet relatable. Shadow IT are Information Technology (IT) systems setup by non-central IT teams with the objective of bypass or overcome the cons of central system. Looking back, I had been on both ends of Shadow IT, a creator and eliminator.

Making Sense of Shadow IT

What gives rise to Shadow IT? Waterfall evaluation, procurement and budget approval often takes longer time to review as usual. From business view, this contradicts agile and speed of adapting to change. With agility, Shadow IT provides a window of innovation and prototypes to the incumbent central IT.

Cooperate, Assimilate or Eliminate

Like rebels, the objective of Shadow IT serves an alternate voice to centralised IT. If the Shadow IT remains niche, it may usually end up being a cooperative system and even can integrate to the central system. Of course, there will also be a scenario which Shadow IT become the innovated solution and this could be easily assimilated into the incumbent IT with better budgets and resources. In worst case, Shadow IT may face elimination organically from pressure like compliance and security or inorganically from obsolete technology or support.

Future of Shadow IT

Cloud technologies have actually encouraged Shadow IT and central IT must recognise the value of Cloud towards Shadow IT. Sandbox can be created to allow business to create Shadow IT in a controlled space. There will come a time where Shadow IT coexist and central IT must learn to manage and leverage the advantages from There are some interesting read that you may want to check it out for this topic e.g. Shadow IT A Complete Guide – 2021 Edition.

Waterfall Agile Hybrid for Cloud

Agile is a pretty huge demand skillset now. It must be surprising to think that Agile was once frown upon as a non-mainstream methodology in the past. I used to be one such “hidden” Agile practitioner until I came out in 2013.

Journey to Agile

Agile have its roots from many models and one of them was Rapid Prototyping Development (RAD). I was exposed to RAD using tool like Visual Basic. This was where I begin to explore incremental changes deployment rapidly contrary to a traditional Waterfall development model. Without realizing, I had started my journey towards Agile methodologies.

Formalize Agile with XP

As I became more experienced with RAD, I decided to look into a formal methods that could incorporate changes faster and systematically. A new paradigm opened up in the form of Extreme Programming (XP), with concepts of pair programming and emphasis of code quality over documentations. It was not easy to implement XP in a traditional team setting compared to using Agile by myself.

Minority Agile

The limitations of Agile shows itself when I tried to implement XP for teamwork. The Agile mindset was more difficult to adopt for many as majority of education system had emphasised on Waterfall model. The lack of support towards Agile methodology was disheartening during the period of 2005-2012. However, I had persisted with Agile even though it remains as minority within the IT space. Putting my signatory in agilemanifesto.org had helped to serve as a constant reminder to strive on with Agile.

SCRUM certification

In the midst of my search for an Agile company, I came across a job requirements for SCRUM. In a way, the emergence of Agile or SCRUM in job ads shows signs of change in the Software Development Lifecycle (SDLC). A key reason for this change came from the shorter deployment time of mobile application and eCommerce. Gaining confidence that Agile will be the game changer, I got certified with SCRUM instead.

Waterfall Agile Hybrid Model

The expected surge in Agile did not really take off as much as I expected from 2014 to 2016. SCRUM soon died away as well. As what Agile preach on handling change, I learnt to incorporate Agile practices within a Waterfall model which I termed the Waterfall Agile Hybrid model. This model fits systems best with configuration paradigm and cloud technologies while conforming to the norms of Waterfall.

Waterfall Agile Hybrid for Cloud

The explosion of cloud technologies pushed Agile into mainstream! Cloud implementation multiplied and marry Agile with it. The rest becomes history as Waterfall took a backseat. While Agile becomes the new norm for Cloud, the Waterfall roots remains entrenched in many parts of organizations ranging for budget planning, approval process and finance. Thus, Waterfall Agile Hybrid model remains relevant until an organization completes its transformation to a pure Agile entity.