Monday, February 18, 2019

The Case for Portfolio Management

As mentioned in my earlier post, "Project portfolio management — or simply portfolio management — is defined as the “centralized management of one or more portfolios that enable executive management to meet organizational goals and objectives through efficient decision making on portfolios, projects, programs and operations.”

So who really needs portfolio management?
A start up company or one who is responsible for investment and work to be accomplished within an organization needs a project portfolio management.

Effective portfolio management aligns corporate investments and resources with the overall strategic objectives.

The net effect of a good PPM model is that business units can make a stronger contribution to the overall business strategy and bottom line.

With portfolio management, we would expect the following benefits.
  • Increased IT performance through discipline and mature PPM practices.
  • Avoidance of additional IT spend on efforts that do not align with the business strategy.
  • Earlier identification and corrective action for troubled IT projects and programs, and 
  • Improved communication and risk management effectiveness for IT and the business.
For portfolio management to succeed, recognizing the need and obtaining buy-in from the sponsor is important and critical.

Management organizations like PMO are an effective way to organize and manage an enterprise portfolio and enable others responsible for management and delivery of IT products and services to operate in an effective manner.

Portfolio management also encompasses governance and resource allocation, ensuring compliance with standards, alignment with strategy, and ensuring optimal resource usage.

For effective portfolio management, clear and effective communication channels are critical to be established between all stakeholders in the portfolio.

Monday, February 26, 2018

Scrum or Kanban? It depends on the type of project

The Agile framework has 2 significant or Key methodologies in today's software project environment. Both are equally efficient and produce results. However, if the right methodology is used after accessing the project you are handling, that is when you get the right results. Also, over a period of time, as the organization project management model changes, one can switch from one methodology to other.
But, how do we decide if we should use Kanban or Srum? For this, let us understand what these two are. There are some similarities and some differences as well between the two.
Scrum follows Agile methodology to carry out complex projects. It focuses on team collaboration and creation of  a framework such that the team is completely committed to create innovative solutions for all challenges. There are small set of rules which need to be followed to the letter and punctuations.
Kanban is another similar yet slightly different framework that is used to implement Agile methodology. Kanban breaks down tasks into manageable chunks and uses a Kanban Board to visualize those tasks as they progress through the workflow.
Both Scrum and Kanban strive to increase quality along with productivity and bring efficiency in the organisation.
Now, coming to the key fundamental differences:
Scrum depends on atleast 3 prescribed roles: Product Owner, Scrum Master and Team members.
Kanban has no set of roles prescribed. Practically a project manager for supervising the work is sufficient.
Scrum plays heavy emphasis on schedule. Each sprint is time bound. Whatever does not fit in a sprint moves to next sprint.
Kanban has no time boxes or iterations. However the focus is on getting a set of work done or completed as planned based on the capacity and timelines.
Scrum has columns / sections that are labelled to reflect the periods in workflow beginning with Sprint backlog, work required for the definition of done and the actual work completed. So, stories added to the sprint based on the past sprint velocity should appear in the completed section or column of the sprint.
Kanban board has columns to show workflow states. They are published with maximum number of work that can be completed in a time frame based on estimates with no time boxes. So, sprint length can vary and need not be constantly time boxed.

There’s really no way to answer the question on what fits in which type of environment. Both Scrum and Kanban are powerful, proven process tools that can vastly improve your project management. The best option is to become familiar with both of them and experiment with various aspects of both in your production environment. Creating a hybrid of both is perfectly acceptable if that works best for you.

Sunday, November 5, 2017

Portfolio Management

On request from many, I am posting this article to cover the fundamentals on portfolio management.

So what is portfolio management?
There are many definitions available in different books and on the net. But, I would like to go with the standard one provided in PMI.
"Project portfolio management — or simply portfolio management — is defined as the “centralized management of one or more portfolios that enable executive management to meet organizational goals and objectives through efficient decision making on portfolios, projects, programs and operations.”

These projects or programs can be related technologically, financially, or entirely unrelated to help achieve the common business goals and strategies. 

