We have often know that there is no Project Manager (PM) role in Agile project. However, many organisations still retain the symbolic PM role. This is not cost effective and why does organisations preserve the PM role.
Why PM is Staying
Unfortunately, PM hold a great political position and influence for many organisations. While there is a shift from traditional waterfall to agile, PM role continues to remain for a main reason. That main reason is coordination. The PM role is now relegated to a coordinator role. This role is focused to coordinate the reporting between the project and management. In other words, this information gatekeeper role places the PM in an influential and yet non productive position.
Although Agile does not require PM, there is a dire need to remove information gatekeeper. Therefore, you are seeing an emerging role of Agile PM. This role are actually a hybrid of Agile developer or product owner who take on the additional efforts to connect with the management. In another words, they bridge the gap between Agile team and management. Effectively, this should remove the information gatekeeper influence and gap.
For many Agile team, we have agreed that there is no PM. However, the reality of PM existed for many organisations. These PM may not understood Agile and become information gatekeeper between Agile team and management. While a role of Agile PM is emerging, the battle continue to either remove or bridge the gap with Agile PM.
A major advantage of interpreted programming languages is ability to read the source codes. It is also lightweight than Java and can easily setup to run without much errors in the development environment. This makes it a great favourite with non computer science users. I am also one of those who have a preference over interpreted programming languages.
Users Self Service
The citizen programming community is getting really vibrant. This will translates to users in organisations. Compiled languages are machine codes and cannot be easily viewed by users if there is an error or bug. You will need to setup the development environment. For interpreted programming, you can self service to read the erroneous codes without the need of complex development environment.
For the newbie in IT project, hypercare must be a new term. There are many approach to conducting hypercare. It can be confusing over the difference between standard support flow and Hypercare. Often, cost is proportional to the duration of Hypercare. This means that the longer the Hypercare period, the higher the cost. These are some of the standard methods used for you to understand Hypercare quickly.
Hypercare consist of the following basic process and approach.
Assurance to fix bugs during the Hypercare period, also known as warranty.
Dedicated resources available during the Hypercare period.
Quicker turnaround to provide issue analysis similar to DevOps process.
Not in Hypercare
There are a few areas that are not covered in Hypercare. Notably, they are mainly related to changes.
Change management are not the scope of Hypercare.
User change request will fall outside of the Hypercare scope.
The Hypercare only covers the intended system. Related issues that are found to be caused by external system are not within Hypercare scope.
Hypercare is a common term used for project warranty. Like all warranty, it is constraint to the intended system and have conditions. The coverage and duration of Hypercare is proportional to the amount of money you are willing to fork out. Do be aware that Hypercare is not a God Mode that solve everything that happens after Go Live.
Today, I have a very interesting discussion on data modification process. There are two integrated systems with a constraint of one system accepting modified data. This is a very standard constraint in many networked applications. How should you overcome this constraint? This is where you need to have a very good SOP (Standard Operating Procedure).
SOP is Cost Effective
A good IT person should always learn business process and how to adapt SOP with system flow. Application does not work on its own but in support of SOP. In most cases, it is more cost effective to handle exception scenarios instead of customising. A good SOP works hand in hand with application. These combinations will lead to a balance trade off on standard applications with different customers.
SOP helps to simplifies many business process. This allows your system flow to be direct and fast. A poorly designed system often exist with no SOP in place. The lack of governance leads to many data errors and system interlocking rules. Thus, you need to think of SOP as the approach to simplify your applications.
SOP exist long before IT have arrived. The full strengths of SOP can be realised in the tightly coupled systems. Without SOP, these coupled systems will hinder rather than accelerate your data flow.
Projects are usually encountered with a constant that is consistent. I like to call it a constant delta, oxymoron intended. For the noobs, this is frown upon and recorded as issues. Instead, a positive mindset is encouraged to embrace these delta. You will notice that Agile is unable to exist in organisational context due to traditional structures, policies and roles.
Another View of Delta
Delta management is rarely emphasised because traditional project management focus on fixing scope, time and cost. Variables are deemed to be risks with negative impacts for projects. This view of delta does not change until the recent explosion of Cloud technologies with Agile. The Agile project is a 180 degree view to regard change as constant. This paradigm shift to handle changes instead of freezing scope brings upon a new view of Delta.
Human Avoid Delta
Unfortunately, organisational view remains entrenched in fixed scope. The slow rate of change is consistent with human reluctance and avoidance to change. There are no revision of organisation policies or financial tools to manage delta. This lack of knowledge and uptake will persist for the next 5 years until all applications moved fully to Cloud.
Agile is the best technique to handle constant delta in projects. For many Agile practitioners, we are frustrated by the lack of delta management in the organisations. The gap between Agile and constant will remain unless there are more efforts to focus on how to incorporate delta within organisations.
Scope creep is one of the most common issues in all projects. It is so common that this should not be consider as an issue. Instead, it should be preemptively managed and anticipated. Scope is always constrained by time and cost.
Project scope can be standardised in many aspect via Agile Templates. By using a baseline with templates, you can anticipate the extent of scope creep for your projects. Rather than setting expectations, you can set anticipation on the type of scope creep. This allows you to allocate the type of resources. High anticipation will result in the need of quality resources to manage scope creep.
Scope Creep is not an Issue
You may find many of the scope creep surfacing in issues logs. Thus, this will place a lot of stress for development team to clear the “issues” for Go Live. You should query the ROI (Returns On Investment) and justifications when such scope creep is listed as issue. For many cases, such issue end up as Change Request (CR) or Backlog items.
Scope creep is a staple of projects. It is time to embrace these human behaviour as scope is often underestimated. Therefore, we shall learn to embrace and manage scope creep wisely.
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.
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.
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.
Setting good status value is key to analysing your transactions. These are some good tips to setting good status and its values.
Keep your status type to less than 3 if you want to remember the status dependency.
Set your status value in a forward logical flow.
Avoid ambiguous status like reopen that will mess up your statistics.
Do not create conflicted status value for status type like Done for a status and “Pending” for the other.
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.
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.
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.
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.