If you are an Agile practitioner, you will realise that there is always a gap between Agile and Management. Not much have been stated on Agile for Management. Unlike Waterfall model, Agile is not big on reporting and generating of status report. Here are some tips on engaging management with Agile projects.
Waterfall model is so entrenched that entire reporting structure to management revolve around this perspective. The first step is to educate Agile and the differences between the Agile and Waterfall to the management. You need to set Agile expectations with your Agile champion. These champions must preferably from top management. You need to have a holistic approach to share the Agile approach to users as well.
One of the best part of Agile is lesser admin reporting. This leaves you more time to focus on what is to be done. Of course, Agile is timebox at duration that management can participate as observer. For example, management can join in daily stand up that should last between 5 to 15 mins. The most suitable updates for management will be the sprint review where they are invited for their feedback. This typically last two hours for a two week sprint.
Agile does not require formal reporting to management. We should always seek to educate management on Agile events like spring review. This is where management can provide feedback on the product. After all, this allows the Agile team to focus on delivering a “done” product.
Hypercare is a process in Waterfall SDLC (Software Development Lifecycle). It is very similar postcare you receive after a major operation. For many teams who makes the switch from Waterfall to Agile, management still demand the need of hypercare process. Is there really a need for hypercare for Agile SDLC?
Hypercare is Just a Sprint?
Hypercare is often regard as a warranty period whereby traditional waterfall all accommodate a degree of big fix due to scope creep. In Agile, there is no such process. Instead, the deviation. or gaps are recorded in the backlog. The backlog items may be selected for the next sprint. This render hypercare unnecessary in Agile. Effectively, management or users become concern for this missing warranty! Thus, you may find some Agile project do state a period of hypercare. However, this is actually the same as a sprint.
The Emergence of DevOps
Another key reason that hypercare is unnecessary is due to the rising popularity of DevOps. In fact, DevOps functions like a hypercare process with its quick turnaround, speed and rapid delivery. Agile and DevOps works hand in hand and you may consider DevOps in place of hypercare period. Therefore, your users and management will have a similar assurance that is given in the form of hypercare.
It is noteworthy that hypercare may no longer be required in the Agile and DevOps world. There is a need to educate and align users and management on these understanding. This may also include the change in future RFQ or procurement whereby hypercare could be removed. As a result, you will see a lower cost with the removal of hypercare process.
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.
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.
Backlog priority is a product owner responsibility. Agile technique state that priority must focus on deriving maximum benefits. However, there are many perspectives that a product owner can learn to derive the benefits. These are some quick practical ways to derive maximum benefits for your backlog priority.
Align Product and User Value
All users view maximum values from their perspectives. This is why backlog priority must never be provided from only the user view. Product owner must always match user values with the product values. You should not seek to please the users but look at the overall product. This is a simple rule of thumb, yet difficult to negotiate for backlog priority! The key is to align these values to a common ground. This will take a lot of practice for product owner and you must not get discouraged by unreasonable users.
Is the Story Logical?
Story mapping is a good technique to review the product and user values. There will be a good logical flow for a good story. A disconnected story will indicate a lower value. Some story appear as exception scenario and this will order it to the bottom of backlog. Thus, the story points or logical importance will help you to determine the backlog values. Subsequently, this will order your backlog in a logical sense.
Backlog priority is one of the fun moments of product owner. It will take a lot of practice to prioritise the backlog for maximum values. Agile do not provide a clear hard rules for backlog priority for a good reasons. As product owner, you will know what is maximum value and order your backlog in a clear manner. Of course, product owner decision is final and there can be only one!
You know that your project is not Agile enough when your user collaboration is not as close as you wish! User commitments is high in Agile project. Many have failed to consider the level of commitment required for Agile project.
Collaboration is Mandatory
In waterfall project, the project task is step by step. Users are not involved in all the tasks. On the contrary, Agile requires close collaboration from Day 1 with the users and developers. It is mandatory that collaboration started from start to the end of each Agile sprint. Without collaboration, your Agile will not be effective and you will not face difficulty in completing your story points.
Collaboration is Two Way
In a typical user developer setting, users often steer their requirements to their wants. Communication becomes one sided and left little room for negotiation for the developers. In Agile, users and developers encourages collaboration in a two way communication manner. Users collaborate in a non authoritative way and developers proposed the best solution at the point of sprint.
It is time to educate users when you are running Agile project. Users mindset will need a new change to adopt a collaborative two way communication approach to the developers. This will help to derive maximum benefits from each sprint.
Agile templates are getting popular now. There is no need to build many things from scratch. You can easily setup eCommerce shop within a day. Template are developed with Agile in mind and vice versa. Thus, you should start to develop Agile Templates instead of projects.
From many legacy applications, templates comes from the ease to reuse and the need to reduce cost. Project is a mash up and gelled need to address a focus objective. In contrast, templates address a particular story point and suit Agile perfectly. Agile team will gain most from towards templates more than previous project implementation exposure.
Shift to Template Management
The role of project manager (PM) will be on a decline as teams shift towards Agile approach. Instead, this role can move to a focus on template management. Some organisations will have similar approach like COE (Center of Excellence). Another big push is Cloud which emphasis a lot on templates for rapid deployment.
The shift in IT landscape is huge for the past few years. The COVID-19 pandemic is also a major push factor in accelerating these changes. We will see more of templates design and model from major cloud organisations. Their template libraries will be the key factor to lock in the customers, including me.
Digital transformation may be the trend now with many rushing to transform their digital technologies or implement new innovations. There are many success stories reported but many have comes with trial and error. The key is to identify what not to digital transform and avoid unnecessary wastage of time, money and efforts.
The evaluation for digital transformation is vague in many instances due to various results and differences of business domains. What works for banking industry may not be applicable for logistics domain. Thus, you need to have clear inclusion criterion to be setup for your digital transformation program. This will allows you to pinpoint the necessary system or tools to be transform.
The inclusion criterion is the first step to understand what are the key things that you can digital transform. It is highly recommended to run multiple pilots to understand the nature of the tools you going to use. With deeper knowledge through realistic applications, you can form the exclusion criterion on what cannot be digital transform. For instance, voice recognition may not work in heavily accent Asian countries with different dialects.
Digital transformation could be for the good, better or worst. You need to have a clear picture and understanding of the tools that you are using. Always seek to run pilot study to know the tools well before you embark on a major digital transformation program. In this way, Agile approach is for the best.
Backlogs or issue logs can be quite a conflict if you are running waterfall Agile for your project. Usually, issue logs are created for UAT and dictated by users who are not well versed in priority setting. Thus, the issues log will conflict the backlog handled by the product owner (PO).
Priority or Business Value
It is not surprising to see users set high priority to all the reported issues. On the other hand, backlog focus on how to derive maximum business value as its condition. As a PO, you can align both backlog and issues log by comparing business value against issue priority. The lowest business value with high issue priority should be delegated to the bottom of the backlog. Vice versa, maximum business value with high priority can be reviewed on the top of backlog.
Issues Impact or Story Points
Issues impact have a tendency to be blown out of proportion. This is why story points in backlog provided a better value and evaluation over issue impact. You can counter weight issue impact to the respective story points. Good story points can lead to better details and provide you a better understanding. From these details, you can derive the actual impact of the issues relative to the story points.
Issue logs have notorious name to blow everything out of context in waterfall project. You can apply strengths of Agile backlog as a countermeasure and sanity check with waterfall Agile.