A key result of PPM is to decide which which projects to fund in an optimal manner. Project Portfolio Optimization (PPO) is the effort to make the best decisions possible under these conditions.

Enterprise Project Management:
Enterprise Project Portfolio Management (EPPM) is the practice of taking a top-down approach to managing all project-intensive work and resources across the enterprise.

IT portfolio management is specific to the IT industry. It is the application of systematic management to the investments, projects and activities of enterprise information technology (IT) departments. Examples of IT portfolios would be planned initiatives, projects, and ongoing IT services (such as application support). 

IT portfolio management contains three major portfolios or areas:
Application portfolio
Infrastructure portfolio
Project portfolio

Information Technology portfolio management as a systematic discipline is more applicable to larger IT organizations. In smaller organizations its concerns might be generalized into IT planning and governance as a whole.

In my forthcoming blogs, we will deal with each of these in more detail.

Sunday, September 24, 2017

Actionables from Successful PMO's

In my previous article, I mentioned about what successful PMO's do at the strategic level.
To sum it up, they are strategically aligned, a vital part of the planning team, embrace core competencies, and show consistency in the project execution and yet flexible in their approach to managing change.

So, the PMO have following key areas to focus on:
Having a clear strategic vision
Staying consistent in delivery practices
Flexibility to align to the changing business goals
Playing an active role in overall ownership

The road to achieve success for the organisational success is to have visibility at the top level. The PMO would have a say in critical business decisions and work closely with CxO's and VP's.
So, a right approach is what helps in ensuring that this happens. And to achieve this, the key ingredient is to work on the fundamentals and ensure that the basic things are as a matter of fact working.
1) Keep it simple: Simplicity removes the room for different interpretations and gets everyone on the same page, especially when one is working in a global environment across culturally different teams. So, the PMO's focus on using standard metrics and processes. This sounds simple but the real challenge lies in internalizing it and implementing it across the organisation and making it work.

2) Focus: The PMO's ensure that  the processes and metrics defined are aligned to the strategic goals of the organisation. This ensures all stakeholders across all teams believe and rely on the processes and metrics.

3) Action, Action and Action: This is the main result and outcome, else all the strategy, planning and concepts are futile. All processes and KPIs are in-vain if they do not result in actions. As an example, increase in revenue is directly proportional to the operational excellence. And successful PMO's aspire to track KPI's that help relate to this.

4) Measuring PMO value: This is subjective and depends a lot on the maturity of the organisation and the PMO model itself. But if implemented correctly, can help in measuring the return on investment (ROI) of the PMO team itself.

The KPI's that the PMO can focus on is shown schematically in the diagram below:

Sunday, September 17, 2017

What successful PMO's do?

In today' rapidly changing business environment, Project Management Offices (PMO's) struggle to provide adequate support for the shifting priorities and faster delivery cycles. The basic reason for a PMO's failure in an organisation has been that they have remained stuck to solely reporting and prioritization function focused on tactical project management. However, the need of the hour is to enable leaders to develop and implement strategies that drive better business outcomes.

These are the so called next-gen high performing strategic PMO's empowering their executives to act with greater agility and achieve better business outcomes. Such PMO's have been more successful compared to their counterparts doing the run of the mill PMO activities.
Based on Forrester research, there are four key findings about successful PMO's:

1) They are members of the executive management: If PMO wants to be part of strategic results, they require strategic positioning. Such champions are strategically positioned and work closely with the CxO's.

2) They are vital part of the strategic decision makers: For successful PMO's, portfolio management is key. They apply the learning from portfolio management to help shape strategy by providing feedback to the executives regarding performance, resource utilization and even customer feedback.

3) They embrace core competencies: Successful PMO's invest on sharpening their axes on project management learning, so as to be excellent in their core competency.

4) They use consistency across industry and regions: Successful PMO's are sensitive to culture. They apply their learning and soft skills to ensure that the processes and objectives are consistent across the organisation, across departments , be it customer facing or product development. They help drive the organization towards excellence.

