This is the first of a series of unboxing PMBOK7 articles explaining PMBOK7 which will help the readers to bridge between PMBOK6 and Agile to PMBOK7 very easily. Again I want to reiterate the fact that the foundations of project management cannot be disrupted very easily. If you know the basics of predictive project management and agile project management, then it is only a matter of establishing a traceability to the PMBOK7 structure. PMI, the publishers of PMBOK have time and again highlighting the fact that PMBOK is only a reference material and need not be mastered and remembered end to end like every other reference material. With these Unboxing PMBOK7 articles, my goal is to make the transition from PMBOK6 to PMBOK7 as smooth as possible.
Structure of PMBOK 7
From PMBOK version 6 onwards, PMI was trying to catch up with Agile Project Management (APM) which is the most suitable for managing certain types of projects, especially those ones where the scope is continuously evolving and the technology component is fast changing. PMBOK Version 7 can be seen as a natural progression of it. Like the 12 Agile Principles, which are the foundation of all agile frameworks, PMBOK7 also has 12 governing principles at the apex level followed by other components as shown in the diagram below.
Click on the diagram to zoom
12 Governing Principles
At the apex level are the 12 governing principles. These 12 principles based on the project management professions ethics governs the actions and behaviors of project management practice regardless of whether one is following predictive or adaptive project management styles.
Stewardship – Be a diligent, respectful, and caring steward
Team – Build a culture of accountability and respect
Stakeholders – Engage stakeholders to understand their interests and needs.
Value – Focus on value.
Holistic Thinking – Recognize and respond to systems’ interactions.
Leadership – Motivate, influence, coach, and learn.
Tailoring – Tailor the delivery approach based on context.
Quality – Build quality into processes and results.
Complexity – Address complexity using knowledge, experience, and learning.
Opportunities & Threats – Address opportunities and threats.
Adaptability & Resilience – Be adaptable and resilient.
Change Management – Enable change to achieve the envisioned future state.
Project performance domains
The second level comprises of the project performance domains;
Team
Stakeholders
Life cycle
Planning
Navigating uncertainty and ambiguity
Delivery
Performance
Project work
Models, methods & artifacts for enabling outcomes
This section at the third level more or less looks like the Inputs, Tools & Techniques and Outputs re-grouped as models, methods and artifacts. For each project outcome we have a set of models, methods and artifacts which help to achieve the project outcome.
At the fourth level is the PMIstandards+ digital platform which will guide on the application of Models, methods and artifacts based on project type, development approach and industry sector.
Courtesy – Project Management Institute (PMI), USA
New 10 Week PMdistilled PMP Plan / Program based on PMBOK7
Projects are neither completely predictive nor agile any more. They are hybrid in nature. That is the reality. So far, project management had two distinct streams, the Adaptive (Agile) and the Predictive (traditional). The purists believed in any one of the streams. They are busy justifying their views. Now, the industry has changed. Irrespective of the type of work, majority are working from home and that demands adoption of both agile and predictive best practices in the day to day work. That trend is here to stay. The Project Management Institute (PMI) was the front runner in this by including Agile in the Project Management Body of Knowledge four years back. This was followed by the new Scrum Guide 2021, which has become more generic. Scrum is the most popular among the Agile frameworks because of it’s adaptability to various disciplines of project management. According to Ken Schwaber and Jeff Sutherland, the founders of Scrum, they made the Scrum Guide 2021 more generic so that it becomes easier for all types of projects to adopt it. The trend is very clear. The boundaries between agile and predictive is vanishing, if not yet vanished.
Unfortunately, when I visited the Agile Manifesto Page, it still reads as ‘Agile manifesto for developing software’. From an EPC project practitioner’s perspective this is very demotivating. The engineering phases of any EPC project is a good candidate for agile adoption, but still the agile manifesto is maintained exclusively for software development. Like every other EPC person wanting to leverage agile I feel stranded and unsupported.
These two factors leads to the need for the Hybrid Project Management Manifesto;
The Hybrid Project Management Manifesto
As practitioners of Professional Project Management, We believe that;All projects are unique in nature,
Tailoring the processes, by incorporating the best from every project management framework is better for project success, than relying on any single framework.
For this;We will continuously update our knowledge and skills without any bias to any one particular project management framework,
We will always maintain an independent open view in all our actionsto ensure project success.
I am very optimistic about this, because there are many who opposes this view as well as those support this view. It is high time we stopped saying ‘Agile Vs Waterfall’, instead we must learn to say ‘Agile and Waterfall’ and for that the apt word is 'Hybrid'. Thanks to the traditionalists who contributed us with great tools like the critical path analysis, earned value management and the likes. These are time tested concepts which is here to stay. The agile practices like time boxing, the short term planning, daily team meetings, self organizing teams can be effectively used within phases of every project. That will result in a healthy co-existence. Think of burn down charts co-existing with earned value management and helping to protect the earned value. Nothing is good or bad, the project context determines it’s suitability.
Hope Hybrid manifesto will help us to focus on the project’s success than worrying about the technicalities of frameworks.
The Hybrid manifesto is evolving. You can help with your suggestions.
Schedule and Cost forecasting explained in detail.
Are we progressing as planned?
Are we completing the work within budget?
When will we complete the project?
These are the key questions we hear most of the time in project review meetings. Well implemented earned value management systems, provide answers to these questions at the press of a button.
Earned Value Management (EVM) is based on the analysis of the earned value of the project and comparing it with the planned value of the project. Earned value management is used to monitor and control both the schedule and cost. Earned value management (EVM) comprises of;
Earned Value Analysis
Variance Analysis
Trend Analysis
Reserve Analysis
Corrective / Preventive actions
1. Earned Value Analysis :
The basic building blocks of earned value management are;
As on date, how much work we were supposed to complete? – Planned Value (PV) – Also known as Budgeted Cost of Work Scheduled (BCWS)
Out of that how much work did we complete? – Earned Value (EV) – Also known as Budgeted Cost of Work Performed (BCWP)
For the completed work how much did we spend? – Actual Cost (AC) – Actual Cost of Work Performed (ACWP)
2. Variance Analysis
Once we have the basic values of Planned Value (PV), which is also known as Budgeted Cost Of Work Scheduled (BCWS), Earned Value (EV), which is also known as the Budgeted Cost Of Work Performed (BCWP) and the Actual Cost (AC), which is also known as the Actual Cost Of Work Performed (ACWP), it is time to do the performance analysis.
Schedule Variance (SV) = EV – PV
Cost Variance (CV) = EV – AC
Schedule Performance Index (SPI) = EV/PV
Cost Performance Index (CPI) = EV/AC
As we can see in the diagram above, as on the review date, the Earned Value (EV) is lower than the Planned Value (PV). That means, the work has not progressed as planned. The actual cost (AC) is higher than the Earned Value (EV) and even the Planned Value (PV). That means, there is a big cost overrun. In an ideal situation, all the three lines should have intersected at the Planned Value (PV). In that scenario EV = PV = AC
Schedule Variance (SV) = EV – PV = 0
Cost Variance (CV) = EV – AC = 0
Schedule Performance Index (SPI) = EV / PV = 1
Cost Performance Index (CPI) = EV / AC = 1
If the SPI=1, then we can infer that the project is progressing as per the agreed upon schedule.
If the SPI >1, then the project is progressing at a rate which is more than planned.
If the SPI <1, then the project is lagging behind schedule wise.
Similarly. If the Cost Performance Index (CPI)=1, then we can infer that the work is getting completed as per the budget.
If the CPI <1, then the that indicates budget overrun.
If the CPI>1, then more work is getting accomplished than planned, with the same amount of money.
As a general rule of thumb, if the SPI and CPI is 1 or above 1, then the project is doing well schedule wise and cost wise.
As project managers, if we know the schedule variance (SV), Cost Variance (CV), almost real time, then we can monitor and control our projects effectively.
3. Trend Analysis
The variance analysis provides us with the current snapshot of the project. One can become more pro-active in managing and controlling the project, if the future trends of the project performance can be predicted with the present progress information. We use graphs and charts to do this.
At this stage, let me introduce these three additional terminologies;
1) Budget At Completion (BAC) – is the total approved budget of the project from the beginning of the project till the end of the project.
2) Estimate to Complete (ETC) – is the budget required to complete the balance work of the project. ETC = (BAC – EV).
In some cases, ETC is calculated as a bottom up re-estimate for the balance activities to be completed.
3) Estimate at Completion (EAC)
If all the future work can be expected to be completed as planned, then how much will it cost when we complete the project. EAC = AC + ETC = AC + (BAC-EV).
If the current trend is going to continue in the future as well, then EAC = AC+(BAC-EV) / CPI.
In some projects, where the schedule has an impact on the cost, for example, a delay in schedule incurs additional cost, then EAC = AC + (BAC-EV) / (CPI x SPI). In this case, CPI and SPI are given weightages like (80/20, 50/50 or some other based on the judgment of the project team).
4. Reserve analysis
While performing the cost control of the project, the reserve analysis of the contingency and management reserves monitored. This will help in utilising these reserves elsewhere is the project progress is satisfactory or in organizing additional reserves proactively.
5. Corrective and Preventive actions based on the to Complete Performance Index (TCPI)
What should be the target CPI, to be maintained for the balance work, in order to complete the project within budget.
TCPI = Work remaining / Funds remaining
(BAC-EV) / (BAC–AC) or it can be,
(BAC-EV) / (EAC-AC) if the EAC is approved by the management.
Earned Value Management brings in more visibility into the project, and helps us to be more pro-active.
So far our focus was on forecasting the Estimate At Completion (EAC). What about forecasting the Estimated Date Of Completion of the project?. The following seven minutes video explains schedule forecasting;
In today’s fast changing world we cannot escape from the fact that business requirements change very often. If we use the predictive, heavy weight methodologies for developing software it is very difficult to incorporate the changing business needs of our customers. Lightweight software development methodologies, which appeared in the late nineties “embrace changes”. The disciplined adaptive nature of these methodologies helps us to easily accommodate changing business needs of our customers, even in later part of the development cycle.
Many software development organizations are using agile development methodologies like Scrum as it helps the organizations to respond to changing business environments very quickly and provide better customer satisfaction. In today’s business environment it is not really the big that win the battles rather it’s the fast that win the battles over the slow. Time to market is very important in today’s fast changing world. Agile development helps us to deliver the value to the customer rapidly through a divide and conquer approach and prioritization. The right 20% of effort will yield 80% of the value, so we do a lot of those in agile development and extreme testing.
Introduction to Agile
In Scrum the whole development is divided into different increments/sprints. Top priority user stories are covered in the initial sprints. Unit tests are developed first as a best practice. Then the code is written to ensure that 100% of unit tests pass. This is done in an incremental way. The developers write unit tests and 100% of Unit tests are automated. This will help in executing the tests repeatedly and also simplify the reporting of results.
There is one more important type of testing involved in agile testing, which is called Acceptance Test/Customer Test. These tests are written, based on User stories. They are formal tests conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. Test engineers write the Acceptance tests with the help of customers in some organizations. It is very important to understand the customer perspectives while writing the acceptance tests. The big mountain acceptance tests are automated using an appropriate tool and executed on all the builds. Agile testing creates confidence that code is complete and it works; catches integration defects when they are first created, and, most importantly, provides confidence that a maintenance change did not introduce a regression error.
Basic values like open communication, tight feedback loop in the scrum teams, simplicity and courage are the key in scrum teams. In scrum, testing isn’t a final hurdle it is a journey along the full development cycle.
Areas to Focus
While building a distributed agile team we need to consider multiple factors. If we don’t build the right team for Agile it is going to be very tough to get the results. Open Communication is one of the key values in agile development.
Individuals and Interactions
If your existing team is to be transformed into an Agile team the most important step is to evangelize the agile concepts and benefits in your team. Management and Development teams also need to be educated on the ROI(Return On Investment). When we were implementing Agile in our organization we used to conduct talks by practitioners on agile, play agile dramas depicting the outcome from monumental methodologies and light methodologies. Once the platform is set we can start implementing agile practices and values. We need to identify and prioritize which are the areas to focus on first for the team. We may need to refactor the team. If there are team members in your team with a negative attitude or having an attitude to resist changes, then proper guidance needs to be given to them to bring in the change. If there are no improvements, it is a good idea to move them to a different project. Agile talks about “tossing off” the code at the end of the day if it doesn’t serve the purpose. This is applicable for team members also. Don’t try to patch it up too much…
While recruiting new members to an agile team we need to ensure that they have the right set of attitudes and skills in line with the agile way of working. Openness, ready to give and accept feedback, simplicity, courage, adaptability, good in communication, right skill mix …these are some of the attributes we need to ensure in a new hire. If you are planning to hire it is a good idea to have a brief discussion about agile practices you follow in your organization during the interview. Once they are hired we need to evangelize agile among them. In some cities we may not get engineers who worked in agile earlier. Transforming an engineer who has been working in monumental methodologies to an agile environment is not that easy. It’s a big paradigm shift. There may be resistance to change. We need to plan our inductions in such a way that the returns of Agile are communicated to the new hires appropriately. Once they understand the synergy it gives to customers and the organization employees will start believing in this new model. Once this milestone is covered it is easy to evangelize the other agile practices we follow in our organization.
Like the “pair programming” concept in Agile mentoring also can be done through pairing. A new hire is paired with a senior engineer who is in the team for more than 1 year. A high level introduction about the product is given to the new hire. After that during the sprint the new hire pair up with other team members according to the plan laid out by the Coach. The mentoring plans always focus on big mountain functionalities first.
When a groupWhen group of people works together in internationally distributed locations, there is great need to communicate with each other, share data and share expensive resources. Building a good communication mechanism is very important for the success of agile testing. Conversation with developer, customer, and feature team leads and product manager is frequent. Daily Stand up meetings with the scrum teams helps to build the relationships among the teams. All the Agile team members including developers, test engineers, documentation experts, product managers and DevOps assemble in the morning (usually on a planned fixed time like 10am) for a short stand up meeting of 5 to 10 minutes duration. Plan for the day and top priority unresolved issues from the previous days work is communicated to the team. This meeting is not for resolving the issues or detailed discussion. Resolutions are taken later after the meeting. If we are working in a distributed model where the development is happening in the US and the testing is in India or some part of the feature team is in a remote location like India and China, Communication and the feedback loop get badly affected. Tailored agile for these kinds of offshore development can be called as “Distributed Agile”. Collaboration among testers, programmers, and other stakeholders is more highly valued on agile projects than details of process, practices, or tools. Test engineers are part of scrum teams. Agile methods ask teams to continually evaluate how to improve group interaction, for the benefit of the project.
Once we have decided the members of the scrum team, building the team is the first priority. We need to plan for internal and external team building activities initially. We can also do a lot of informal interactions and get together … like all feature team members having evening snacks together in the snacks parlor.
Video calls, Chat, email , lightweight documentations , phone calls etc.. can be used for constant communications. We can plan for weekly meetings with members of the scrum team who are in the remote location. It is a good idea to have all the scrum team members participate in this meeting. Frequent conversations between the remotely located team members is a good practice. This will help us to build relationships. We need to agree on the overlap timings when the video calls can happen as most of the time one of the engineers will be at home because of the time zone differences. Engineers traveling in both directions frequently (2-3 travels per quarter) and working with the remote team for 3-4 weeks will enhance the relationships. This will help us for better culture sync. These ambassadors ensure there is enough osmosis within the distributed feature team.
Working Software over Comprehensive Documentation
Jim McCarthy said that, “The regular build is the single most reliable indicator that a team is functional and a product is being developed.” This is very much true in the case of a distributed agile team. We need to ensure that we have good CI/CD practices in our organization where the latest builds are easily available for the test teams. This will help the test teams to run their test on the latest code. We need to automate the big mountain acceptance tests using appropriate tools. This will help us to test often and communicate the progress to the feature teams.
Frequent demos of the current status of the features to the entire feature team is very important. It is a good idea to have such demos weekly once. Demos can be arranged for remote teams on Fridays and we can have a group test after that where the entire feature team tests the latest build with a focus on new features. These demos can be recorded and uploaded to a common repository. Later if some of the team members want to go through the demo they can always replay it from the common repository. During the initial milestones where the top priority features are developed we can use build mechanisms like “sandbox” where the developers check in their new code as and when the unit test passes into a sandbox build maintained by the feature team. Test engineers can always use this build for testing the new features. As we are going to give feedback on working software rather than on design documents or requirement documents the feedback inputs will have more value. Development engineers can incorporate the feedback back into the sandbox the next day. At the end of the week all the new code checked in by the feature team in the sand box (which is tested and feedback incorporated) can be checked into the main line code. If we are working in distributed agile we may need to document some of the important changes. We can use wiki or google doc etc… for maintaining these kinds of knowledge bits.
Summary
To build an effective testing team for Distributed agile we need to focus on individuals and interactions over processes and tools. We need to ensure that the latest code is available for testing in all the internationally distributed locations. Feedback based on working software helps to build confidence in the feature teams.
Read this article if you know me, and are intrigued about what happened to the venture, or if you are in an entrepreneur-in-the-making, as you can perhaps avoid these pitfalls, or if you are an intrapreneur, as the thoughts may easily resonate with you as well. Yes, that’s right, I am talking about the startup that I co-founded! The ultra-innovative, ahead-of-the-times startup that wow-ed world-renowned brands, engaged with hundreds of businesses creating over 20,000 campaigns, grew organically with a distributed model, and came close to two acquisitions/mergers – had to close shop this summer. It is easy to externalize this ‘failure’ to the business environment in the world, but that would be an excuse. Granted that we may have survived on an upswing, but learning from the reality seemed more valuable, and I am hoping will agree.
We started out with the mind in the right space. And the following thought comes to mind!
“You cannot cross the sea merely by standing and staring at the water” Rabindranath Tagore
Well, we didn’t stand by. If I were to liken the journey to sailboats at sea, I sailed into the ocean without the ‘fear of failure’, instead, with great confidence having overseen dramatic success in innovation, albeit at a corporate.
I can say now the journeys are not that different, nevertheless, I had endured the real-life training, understood newer variables, and did not make the rookie mistakes, such as burning-out-cash-fast, expand-too-fast, go-after-investors-rather-than-customers, go-after-the-money and others.
Then, what went wrong?
On the outside, all businesses essentially fail because they run out of cash, of course. The reasons are always more intricate, and here is my world view of it.
1) Value creation cannot be an excuse for not making money!
Put simply – we didn’t make money because we didn’t focus on that. We believed in going after the big fruit – long-term value creation over short-term money generation. When a board member of a 1500CR company asked us “You beat big majors in evaluation, but how do I know you will exist next year?”, we addressed his concern with “Pay us next year!”. That’s how much we had invested in the long-term, but in hindsight, we should have known when to sail and when to stop/reap the benefits – very much like the stock market!
Learning: Starting out is an emotion, but once out there, apply the ‘Rule of 40’ consistently.
Rule of 40 in simple words is Profit Margin % + Revenue Growth % > 40%.
2) Expert Opinion cannot define Your heart’s heading
Ken Blanchard said “Feedback is the breakfast of champions” and I have always asserted my own growth in corporate was attributed to it. Take that too far, and while you are at sea, and a potential investor query such as “Hey, you have great tech, but I can make this work instantly in logistics, are you interested?” tingles your vulnerability immediately. Don’t get me wrong, that’s not bad advice, but if that’s not what you wanted to do, you build things that don’t help your cause.
Learning: Don’t ask your advisors which puzzle to solve (heart’s heading), but treat their experience as a valuable piece of the puzzle you are solving!
To emphasize, surround yourself with advisors and who have sailed before, but know how to leverage experience and advice!
3) Features cannot substitute for NOT diversifying your market
Market surveys certify a product-market fit, but that’s not where you stop evaluating. When a prospective buyer sees an AI-demo predicting consumer intent at a physical shop accurately and he says – “Wow, that’s cool, can you also give me that POS (point of sale) data?”, he classified your AI as Desirable and POS as Mandatory. You have a choice – build the POS extractor to bag a brand name or find customers/markets who would buy the AI. What would you do?
Learning: Rigorously find the ROI on every feature, it’s easy to be enamored by a renowned brand logo on your portfolio.
Understand ‘Feature ROI’, ‘Customer Lifetime Value (CLV)’, and ‘Cost to Service’ a deal. When at sea, it is easy to make short-term decisions, but survival depends on well-judged long-term decisions.
4) Building an infrastructure business yourself, is at best, fragile!
Market places are heavily funded in India, infrastructure businesses not so much. So, you decide to sail anyway, not willing to trust potential investors who are just getting their feet wet or not knowing how to get the attention of the well-traveled! However, sailing out into a deeper ocean without support was just pure adventurism and when the storm (the year 2020) came, the fragility was exposed. Well, you can’t blame the storm when you went there knowing the risks!
Learning: Align your dream with the reality of the environment around you. Relocate, if you need to, as dreams are not realized sitting around.
Relocating is not always a good thing, but its worth a conscious consideration.
5) Building a business requires inner motivation
Sailing out into the unknown requires a different mindset, a passion. There is no dearth of external motivation when you set sail. Once in the open ocean, its lonely, you see another boat once in a while and to go on endlessly requires deep inner motivation, passion, and most importantly, alignment to a purpose. This is the only perennial battery source in this long journey, so next time I won’t ignore the dissonance I felt when we changed direction in pursuit of being financially successful. Watch out for that!
Learning: Inner motivation comes from being aligned to a purpose and not the pursuit of money.
This is not new learning, but worth an emphasis – pursue innovation because of a greater emotional purpose that is dear to you, as there are better ways to earn money with greater determinism, if that is the goal.
Fear can drive success and failure
Well, that’s that! Perhaps the top 5 learnings from this sailing. I think you will agree with me that innovation inherently deals with ‘unknown’ factors and its only but natural to have fears when you set sail. It follows that understanding, embracing, and dealing with them leads to dramatically better results and even powers success.
Let me make an assertion and we can debate it. I feel that innovators face ‘fear of failure’, ‘fear of change’, and ‘fear of success’ each coming at different stages of success before you reach the finish line. Of course, this varies by personality type, intensity, quantum, and person to person. Fear is known to cause distortions to decisions, but it’s not often you want to analyze that, as its more tangible to discuss an actionable ‘external’ event.
I wanted to try and get deeper and analyze, to put myself out there, so we have a real situation to discuss. I invite your perspectives. In my case, if you look closely – not diversifying markets, stayed self-funded in a price-sensitive market, susceptible to directional advice – all point to one emotion:
“Fear of change”
Things were working reasonably well, why not just build the POS extractor and get that super brand? Well, you reached this stage of success with a lot of hardship, it is fragile, there is a worry that changing dramatic can break it, but that’s the whole illusion!
Conclusion
I was lucky to reach the flag in my first outing and blind-sided at sea the second time. I wish I had disassociated and seen it this way earlier. Perhaps I am simplifying the decision making more than I should, but I would like to leave you with the thought that, each one of us can greatly enhance outcomes by understanding, embracing, and dealing with fears that influence them. Do you agree?
Your perspective is most valued. I’d be happy to hear your feedback, advice, or criticism. Thank you for your time, reading, and your support.
Author : Krishna Mitter
Post Graduate from IISc, Leadership at Harvard, 24 years of industry experience, grew and led ~200 sized engineering teams, built high volume AWS Cloud based SaaS enterprise AdTech offering and currently working on a intelligent service automation platform.
Agile Transformation is the evolution process an organization undergoes in order to deliver better, faster solutions while adapting to the constant change of an increasingly complex and uncertain business environment. Most organizations recognize the benefits of agile but aren’t sure how to create or encourage Agile “behavior” or when to introduce frameworks and practices. It involves a mind-set change in all people in an organization which can be uncomfortable for most. Commonly the emphasis in an Agile Transformation is on the “Agile” part and there is little focus on the “transformation”. When the companies focus on the details of “Agile” they often struggle or fail. The emphasis should be on “transformation”. Agile is important, but it is not the make or break focus of an Agile Transformation.
The following are transformation issues, no matter what kind of Agile Transformation you have in mind (Scrum, Kanban, Lean, XP or other team level practices OR SAFe, LeSS, DAD or other scaling practices):
Company philosophy or culture at odds with core Agile values: Cultural change is critical to any ongoing successful Agile adoption by small and larger businesses because people feel comfortable using traditional ways and resist any change. Moreover, it is critical that Agile must co-exist with traditional development approaches. The agile adoption can change the nature of some roles; particularly those of line management and traditional project management, people who are used to making decisions and directing work, whereas agile requires a more democratic process, with all team members participating. It’s very important that people in such positions are allowed to influence the nature of their new roles and understand the value they can continue providing. Without such transparent communication, they can become blockers to the adoption of agile but when properly involved, they can be positive agents of change. Recommendation: Should start small, experiment with pilots and prototypes. Ensure key stakeholders are involved early in the process and have a common understanding of Agile concepts and benefits. Plan a concise, contextualized strategy for Agile transformation, a foundation roadmap, its desired outcomes, how to measure and communicate the progress and success to the team. When others in the Organization realize the success, will also start supporting and contributing in Agile adoption.
Lack of management support: It’s usually ‘middle management’ who has lack of trust for a new process, lack of understanding of changing roles and a lack of buy-in to the new process. Successful Agile implementations need support from the team members, management, and executives to embrace new ways of completing work and collaborating. In most enterprise wide agile implementation efforts, it is common for teams and executive to have great enthusiasm for the effort. However, in the absence of a strong Agile transformation plan, project and program managers or functional ‘resource’ managers often feel isolated mainly because their roles are no longer clear. This results in a general resistance and creates additional barriers to further Agile adoption and success. Recommendation: Executive leaders should model the behavior they want their management team to display. Lead by being an example and live the values they want them to adopt, and help middle managers understand how they fit into the changing organization. Embrace not only from top down but bottom up that a “mind shift” needs to happen to embrace the new levels or collaboration, communication and transparency.
Resistance to change: Another barrier is resistance from people who feel they don’t need to change and unwilling to follow Agile. A lot of the “management” functions start to move, change or go away as an organization becomes Agile. One of the changes is that “Line management” becomes less important and “hands-on” as people and teams become empowered; Technical managers become less important as teams become more self-directed and define their own technology spaces; Service managers become less involved as people move from silo IT to DevOps and Project managers become less powerful as the firm moves from a project to a product mindset. Recommendation: Not having alignment on the aspiration and value of an agile transformation could be barrier. Employees also need incentive to make a change and how will it benefit them. No matter what your role most people need to know “what is in this for me?” it is human nature when dealing with change. Everyone must see the value in the change before it can happen. Incentive is the piece that can either build consensus or build resistance among staff. Incentives can be tangible such as monetary, or intangible such as personal achievement or prestige.
External pressure to follow Legacy systems and processes: This is especially common in large enterprises, where some teams follow Agile approaches and other parts of the organization operates within traditional waterfall approaches, sometimes working under the umbrella of the same portfolio or program. In such cases, the Agile teams are usually being grafted into the existing traditional portfolio and project management methodology, and with teams that are working against different schedules, trying to deliver on a specific project. This can be a barrier in successful Agile adoption. Recommendation: Should aim to get business units aligned through training to ensure that managers of different areas understand the implications of interacting with teams that do work in the new way. The ultimate goal should be to break dependencies across the entire organization. Change your metrics, identify new metrics that move away from measuring and tracking lines of codes, quality issues and reports as success factors and deliverables. Focus on “working product” and value delivery and this should be greatest measure of success in an Agile environment. And to achieve this, facilitate continuous collaboration between the business and the development team. Having the traditional teams understand even though they cannot change their architecture on a dime there are things that they can do to move them in the right direction, have them start small and work their way over to a full agile adoption.
Insufficient training: One of the necessary elements is to know what skills are needed and do existing staff members have expertise or training in what they are being asked to do. The lack of skill, appropriate resources and training may lead to anxiety. Recommendation: Should know what in-house resources are readily available and if they are suitable. What resources are needed and how will you get them. Conduct trainings for all stakeholders and the core teams. Coach teams through real delivery to refine understanding. Not only is the initial training essential but on-going training to keep the skills within a team and to assist the team in evolving to a high performing group of people.
Inadequate experience with Agile approaches: For most new Agile teams, members are typically inexperienced in applying basic Agile practices and unfamiliar with successful agile transformations. In such cases, there is a high likelihood for misinterpretation of Agile principles and fallback to old practices. An Agile process will expose problems and issues with the project more quickly than a more traditional development process; addressing such and what to do about those problems and issues is also not always very clear to new and inexperienced Agile teams. Challenges can make the difference for the team’s success or failure with Agile. Recommendation: Understand that inexperienced teams need more formal process and guidance. Include an experienced Agile resource to coach on the team that has strong experience practicing Agile methods, and successful experience with Agile teams. Keep team members stable on a team, if possible, move towards a “Fund the team” model versus “fund the project” where you are constantly ramping up new teams. This will help teams mature and develop a cadence and well-defined velocities that provide better predictability to product owners and stakeholders. Invest in making training and continued coaching guidance available for the teams to consult. Encourage a learning organization by launching a community of practice.
Lack of vision and Agile priority: There must be a vision and reason why the change is needed. Creating an “agile friendly” culture requires a firm vision, senior business and IT executive support, strong governance and a clear roadmap. Mostly, companies find themselves limiting agile to pilots within a small part of the organization, with a small set of leaders. While the pilot is typically successful, its impact is restricted to a few teams and not treating agile as a strategic priority that goes beyond pilots eventually gets killed. Recommendation: Transparency is vital to the effective teamwork that underpins agile development. The vision and action plan for change should be clear, developed by a representation of all stakeholders and should be communicated to the team. The lack of vision and open communication leads to confusion. A great practice is to not only review the vision with the team in the beginning but go back to review it as work progresses ensure the changes that naturally occur are accounted for and the team(s) still understand the direction and priority needs to help deliver the greatest value.
By Harleen Flora; PhD (Computer Science), PMP, MSP, PRINCE2, ITILv3, CSM, Agile PM, SAFe5 Agilist, Lean Six Sigma Black Belthttps://www.linkedin.com/in/harleenflora/
World over the way people work have changed. Organizations are forced to re-think their business strategies to survive first and then to grow in a new world order characterized by;
Organizations sparing no opportunity to maintain / improve bottom lines
Organizations trying to go-global looking for new markets for existing products and services
Organizations rapidly innovating new products and services for their current markets and beyond
In a nutshell, everything in the corporate environment have become dynamically agile, where business owners are trying their best to maximize return on their investments. As a timely coincidence, leading organizations like the Project Management Institute (PMI) started their initiatives long back to converge the Predictive and Agile Project Management best practices, as if they could foresee the forthcoming new world order well in advance. All these have major impact on how we collaborate and work on projects. The concept of permanent employment have already become a matter of the past, as organizations are actively seeking flexibility in resourcing to optimize costs.
People with proven skill sets and the ability to learn fast with good work ethics will be sought after. Professionals with the ability to deliver value at the right time, with almost zero supervision, working remotely will be in demand globally. The geographical constraints of employment will become almost zero for the right people who can proactively identify the new opportunities and gear up. In this new world order, our professional profiles matters a lot to market ourselves. You are a brand, and that brand has to be continuously nourished to be in demand. This is the right time to equip yourself with new in demand skills supported by globally acknowledged credentials. Project Management 2021, is all about highly skilled, motivated individuals, working on their projects of choice as self organizing teams, demonstrating high degree of work ethics.
