Priya PatraDelivery Director| Capgemini India Technology Services LtdMumbai, India
This is in continuation with the PMI Xchange discussion at the PMI Global Congress 2015, I had with a group of very bright attendees.. Organization Agility
In this discussion we talked about internal and external factors that can affect organizational Agility. Internal factors were governance, HR process, quality and delivery processes.
Any thought son the external factors that can affect organizational agility and what actions that we as project and program managers needs to take to ensure that the organization is truely Agile Saving Changes...
Priya PatraDelivery Director| Capgemini India Technology Services LtdMumbai, India
Hey Mike ! I read the NASA story just now..thanks for directing us towards the same. It is awesome. I agree story telling is an effective way of knowledge sharing and communication.
Effective communication and knowledge sharing and learning from failures, makes an organization ready for change. Saving Changes...
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
Organizational agility is much more than HR or our systems or our practices. To achieve organizational agility, you first need to achieve the other agility types - strategic, value, delivery, business, cultural, client, and leadership. Client agility is where you factor in the external world so you adapt to you clients changing needs. Business agility focuses on the operational space so you achieve efficiency and effectiveness in daily operations as you deliver value to your clients. Strategic agility focuses on being cognizant of emergent realities when operating at the edge of chaos (many more organizations operate here than is realized) in order to achieve your strategic goals. Value agility is where you sort out how to achieve your strategic goals/objectives and they help you decide your portfolio of initiatives to do that. Delivery agility focuses on our practices. Cultural agility recognizes the diversity of the modern workplace (multi-generational, ethnic and language factors, etc.). Leadership agility recognizes that the role of a leader is to create other leaders - not to create followers. Get all that going and you''ll achieve organizational agility. There are some who get it like W.L. Gore and Zappos.
Each of the above agility types both support and inform the other types – it is a process of constant inspection and adaptation based on what emerges over time as we move to achieve our strategic goals. In Agile we talk about emergent architecture and emergent design. I also talk of emergent problem understanding - we often don’t know what we don’t know until we see it. Each type of agility also incorporates many different and sometimes overlapping practices. Scrum is one of many agile practices/techniques - there are tens more that can be used and there are more agile practices and techniques emerging every day.
The above agility types are the focus our agile for executives course and of “The Agility Series” of e-books I am working on. Saving Changes...
Priya PatraDelivery Director| Capgemini India Technology Services LtdMumbai, India
@Lawrence This gives us a holistic view on Organizational Agility. Agreed Organizational Agility goes beyond HR , systems and practices.
I work for a services organizations, so for us Client / Customer Agility is an important external factor. Many a times we face challenges when our customer is not at the same level of agility as ours ( sometimes more, sometimes less) . Also there are challenges when we need to interact or work in a multiple vendor scenarios. Balancing Agility with client/ third party vendors / client vendors opens up a different dimension of Agility altogether. Any thoughts on such a scenario ? Saving Changes...
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
This is where leadership and strategic agility can really help. Strategic agility in particular is helping us to constantly inspect how we are doing in achieving our strategic goals/objectives or priorities (lets call them goals) and then being willing to adapt to the reality we encounter as we execute our strategy.
Encountering a client that is at a higher or lower level of agility than you are at in your organization means you need to adjust your strategy both in how you engage and in how interact with the client as you progress with them. In our book (Agile Value Delivery: Beyond the Numbers) we referred to this level of inspect and adapt as recognizing emergence in problem solving in a chapter on emergence which also talked about emergent architectures and design. I would now extend that concept of emergence to also include emergent strategic choices around our strategic goals as well as to the other areas of agility.
Leadership agility is what emboldens those who execute to strategic goals to have both the confidence and the support they need to inspect the reality they find in execution and to make additional strategic choices in the moment that are more suitable to the circumstances. This is premised on the idea that the real role of a leader is to create other leaders – a great book on that concept was written by David Marquet called “Turn the Ship Around”.
When we view leadership that way we are pushing decision-making down to the lowest possible levels to those who are best equipped to do so as they are the most informed in the realities of a particular set of circumstances.
Strategic goals are just that – goals. They can become like the big-up-front-plan (BUFP) that the Agile Manifesto`s principles cautions us against if we don’t recognize the issues uncovered through emergence. Reality may dictate that we need to adjust. Our people need to know that they can without seeking permission.
Client agility is recognizing the situation you describe. When that happens these other two agility types need to become paramount in your thought processes.
Once that happens, this will then lead to new choices or lead us to make adjustments in the choices we made previously for Value agility and Delivery agility. It therefore becomes a continuous cycle of inspect and adapt across all facets of organizational agility. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
@Priya: we need to keep this simple and we need to keep it concise. We need to understand that we need to separate the understanding of agile and agility concept from the methods we will use to create agility and implementing agile. For example, to create products, what type of life cycle will we use? Predictive or Adaptative? I think most of the people will answer "adaptative" I´m sorry but I can demostrate (with my personal experience included) that you can be agile using predictive methods like "waterfall". So, the worst thing you can do when you try to implement this type of things is to assume that the use of one method or tool will give you the agility "per.se". About to interact with the environment (client, customer, vendor, etc) you have not to expect that they are in the same grade of maturity (no matter agile or other type of thing you will use) than you. Remember: agility means react to the environment changes or create environment changes. So, it is up to you. Saving Changes...
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
Saying that you can be agile using predictive methods like "waterfall" is an oxymoron...as you are doing neither according to their actual definitions.
Predictive methods fix the scope in order create the big up-front plan (the prediction) which then puts the PM in the unenviable position of having to defend the scope from change by the business. The whole premise to predictive is that the ‘plan is the plan’.
The reality though is that a plan''s predicted dates and costs under such an approach are rarely if ever met unless something is dropped from the original scope. The fact they the business does not get to see anything until the very end of the project puts them at a very large disadvantage. All too often what is dropped (also usually near the very end of the project) is typically something that the business had valued highly.
Agile allows you to fix time and cost and constantly negotiate scope at the start of every sprint/iteration based on highest business priority and to then deliver potentially shippable product at the end of every sprint that the business gets to inspect and make decisions (adapt) around as to what they should do next. Should time or money become factors later on, the business will have confidence that what they valued most was actually delivered. By their very definition you lose that important aspect through predictive planning approaches like waterfall.
By the way, the seminal paper that supposedly started the whole waterfall thing (due to later a misunderstanding by the authors of DOD STD-2167 of Royce’s intent) was actually promoting incremental development and said don’t do waterfall.
After showing what was later called the “waterfall model”, Royce simply stated after Figure 2 on page 2 that “the implementation describe above is risky and prone to failure”.
Agile thinking as opposed to Agile (the Manifesto) goes way back beyond Royce – all the way back to Walter Shewhart in the 1930’s and W. Edwards Deming who used Shewart’s work to come up with the Plan-Do-Check-Act cycle which he took to Japan which even later became the premise for the Toyota Production System (TPS) and Lean. Agile is in essence an extension of these same ideas into the software space.
It has long been recognized that predictive planning practices such as waterfall are fraught with peril and to be avoided. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
To afim that using agile with predictive methods is an "oxymoron" deomstrate a lack of understanding about agile or agility is. And the right name for "manifesto" is "Manifesto for Agile Software Developemt" and people who wrote have used the word "software" for a reason. Agile and Agility concepts start on USA/Dod NAF Agile Forum. And by the way, there is a lot of examples. Toyota itself where I have the pleasure to work. So, if you will to afirm something my recomendation is to search for the academic view (as you did) and the examples outside there. Good luck with your line of thought. My objective is that people really hear the other part of the history and can take advantage of a concept with is critical to achieve organizational survival. By the way I am working right now in my seventh project to put agile in practice in order the organization will get agility. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
@Priya: that is all from my side. I hope my comments have help you and other people to see the other and most of the time loose part of the agile and agility history. Nobody owns the true. But believe me, most of the hugh companies in the world have started and will start projects in order to create an environment where the organization can react to the environmental changes and create environmental changes. And that is agility. Most of those companies are naming their initiatives as "innovation", "oraganizational transformation", and other names. But when you analyze the scope you will see that all is about to implement agile in order to gain agility. And that must be done with the actual structures, methods, process, etc. Things must happed by evolution, not by revolution. You now what is the cost of a revolution. If you really understand about agile you will find that it will can implement by evolution (maintaining what exists right now and changing the way of behave and thinking which is agile) Saving Changes...
Michael AdamsSolutions Architect| LANLLos Alamos, Nm, United States
agility
[uh-jil-i-tee]
Spell Syllables
Examples Word Origin
noun
1.
the power of moving quickly and easily; nimbleness:
exercises demanding agility.
2.
the ability to think and draw conclusions quickly; intellectual acuity.
Having read through the comments a couple of times here, I''m convinced that this thread is confusing two distinct concepts:
1) applying agile methodology (this doe not include waterfall)
2) creating agility in an organization (waterfall is not excluded from this)
Waterfall project management and agile project management, meaning employing agile methodology, are distinct. Waterfall can be modified and pushed in the direction of lean or agile, but it is distinct.
However, it is erroneous to assert that an organization is unable to act with agility because it employs waterfall project management. Being predictive does not mean that a plan can''t change and having a detailed plan does not mean that changes will drop the most important parts of a project. In fact, I would assert that if a project is brought to completion and in the last months of the project, vital functionality was dropped, it wasn''t managed properly!
Priorities weren''t examined, the sponsor and steering committee weren''t sufficiently involved, the project change management process was either not followed or not robust. Most importantly, the business analyst didn''t have their eye on the ball, or there was no business analyst.
In any event, PMI methodology is an ever evolving organization and process. The fact is that maintenance of a PMP in today''s environment includes mandatory training in both strategic thinking and leadership. The purposes of these changes are to enhance the value of project managers by putting them in a position where they can keep an eye on the business climate inside of which their projects are being executed.
The fifth edition of PMI''s PMBOK guide abandoned the triple constraint in favor of a more robust list:
? Scope,
? Quality,
? Schedule,
? Budget,
? Resources, and
? Risks
And with the new requirements for PMP maintenance, this list of managing within project constraints is being broadened further.
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
All valid points you make as to what might be reasons for failure....but waterfall, strictly speaking, offers nothing to address any of them. If we start merging waterfall and agile we you get wagile or fragile - meaning we are doing neither according to their definition.
PMI methodology: the PMBOK (if that is the reference point) is a body of knowledge not a methodology. PRINCE2 however is a PM methodology. And neither PRINCE2 in its 2009 form nor the PMBOK said we had to use waterfall. That was an often misinterpreted view that was never explicitly stated in either.
I agree that the PMI with the new PMP maintenance requirements are moving the profession toward a more robust view of delivering projects. Leadership is an important addition to that discourse in my mind as it begs the question of whether we should be calling ourselves project leaders instead of project managers – especially when we are leading projects in an agile way (the implied context that started the discussion as we were asked to offer thoughts on “the external factors that can affect organizational agility and what actions that we as project and program managers needs to take to ensure that the organization is truely Agile”)
The different types of agility can serve to give us perspective on how we might answer that. It is not a simple single-focus topic as the world we now live in and the organizations most of us now work in are no longer operating in predictable ways or in predictable environments. We need to be able to adapt to what we encounter rather than attempting to trudge on in spite of it. So the real question is which approach will serve us better?
Should we stick with waterfall/traditional approaches while trying to overlay some agile practices in the hope that one day things might move back towards more predictability? Or should we acknowledge that VUCA (volatility, uncertainty, complexity and ambiguity) is the new norm so we need to fully embrace agile thinking and all that it means in order to now only cope with it but thrive because of it?
As a friend of mine said recently, we have to stop trying to manage change, and to start leading at the pace of change. Agile thinking helps us to do that. Saving Changes...