Sunday, May 14, 2017

Vital signs that tells you that Scope Management needs attention in your organization

Almost all projects would have a scope defined base. Those projects that don’t have a proper scope management in place would definitely be at a peril. Though most of the managers realize the importance of scope management in the first place, they almost fail to execute it properly. Either the processes are in place, but not effective enough, or there is not enough maturity for taking scope seriously. Such organizations would normally give a fair bit of reasoning such as we are always on our toes and our project environment is far dynamic, or our resources are working day night to ensure that the customer is satisfied by providing last minute patches/hot fixes and last minute requirements.
If one looks deep into the situation, one of the reasons is the pure lack of scope management, which causes a cascading affect on unrealistic planning, poor quality of product, lots of over work and thereby causing low morale of employees.
Though there could be so many reasons/ signs, here are a few vital ones that will indicate that scope management needs attention. It could mean that the project manager would need to carefully examine and  bring in positive changes in the scope management related processes:

The team has trouble getting the project off the ground.
This is the first sign that shows that the scope mgmt related process is either not working or is not in place at all. Team members would be looking at previously executed similar projects and assuming that they would work on the project accordingly. Everyone would be thinking that he is doing his job well without looking at the big picture.
Number of False starts .
This is another vital sign where the project team would plan out the requirements to be done and then after a few days or weeks realize that the requirements/ scope were somewhat different than what the customer wanted in the first place. Here we go again, reworking on the scope. And after a few weeks when the team has already started progressing on  the requirements, they realize that the stakeholder had another idea. This sign also indicates that not only was the scoping not done properly, but there was also a lack of proper processes to manage the changes in scope though an integrated change control environment.
Unpredictable sponsor and stakeholders.
This could hit the project and the project team throughout the project life cycle. In the beginning, when the scope keeps changing every often, in between during execution and control when stakeholder would find defects as well as changes in the fundamental design and concept of the product itself; and during the end when last minute major and critical changes would creep in and shift the project completion date further to the right.

Lots of changes amounting to rework.
This is in continuation of the previous point, and it goes a step ahead when the team has no idea what will hit them next. They would have lots of unplanned work on weekends and the work would look like perennially continuing, affecting the morale of the team members and the employees of the organization as a whole.

If any of these vital signs are observed in your project, it is indicative of the scope management process that would need fixing immediately. Next, the project manager should follow the other areas of project management that got impacted as a result of the scope related problems such as time/ quality/ Resources etc.

It is important to set-up and follow the scope management processes i.e.,
1)       Collecting Requirements
2)       Defining the scope
3)       Creating and base lining the WBS – re-base lining whenever there is relevant/ agreed scope changes with clear impact on time and cost.
4)       Controlling the scope through integrated change control.
5)       Verifying that the scope delivered is in sync with what the customer initially asked for.

Tips to Conduct Successful Meetings

