A key concept of Agile is to timebox. I usually refer it as the “Divide and Conquer”. Scope and requirments comes hand in hand in shaping on what can be done by the end of timebox. Although Scrum timebox daily, the reality is not true of that.
What to Divide
The rule of thumb in dividing the tasks is to find the easiest component. Completing the easy component leads to clarify. Once completed, you can further determine if the task can be split further. So, how do you identify the easy component? Easy usually refers to below criterions:
It is known solution and you can complete easily within an hour.
The task component have low risk.
You can reuse the task component.
Conquer After Divided
After you divide your tasks, it is ready to be completed within the timebox. Some of the divided task may be added back to the backlog as it will exceed the timebox. You shall take many iterations to improve on your timeboxing. One key things you learn is the ease of completing your tasks after you divided it in the most effective way.
Have you ever meet user who like to ask if this or that can be done to change the system? That someone will also like make recommendations to the system. An age old answers to them is always “Time Scope and Cost”. It is usually easy to make suggestions or recommendations without such constraints or understanding of the system. So, how should we deal with it?
The Ignorant User
Some user will always be ignorant and oblivious to the basic of “Time scope and Cost”. For such user, the best way to handle is a detailed SOP (Standard Operating Procedure). With SOP, everything is documented with full transparency. If it is a product constraint, you can also state it clearly. All communication will need to formalise to prevent repetitive explanation with the ignorant user.
The “Want It All” User
There is another set of user who wants every features and yet having non existent scenario or test cases. This is the dreaded scope creep where development team waste valuable time designing for non existent requirments. I often apply Agile and scalable solution to handle such user. Agile allows your solution to scale if the “said” scenario occurs.
In every projects or production support, there will always be users who falls under the above categories. They usually have no understanding of time, scope or cost. You can easily be transparent and show your SOP. Do also consider applying Agile and design your solution to scale easily.
There is a trend of MNC hiring that requires a working stint or experience in a Startup. One reason is the ability to innovate with minimum cost for a startup. Of course, you will not see such phenomena if you always work in a MNC. So, why are MNC looking for startup capabilities? I will relook my own experiences in Startup and explain quickly why it is such sought after for MNC.
What is a Startup Mindset?
In a MNC, majority of IT are outsourced and dependent on vendors. You give requirements and vendor provide cost and quotations. In contrast, startup have lower cash and can only able to rely on its most valuable skills i.e. human capital! IT solution are often open source and incur zero licensing. The constant need to be creative and innovate with minimum cost will hone the startup mindset in an individual.
Think like a Startup in the MNC
In a startup, you are always hands on for all implementation from business analyst, developer, tester, support and even pre sales. This is the perfect Agile team competencies and each members are capable to handle end to end project implementation. The view is not to rely on vendors and focus to build resource competencies in-house.
It is good to see MNC looking to acquire startup resources or people with such experiences. However, you can also encourage such mindset with a single leader who have such expertise. All I can say, it is not easy to create startup mindset for your team. Do not give up as the rewards are worth it.
Do you have a list of backlogs or a product backlog for your Agile project? In traditional waterfall project, you will find many many lists like issue logs, parking lots, features list or even wishlist. A project manager is literally a full time administrator for maintaining these lists. Oh yes, an Agile project do not have a project manager!
The Pros of a Product Backlog
A product backlog is a single source which all members refer to. It can hold your features, issues, wishlist or any tasks that is required to achieve your agile outcome. You can also breakdown any items from product backlog. It is usually arranged such that higher priority items are on the top of the list. You do not need to keep multiple types of lists and thus reduce a lot of “admin” task.
Improvised your Product Backlog for Waterfall
A true Agile project seldom exists in many large organisations. Thus, we often run a waterfall agile type of project. You can still streamline all your listings into a single product backlog. All you need to do is tweak a column for different point of view. Of course, the first step is to merge all the various lists into a single one. Do manage your stakeholders views carefully for this “simple” change.
Agile have many good artifacts that aim for speed and low maintenance with maximum outcome. Product backlog is one that you can consider to implement in your existing waterfall or hybrid project. We should acknowledge that the results outweigh the “efforts” put in creating nice lists.
If you want to know the details, you can go through the code.
Recently, I got a surprising comment from an AMS (Application Managed Support) vendor above. This really confirm my view that AMS will be obsolete in the emergence of DevOps. Luckily, our team have been less reliance on AMS and transitioning to DevOps model over the past few years. Therefore, there is totally no issue for our team to read the codes. However, such mindset is the reason why AMS will be replaced in the next few years.
There is little value add for organisations to support AMS with focus on clearing tickets and reduce SLA.
AMS objectives are outdated due to paradigm shift to Cloud and Agile.
There is no knowledge increase in AMS resources to achieve better Customer Experience (CX).
The values of AMS contradicts that of newer paradigms.
AMS is gradually being replaced by either DevOps or Self Service Technologies (SST).
New experiential indicators are gaining popularity to measure user satisfaction.
It is more cost effective and efficient to replace than to retrain existing AMS.
These reasons serve as constant reminders that new paradigm will always replace in favor of old. It helps to push us to seek long term skillset in preparation of this shift. Thus, we should not be contended in our comfort zone.
Many years ago, I was astonished that development team and support team were separated in large organisations. Coming from smaller organisation, I often need to handle support after development and relate the pain points of support. In some cases, I add the support requirements to my development efforts to factor the changes encountered during support. Time have shown that DevOps are better in many aspects compared to traditional AMS (Application Managed Support).
It is the support team issue!
Project duration is often short and development team usually code against known requirements and test cases.
For future risk and issues, development team tends to transition this to support team.
Support issues that require change is considered enhancement.
Data or user education are support team issues.
Enhancement is developmentscope
Support team are measured by support ticket and SLA (Service Level Agreement).
Known issues are easily fixed and can meet meet SLA.
RCA (Root Cause Analysis) are only done upon requested and there is no incentive to resolve root cause for support team.
Resolution of root cause falls under enhancement and belongs to development scope.
There is now a demand for DevOps as many organisations switch to Agile. The disconnect between development and support can now be resolved. However, this will comes at a steep cost as DevOps is more than development and support.
I find an interesting item while decluttering. This item reminds me of digital transformation and migration. So what have these two subjects have in common?
DigitalTransformation of LegacySystem
Digital Transformation comes at a much steeper cost if you have legacy system. The key consideration is what you should and able to transform. Although there are many consultants who can advise on the subject of digital transformation, very few can tell you what you can transform in relative to your existing legacy systems. This creates a dilemma of whether to starting afresh or maintaining your legacy systems. Inevitably, you will need to consider migration approach instead.
Migration of legacy system
The decision on migration of legacy system is typical of big organisations. However, this comes a huge risk which are common to all migration project i.e cost and duration. Do start with a simple checklist before you make this decision. They may increase the success rate and decrease the migration costs.
Do you own all the source codes or the capabilities of your legacy system?
Can the pilot migration be completed within 3 months?
It is a simple checklist but difficult to achieve. Experience shows that duration is proportional to cost and greater success is achieved with quick deployment. In-house SME or Agile DevOps will ensure you can handle any migration constraints between legacy and your transformed system.
Unknowingly, I have spend more than 5 years with TMS (Transportation Management System) using OTM (Oracle Transportation Management) system. Overall, I enjoy the ease of configuration to deploy Agile solution using technique of DevOps. The control of global TMS solution also create high degree of adaptability for the team.
How to Agile your TMS
TMS have short transit window. It is favorable to adopt Agile.
Do design for change rather than design on sign-off requirements.
Configuration solution with custom plugins can cater for all TMS scenarios.
Determine your Agile components.
When to DevOps
DevOps complement Agile approach. This suits TMS because TMS contains many exceptions in the real world.
Use DevOps to close your loop in Agile implementation.
Consider to include monitoring tools or reports and analyse your data to determine your solution effectiveness.
TMS is usually 20% localisation. You may choose to DevOps on these localisation.
In summary, TMS needs a good product platform. You will also need to train your your TMS team to be Agile and DevOps ready.
Multimodal design is gaining in popularity for Transportation Management System (TMS). Multimodal refers to the different types of transport mode like truck, barge or air. Does multimodal creates more complexity for your TMS? Here are some tips to consider for multimodal design.
To start off with multimodal design, you will need to ensure you have expertise or SME in-house. They are required to tweak and harmonized the multimodal data.
Transport modes have common grounds. Look at existing data for comparison. Remember the 80/20 rule.
Find the common fields from your commercial who will tell you their views in cost margin and ease of selling the products.
Go for simplicity and ease of maintenance in your solution design. If it is more than 5 steps, consider to review and revise your solution.
Utilise Agile for tweaking and improvement with data.
Build your multimodal knowledge base. This is incremental efforts and takes time to nurture your in-house capabilities.
Multimodal design are advanced model and sign of maturity in your TMS program. Majority of TMS SME will apply various forms of multimodal approach. Till date, the best solution is not geared toward complex and elegant design but rather on simple and fast approach.
When you are doing Agile, you naturally gain a new skillset on exit planning. This is due to the time box that is set for your changes. Waterfall favor extensive test coverage, testing and sign off. On the other hand, Agile focus more on code quality, speed with CI/CD (Continuous Integration/ Continuous Delivery) methods. In another words, you formulate your exit plan while building for Agile. This is also commonly known as rollback plan.
In recent times, this is rename as DevOps that function in similar manner. In my team, I always emphasis End to End knowledge i.e DevOps and a need for Agile Exit Plan. Here are some ways of building your Agile Exit Plan while moving towards DevOps.
Good Agile deployment must have resilience way to monitor and rollback your codes.
Data integrity is a majority of deployment errors. Cultivate good code quality with exception handling.
Train SME (Subject Matter Expert) who can provide good advice on exit plan for each Agile deployment.
Develop 80/20 rule for your Exit Plan. Factor 20% as exception and focus your resources on the 80.
It takes years of practice to master Exit Plan with waterfall approach. However, Agile is so intense that you can hone your skills within a year or two. If you are also handling Production like me, you are DevOps before you realise it.