Meetings are normally conducted to help discuss certain problems or options and come up with a viable solution. There can be different kinds of meetings such as:
1)      Meetings with clients to sell, to discuss on strategies to provide the best service, to trouble shoot problems related to product/ service etc….
2)      Meetings with internal stakeholders within the company on project kick offs, phase reviews, knowledge transfer, and coming up with a new product, solution or approach to problem solving etc…
3)      Meetings within the team, such as team members to discuss on a problem at hand, or a review etc…
4)      Meeting with one’s own boss, boss’s boss, peers, sub-ordinates, for various purposes such as departmental reviews, status updates, appraisals etc..
5)      The reasons why a meeting can be conducted is endless.
Many professionals think that meetings are a waste of time and nothing is achieved out of it. But the fact is that it is a vicious circle created by many who think this way. There are genuine reasons to have meetings when you know that collective or subjective wisdom can help achieve the goals/solve problems and necessary actions can be taken. At least, it can help provide the right direction.
However, at the same time, I am surprised to see many executives who spend endless hours attending one meeting after another and at the end of the day achieve nothing in action. I wonder if such executives achieve any valuable results or not.
So, the idea is to have a balanced approach. I would rather advise to attend those meetings that are must and one must appropriately prioritise. In fact, there are many things that can be done by just a phone call, or just passing by the desk of another colleague and sorting out the confusions. NEVER organise meetings that is basically to solve some point of disagreement between two colleagues where rest of the participants in the meeting are just watchers. Such kind of situations can be sorted out between the colleagues internally or at best at the level of their immediate superiors in a closed door discussion.
However, in spite of all the kinds of meetings and the wisdom that surround meetings, there are some fundamental rules that can help one to achieve success in achieving the objectives for which the meeting was originally asked for.
Here, based on my experience, I have tried to simplify it and put across these fundamental points that are very useful in almost any kind of meeting. For the sake of simplicity, I have put it in three phases:
Anything that we do needs some level of basic preparation. Similarly, it is important to take out some time to prepare and plan out the meeting.
1)      AGENDA: First and foremost, ensure that you warm up with the most basic thing in place…. The agenda….
Ensure that the purpose of the meeting is clearly stated. This is the barest minimum you need to do to hold a meeting, in the first place. Ensure that the agenda has a topic, and clearly listed out points that need to be discussed or sorted out.
2)      PLAN: A plan is needed to clarify the purpose and the approach towards the meeting
Once you have a purpose and an agenda in place, plan out on whom all are necessary and useful to help achieve the desired goal of the meeting. The plan should also contain a venue. The venue should be such that it is by far possible for all to join. Ensure that seats and desks are available for all participants. Timing should also be planned as per the availability of all the participants, and this can at time, become daunting especially if it involves busy top executives. Finally, send out the meeting invite with clearly stated agenda, List of points for discussion, objective to be achieved, venue, time to the appropriate stake holders/ participants. If a participant cannot make it to the meeting, ensure that his representative can take appropriate decision or at least contribute ideas instead of just being a bystander.
1)      BASIC ETTIQUETTES: Coming on time, informing the chair person in case one cannot make it to the meeting etc..  All comes under basic etiquettes….
Imagine one going for an interview. The person would ensure that he reaches the venue before time, prepares himself well before the interview, and presents himself appropriately and so on… In fact the same rule lies when we all come for a meeting.
2)      EXECUTING: Ensure that the meeting is used for discussing the right points as in the agenda and uses everyone’s time in a productive way.
For this, it is important that all participants’ points of view are taken into consideration, everyone gets the chance to talk, and that ONLY the relevant points are discussed. Any one deviating from the objective should be respectfully asked to stick to the agenda and that any new points arising can be discussed at the end of the meeting (if time remains) or in the next subsequent meeting. Ensure that minutes of the meeting are maintained by a responsible and identified person. MOM should not be assumed to be maintained by all participants. Ensure that arguments and quarrels are kept aside and if any such incident is seen happening, are immediately mitigated. Once the duration of the meeting is coming to a close, give gentle reminders to ensure people wind up quickly.
1)      Closing the meeting: This should be done by  summing up what was achieved in the meeting, on action points and future follow up meeting date (if required)
Here, ensure that the objective achieved is measured and stated. If any agenda is left pending, check if all the participants have any additional time to pick it up, else, arrange a next round of meeting to pick up those. All actions along with their owners should be summed up to prevent any ambiguity on who is to work on what. Please don’t forget to thank everyone for their valuable time and effort at the end of the meeting.
2)      Post Meeting: Distribute the MOM and the actions, with a clear list of their owners. For this, it is a good idea to use project or organisational process assets to maintain the meeting details, actions and history in a centralised place accessible to all who attended the meeting or those who will be affected by the outcome of the meeting. Send a separate invite for the next round of follow up meeting with the updated agenda, venue, time and participants.
Hope you all derive benefit from these tips and make your meetings more successful.

Leadership Skills at all Levels for Project Success

Talking about successful projects, one aspect that comes to everyone’s mind is leadership skill needed to drive the project. When we talk of leadership skills, we normally attribute it to senior management at the programme or organisational level. What we do not realise is that leadership is actually required or rather necessary at all levels of the organisation hierarchy.
Before dealing with what leadership skills are required at all levels, let us first try to understand what leadership is and what is expected out of a leader. Though, writing about leadership and its skills will itself require a separate dedicated forum and there are a huge number of books dealing only with leadership, we shall understand the key element before we can deal with leadership at multiple levels.
Leadership is what helps the overall business objective(s) to be achieved by leading people and teams to achieve the goals by enabling them to realise themselves as part of the common goal or objective. So, from a project point of view, the ability of the leader is to guide the project team to achieve the project objectives and help balance the project constraints.
Leadership at different levels
So, there is no doubt that leadership is a trait required at all levels, so that the results are accumulated right from the floor level till the top ranks. Though, leadership is mostly discussed and referred to the top level, ironically, it is even more important at the floor level.
In general, there are some core points that leadership should address:
1)      Ensuring that the business objectives are well understood, clear and executed well enough to achieve the business goals.
2)      Communicate throughout the ranks and hierarchy to ensure that there is common direction, objectives and goals.
3)      Facilitate the team to achieve the goals by –
a.       Building the right team.
b.      Creating an environment to collaborate, communicate and work together.
c.       Motivating the team to take calculated risks by enabling a nurturing environment that allows mistakes to happen as a learning experience and improve further.
d.      Creating a positive environment of rewards and recognition where exceptional and good performance is recognised and rewarded.
These skills are generic and need to be applied at all levels. What would vary is the way and the scale to which they are applied. These are therefore even more important at small team levels which are building blocks of the whole project team and of the organisation as a whole.
Technical Team Level
Here the team lead’s role should be not only of ensuring that the project module or target is achieved, but also to create a team that is efficient and reliable. For this, the team lead should motivate the team, should keep them connected and communicate the bigger picture so they all feel part of the whole project, reward the team members and handle conflicts in an appropriate and responsible manner. He should also direct the team to follow processes, values and ethics to help the project and the organisation at a broader perspective. This fundamental approach can go a long way to not only improve productivity but also reduce attritions.
Project Manager Level
No wonder a lot has already been talked about a project manager’s leadership capabilities. As a leader, the project manager should not only process technical knowledge of handling the project, but also be well equipped functionally to manage the project well. He should apply the project management knowledge across all knowledge areas. The project manager’s personal effectiveness, attitude, personality and the ability to guide the team while balancing the project constraints all adds up to his leadership skills. It also includes how well the overall programme objectives are understood to help achieve the project objectives. This has a direct impact of letting the project team understand their role and importance in completing the project and make them feel as a part of the overall programme. The project manager should be adept at handling resource constraints within the project, in managing resource conflicts and creating a positive environment in the team.
Programme Manager Level
A programme manager should align the overall portfolio or organisational strategic direction to all related projects in a programme. To achieve this, the programme manager should ensure that all projects within a programme are achieving the overall programme objective. He/she should resolve resource constraints or conflicts at a programme level that can affect multiple projects. The programme manager should be capable of resolving issues and change management within a shared governance structure. In doing so, he/she should communicate the right message across all the project managers in his programme. He/she should also provide a clear direction to all his project managers.
The role of the PMO
The PMO or the Programme Management Office can play a vital role as a leadership team. Apart from administrative tasks such as managing resource sharing across the programme, administrating and developing project management methodologies, best practices and standards, monitoring compliance with project management standards, policies and templates, they can play a bigger role. They should facilitate in initiating leadership across the programme by being leaders as an example. They can facilitate in providing the right kind of direction, communication and team building across the programme by working more closely with all the managers. They should provide mentoring, coaching of both hard and soft skills to make better managers and leaders. They can do this by creating the right environment and training.
For this, they themselves need to be more disciplined, innovative, take initiatives, and lead by example. They can justify the PMO as a cost centre by measuring the return on investment not only monetarily but also as a creator of value addition.

10 Key Steps to Revive a Project

We all talk about successful projects and discuss mostly on pointers to make our project successful. However, what if a project is already in a difficult situation? For such projects, there are some common but yet critical steps that can be taken to help revive the project back.

Projects commonly suffer from delays in delivery or overspent budgets.
The reasons for these are many. Most common are:

1)      Tight or unrealistic schedules,

2)      Unclear scope or requirements leading to scope creep.

3)      Lack of or too many resources.

If looked into or probed further deep, the problem mostly lies with communication, improper assignment of resources, lack of leadership, incorrect priorities and so on.
For this, mature organisations are already prepared with what is called a disaster recovery plan which normally consists of the following actionable and pointers. For those who are unprepared for such eventualities need to work to ensure that these disaster recovery plans are in place.

1)      Re-look at the project life cycle and processes.

2)      Re-look at the Organisational structure and restructure the organisational hierarchy if necessary.

3)      Put communication in place and in order to communicate strong positive message within the company. Understand the sensitivities of both external and internal stakeholders. This is where a lot of risk factor would be present.

4)      Ensure that the scope and requirements are clear and concise. Re negotiate the scope and requirements with the stake holders to ensure that the project is realistic and deliverable, If required, the requirements can be broken into smaller parts to help smooth project execution in realistic time scales without having the stakeholder to wait too long.

5)      Ensure that deadlines are re-visited and if it is necessary to meet strict deadlines, re-prioritise and re-negotiate the processes and the work by bringing in the Disaster recovery management into place.

6)      Ensure quality of the product, the technical road blocks in achieving the quality and completing the product/ service on time is well managed though positive and open communication and bringing in right kind of resources.

7)      Re-structure and bring in right and competent resources at key departments/ positions to help resolve the bottlenecks. Sometimes, external vendors/ or resources outside the project can be brought in as subject matter experts to work along with the existing team to enable them to get things done appropriately.

8)      Assign specialist disaster recovery project managers who are skilled, adept and can take strong decisions with their right knowledge of organisation structure, policies, industry, political connections. They can work along with the existing project manager and facilitate the completion of the project by enabling them.

9)      Manage risks and issues on a more aggressive scale and ensure that the risks/ issues are dealt with more realistically.

10)   Bring in strong leadership with qualities to help the overall project to move in the right direction, to motivate and facilitate the teams to work in collaboration, and who can usher in the right communication and guidance and help achieve the above.
One or more or all of the above steps in combination can help revive a project from disaster and convert it to a successful one.

Why Scrum Projects Fail?... and how to solve it?

Having discussed about the importance of project management processes in Agile Scrum in my previous blog, let us now look at the reasons why Scrum projects fail and then we shall look at the approach to solve these problems to help achieve successful Agile Scrum projects.
Re-iterating some key points on Agile Scrum… We now know that Agile is primarily a methodology to help develop relatively new complex software projects where the requirements are constantly evolving/ changing or getting added. This is achieved through an incremental, iterative and collaborative approach where quality is continuously added at every single step rather than at the end, with total user involvement to ensure the product developed at every stage is potentially shippable.
The key point in the Agile Manifesto is that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” And this preemptively defines what is meant by success in an Agile Scrum framework.
So, when we talk of the following key points in the Agile Manifesto:
Individuals and Interactions over processes and tools,
Working software over comprehensive documentation,
Customer Collaboration over contract negotiation,
Respond to change over following the plan
The success of a scrum project depends on the mindset as well, apart from the project management processes and skills.
This has a lot to do with the right mindset that contributes to scrum success and the lack of it that contributes to failure. So, when we come to think of what hinders success in scrum projects, we are primarily dealing with the problem areas around 5 key points.
i.e., Reflection, Emotions, culture, Collaboration and Adaption
No single cause makes the scrum project succeed or fail, it is a combination of these factors that make or break a scrum project. So, let us briefly deal with each of them one by one.
Humans are primarily emotional…. We have an emotional baggage in everything that we do. The idea is to cultivate positive emotions to succeed. The same applies to Agile Scum projects as well. So, when Agile is mostly about mindset and how we approach to it, it is important that we first look at emotions, for this one area has a direct impact on the scrum projects especially when sprints are executed within a collocated scrum team consisting of at least a scrum master, designer, developer, tester and a product owner.
Emotional Symptoms that have a direct impact on the scrum project’s success or failure are
Discipline – The discipline needed for a waterfall model and scrum project is entirely different. E.g., adding extra resources or cost or time at the fag end of the project because of some delays in the beginning of the project is an absolute no no in a scrum project. It takes time for the team to deal with this kind of situation and inculcate a different set of discipline to deliver story points in every sprint to provide a potentially shippable product at the end of every sprint and demo it to the customer.
Apathy – This can happen within a team due to a number of reasons. The very fact that a team doesn’t have conventional designations and all are equal in a scrum team can lead to discrimination within the senior and junior team members causing apathy. Also, it can be related to knowledge issues where the team is ignorant or has not really understood the very purpose of agile.  Another cause of this could be the team’s prior comfort levels.
Culture surprisingly can have a major impact on the success or failure of Scrum projects. The symptoms here are micromanagement, finger-pointing, detailed reporting, and Scrum Master being made accountable for the Scrum Team. The root causes for these normally lie with the way the organization has been working in the past and the culture that has already been set-up prior to implementing Agile Scrum. These result in a hierarchical thinking mindset as in waterfall, the team believing in command and control mechanism and a scrum team formed of say members from different departments with varying compensation packages.  
If there is no reflection on what we are doing on a day to day basis and no learning on what we have done so far with no inclination to learn something new daily, we observe symptoms such as :
Same process being followed in Sprint n as was in Sprint 1, no hands-on customer demo after every sprint, daily stand-up being monotonous and a formality, no code-reviews, and tests not run before check-In, misleading metrics.
The root causes for these are wrong value definition right from the beginning, Missing Commitment, Non-Learning, and going back to the comfort zone.
This is again, key to Agile Scrum projects where one needs to adapt and change as one moves along in the project. While no planning is carelessness, adapting and changing the plan as one moves through every sprint is extremely crucial. The symptoms one can observe due to lack of adaption are: Sprint retrospective meetings are done without actions being implemented for the next sprint, plans not being updated due to the changes happening in the project. The Root Causes could be to do an ineffective Scrum Master, No Empowerment to the team, Invisible Product Owner or having a proxy of the proxy of the proxy product owner, too frequent changes causing team to hesitate to adapt.
The whole Agile Scrum framework works on collaboration. If there is no collaboration, it can impact the scrum team’s working and can thereby impact the Scrum project. Collaboration again is key to a Scrum project success. The Symptoms here are: Only BA talking to customer instead of the whole team interacting with the customer at the end of each sprint, there is no proper team planning, the proxy product owner starts deciding for the customer and so on. The root causes here are Segregation, Separation or differences within the scrum team inhibiting collaboration in the right spirit, Hard-coded Communication Paths, Push-System where tasks are assigned instead of a pull system where the scrum team members pick up story points daily, There is No Shared Responsibility, There are too much of Turf Wars or Politics.
Solution to these to make Agile Scrum Projects Succeed:
First and foremost, it is important for the organization to appoint a Scrum coach who has lots of experience in training and coaching the scrum teams at an organization wide spectrum. He needs to be a strong leader to help influence the organization to take the right steps towards Agile Scrum. This would help the organization bring in right changes in the culture, philosophy and goals that would align well with implementation of Agile Scrum. Having said that, the Agile coach would also help influence the HR, PMO and other functional departments to bring in the right work cultureThis could mean planning out the right career paths, reviewing compensation packages, bringing in the culture of empowered teams that can execute sprints in a collaborative environment. The change would need to happen right from the top to the lowest level. Once the foundation is laid, every team and department needs to bring in the concept of adaption and help motivate the team members to take risks and also adapt to change more openly. All this set-up would help work in a collaborative environment all set to make Agile Scrum Projects successful.