Tag: Agile

Perfection of means and confusion of goals seem — in my opinion — to characterize our age.

Albert Einstein

This blog entry is Part 3 of a 5-part series laying out the elements of an Agile framework. It presents 4 techniques generally included in Agile methodologies, and discusses which of the 8 principles presented in Part 2 are usually implemented through them. I will try to explain why some of those techniques do not work sometimes, as well as why it is paramount to apply all of the 8 principles of Agile for Agile techniques to really succeed.

4 Agile project management techniques and why they sometimes fail

There are many techniques associated with what we call today Agile project management. I singled out 4 of those techniques that seem to be used in most projects, namely:

1. Dynamic planning, also referred to as “rolling wave planning” [1]
2. Timeboxing [2]
3. Scrum [3]
4. Deliverables evolution curves, usually known as “burndown or burnup charts”, “velocity charts” or “percent of promises completed curves”, “PPC curves” for short [4]

The purpose here is not to explain the exact mechanics of those techniques, but rather relate the way those techniques are usually applied with respect to the 8 principles of Agile covered in Part 2. For more information on each of those techniques, you can read the documents referred to in the footnotes.

Table 1, above, is a summary of my own observations on how many organizations use those 4 techniques. The techniques are often used quite blindly like “recipes”, often with very rigid parameters to respect. I was amazed to have an argument on very specific parameters with the person responsible for the implementation of Agile (for this person, meaning implementing “Timeboxing” and “Scrum”) in a very large organisation where most projects are IT related. I was preparing a conference for them on Agile project management; I intended to give some examples for “Timeboxing” periods and for the duration of a “Scrum”. I was asked to send my presentation material beforehand for validation; I was then told that according to their guidelines a “Timebox” should not be longer than 15 days and that a “Scrum” had to last 10 minutes… and asked to modify my presentation accordingly. I understood then that their implementation of those techniques had nothing to do with the 8 principles of Agile, but rather, sadly, with the search for a universal recipe to solve their need for organizational agility. Best practices promoted by recipes are the antithesis of agility.

The observations summarized in Table 1 need to be scientifically challenged by proper surveys. I believe, however, that they are representative of many implementations of Agile techniques. Many organizations try to perpetuate a work environment valuing “control” (for most the status quo) rather than to adapt to a very turbulent and changing work environment through new values like “collaboration”, “team work” and “collective accountability”. By doing so, they defeat the purpose of the Agile approach they are trying to implement. They fight to keep the status quo, while Agile tells them to accept change and manage it.

The “Theory of Constraints” and the rationale for integrating the missing Agile Principles to current implementations of Agile methodologies

“Timeboxing” and “Scrum”, at least as named, are Agile techniques that originate from the world of Software development. “Dynamic planning” and “Tracking deliverables/tangible promises” with “PPC curves” are associated to both the software development world and the world of Lean Construction Management, as promoted by the Lean Construction Institute. However, making sure those promises are done by the individuals delivering them is linked to the “Last Planner”™ principle [5], a principle not generally espoused and presented by software development specialists writing books on Agile. Lean construction project management also promotes, as a must, “integrated project teams” [6].

The 8 principles of Agile I promote are a mix between principles applied in Agile software development projects and those applied in Lean construction projects. Beside the “Last Planner” and the “Integrated Team” principles, there is another element we can find in Lean construction management books and articles, that is not often discussed in Agile software development literature. This element explains:

• why the “Last Planner” and the “Integrated Team” principles are essential; and
• why we need to include 2 more principles to succeed in our projects, the “Capability” and the “Desirability” principles.

I am talking here about integrating Goldratt’s “Theory of Constraints” in managing projects. Lean construction proposes managing around the constraint and elevating it as required [7].

In my series “Velocity” [8], I proposed that all projects are about making change. I proposed that the constraint, in any endeavour involving change, had to do with human resources, not with material or economic resources. I identified this constraint as the “capacity and will” to change, which justifies the need to include all stakeholders and ensure that they can and want to implement change. In this context, Goldratt’s “Theory of Constraints” is the approach that calls for the application of the 4 principles often missing in Agile techniques implemented in most software development projects. There is no doubt that, by adhering to Goldratt’s constraint management approach, software development projects will become really agile and get better results. I believe that, by applying the 8 principles of Agile, projects in any venue will be more satisfying for all stakeholders concerned and thus more successful.

Those 8 principles are congruent with a whole set of beliefs and values, that we could call an “Agile philosophy”. Part 4 of this series, my next blog entry, will present the 4 values and 6 beliefs that are the foundations of this “Agile philosophy”, values and beliefs that call for all of the 8 principles of Agile to make projects really work.

 Don’t forget to leave your comments below.

---

Perfection of means and confusion of goals seem — in my opinion — to characterize our age.
Albert Einstein

This blog entry contents Part 2 of a 5-part series laying out the elements of an Agile framework. It presents 8 elements that have to be put into place to succeed at Agile project management.

In Part 1, I described the prevailing organisational context of our current turbulent business environment, then used this as my basis to explain what the word “Agile” really means, and what it implies for organizations and people managing projects in 2011. My conclusion was that Agility is a must to move through the chaos of the Project Age. However the Agility to be achieved implies mobilizing all project stakeholders to act individually, but “as one mind” moved by a common vision, freely adhered too. This can only be done by putting into place an Agile framework aiming at aligning individual minds and individual goals to share a common vision and move towards a common outcome for any given project… all that while evolving in a very complex “multitask working environment”. This Agility is achievable not through alignment of actions only but, first and foremost, through alignment of individual interests; without this alignment of individual interests, alignment of actions is just not achievable.

Managing a project is like rafting on turbulent waters, together in one boat, towards an approximate destination

To help participants in my workshops understand the nature of projects, I use the analogy of a collective journey, very comparable to the journey of a family travelling together on a boat towards a collectively desired vacation destination; if it is not collectively desired, neither the journey, nor the destination will be pleasurable. Each family member has agreed personally to get into this boat and to do their share for both the success of this journey and arrival to the desired destination.

To simulate better our current turbulent business environment, the boat I talk about cannot be the usual long boat that is often used to illustrate “teamwork” in motivational posters. In such “poster” vision of teamwork, the turbulent environment in which organizations  evolve nowadays is surely not very well represented by the calm water on which the long boat travels. The notion of teamwork alluded to in this poster has also nothing to do with real organisational life; all the team members (except the project manager who decide of the rhythm of the rowing…and does not do his/her part of the rowing) row in unison at the command of their leader. We can also see that the rowers have their back to the desired destination; apparently, in such a team, team members do not need to know where they are going; they just have to row as they are told to.

The image of “teamwork” represented by this long boat could not be farther from reality in a project environment. I propose instead, as a “boat analogy” for teamwork, the image of rafters rowing together (among other things) on very turbulent waters. In order to make such a journey a success, people who are in the raft:

• have agreed to be part of this “project” (they have many other things they could do instead in their multitask working environment, maybe things more pleasurable if not less risky)…they share a common purpose because they have something in return;
• understand exactly what is expected from them (which part of the raft they are responsible for) and have the skills to do so… they have clear roles and responsibilities, as well as the knowledge and skills to carry them out, and they feel INDIVIDUALLY responsible for their actions;
• are quite autonomous in their action, as they must not wait for an order to take action when they see a rock or a big wave coming towards their part of the raft… they know where they fit globally, but they plan locally their own actions;
• take seriously their role in the raft, as they know that if they fail, they will sink with the boat… they feel personally responsible for what they have to do;
• understand that they must help each other, because if one of them does not succeed to alleviate an obstacle, everyone will sink… there is a sense of interdependency (an attribute of any TRUE team) and, as a team, they feel COLLECTIVELY accountable for the success of the journey; and finally
• understand that both the itinerary as well as the final destination will have to be revised along the way… they will be agile and adapt to new circumstances to ensure both a pleasant journey and a desirable outcome.

Those conditions of success are the same as those reflected in the 8 principles of the Agile framework I propose below. Those principles are not new and are discussed in whole or in part in many of the books on Agile/Lean project management that have been written; however, they have not necessarily been presented as principles that MUST be applied to achieve project success consistently.

In order to achieve the required alignment of individual interests, the Agile framework that has to be put into place has to reach at least two goals:

• get project stakeholders to feel INDIVIDUALLY responsible for the work they have to contribute to the project, while knowing they are part of a team of interdependent individuals feeling COLLECTIVELY accountable for the success of both the project outcome and the journey towards its destination;
• create conditions and mechanisms to ensure that everyone of the project stakeholders see, understand and want the same journey and the same outcome, thus have the same perception of what is going on and of what is changing, as the project and its environment evolve through time.

5 of the 8 principles aim at building individual responsibility and collective accountability, while the other 3 aim at creating an environment where project evolution is tracked and shared collectively

5 principles to build individual responsibility and collective accountability

Most of the following 5 principles have been presented in some of my previous blog entries in Project Times. While I will give a brief description of each of them here, I will refer to previous blog entries for further details, whenever they exist. For those not discussed in previous material, I will give more details in my future blog entries if required, right after I finish my 5-part series on this Agile framework.

In order to build individual responsibility and collective accountability, the following 5 principles have to be applied to project work:

1. The “Last Planner^® Principle“ [1]. The person who has to execute the work is also the person who will plan it. Often, the most important Last Planner is the end-user of the project final deliverables, yet we fail to properly include this stakeholder on the project team. [2]

2. The “Capability Principle“[3]. Everyone working on a project must have sufficient

• information about the project to be able to share the project vision and feel interconnected with other team members, as being a very important part of a very important whole;
• knowledge and skills to deliver what is expected from him/her;
• material resources and relevant support to deliver what is expected; as well as
• time to apply the level of effort required to deliver successfully.

If those conditions are not met, this person will not readily accept responsibility to deliver what is expected; he/she can even refuse to do it directly or through stalling the work.

3. The “Desirability Principle“. Individual interests won’t be aligned with the project:

• if the fact of working on a given project does not result in some kind of reward for the person who does the work (the “What’s in it for me?”); and
• if this reward is not proportional to the effort to be consented to deliver the work (the “Is-it worth it?”).

So, if the individual interests of a team member are not taken care of, this person is likely to work on something else more rewarding than on your project.

I have not specifically covered this principle in a previous blog entry, although I have alluded to it many times already in my ongoing series on “Velocity”. This principle appears quite self-evident to me, particularly in a “multitask working environment”. I might expand on it later. Meanwhile, I refer you to web entries on Vroom Expectancy Theory of Motivation; there’s a lot to learn from Dr. Vroom in order to build a real project team.

4. The “Tracking Small Individual Promises Principle“[4]. Project deliverables are divided in small “observable” promises, over very short time periods: for example, once a week and broken into deliverables having an effort level of 80 or less man-hours. Those promises are those of each individual team member, not those made for them by their bosses or the project manager.

5. The “Integrated Team Principle“[5]. You have to expand the “traditional” project team to include and integrate all significant stakeholders as part of this team as early as possible. Among others, this is a mean of recognizing the interdependency that connects all project stakeholders and of developing COLLECTIVE accountability.

3 principles to create and maintain a «shared» project environment

As for the principles discussed above, I will give a brief description of each of the 3 principles that support the creation and maintenance of a “shared” project environment, and I will refer to previous blog entries for further details, whenever they exist.

What one should try to achieve through the use of these principles is to align perceptions. I believe that one of the main causes of project failure is that project stakeholders do not have the same perceptions of what a given project is about, of what is its current status, as well of how it has changed and is evolving. Managing a project means managing perceptions; failing to do so is a major mistake and will result in project failure.[6] In order to put into place a “shared” project environment, the following 3 principles have to be applied to project work:

6. The “Proximity Principle“.[7] The project client, the sponsor, the suppliers, the contractors, the project specialists, the end-users are not only part of the integrated project team; they receive continuous feedback about what is going on. Every project change is communicated and feedback on it is sought to ensure a common understanding. No single stakeholder should be kept out of the loop.

7. The “No Surprises Principle“. This principle is a supporting principle to ensure that we have real proximity (supports the “Proximity Principle”). Ultimately this principle is used to eliminate as much as possible surprises to any stakeholder when project changes take place. The longer the time between the change event and its disclosure, the bigger the sense of surprise… and the bigger the feeling of having been kept in the dark and out of the loop. By eliminating “big surprise” effects, stakeholders will be more into an “adaptation” mode to normal frequent project changes (the fabric of being agile) than into a «resistance» mode towards changes that they did not see coming.

8. The “Accelerated Benefits Principle“. The faster you can get benefits out of the project – which means DURING the project journey, not only at the end of the project – the better it is. After all, we are in turbulent waters and not sure where we will end up, so why not reap benefits while we can. If fact, if there is one principle that is always associated with Agile Project Management, this is this one, as illustrated by the purpose of the timeboxing and scrum techniques that are the foundations of most Agile methodologies. Clear, observable benefits, tangible project deliverables along the way are one of the most effective ways to ensure stakeholders see the same project evolution, since sharing a concrete deliverable and its meaning is easier than sharing ideas and intangible benefits.

I must add that the benefits we are talking about here are not only the ones measured in terms of the official project outcomes, they also are benefits associated with meeting the individual interests of the team members; failure to deliver such benefits will work against the «Desirability Principle» and will put both the project journey and its destination in jeopardy.

So those are the 8 principles underlying an effective Agile framework, as I see them:

• The Last Planner Principle
• The Capability Principle
• The Desirability Principle
• The Tracking Small Individual Promises Principle
• The Integrated Team Principle
• The Proximity Principle
• The No Surprises Principle
• The Accelerated Benefits Principle

In my next blog, I will present the 4 most used Agile project management techniques. I will cover their use in relation with the 8 principles discussed today. I will explain how we can improve both the effectiveness and efficiency of those techniques through applying all 8 principles to them.

Don’t forget to leave your comments below.

---

Part 1: The Project Age and the case for Agility

Perfection of means and confusion of goals seem — in my opinion — to characterize our age.

Albert Einstein

As announced in my last blog entry, this is Part 1 of a 5-part series laying out the elements of an Agile project management framework. It will discuss the context of realising projects in today’s turbulent environment, as well as why Agility has become a must for most projects. By doing so, readers not familiar with Agile will have a better understanding of what the word “Agile” really means and what it implies for organizations and people managing projects in 2011.

Back in 2001, Hugues Bouchard, (1) a fellow project management professional, and I wrote a working paper welcoming people to what we called the “Project Age”, our 21st century. This working paper was later used as a starting point in the development of the 1^st edition of PMI’s “The Standard for Portfolio Management”. Back then, this is what we were seeing:

Our times are characterized by:

• Worldwide competitive pressures
• The need to differentiate oneself in a global market
• The requirement to meet high quality international norms and processes to be accepted in new markets and be more competitive
• Shorter and shorter product life cycles
• Faster new product development imperatives

Today’s organizations are forced to invest more and more of their resources in strategic projects in a race to keep the upper hand over competitors and increase their value, be it for their owners, their shareholders, their customers, their employees or society as a whole.

In the new economy sectors (biotech, telecom, IT, e-business, etc.), “mixed” organizations, executing as much activities or more activities on the project side than on the traditional/operational functional side of their businesses, are now being more and more involved in the development of project offices, program management systems, portfolio management and “gating” processes, strategic project management organizational structures and the like.

Even more traditional manufacturing organizations are forced, by global competition and time-to-market pressures for new products, to invest in strategic projects to keep their edge. While doing so, they have to reconcile a strong functional culture with the peculiar needs of delivering through unique, “one-time only” projects. In this situation, these organizations are also developing their versions of project portfolio management systems, “gating” processes, project support offices, sometimes in an atmosphere of great unease. This is particularly true of those organizations who still have to maintain a strong functional culture while, at the same time, committing more and more time and resources to project initiatives. (2)

Do you recognize your business environment? I believe that these words still define correctly our turbulent times. This turbulence has even increased many times in certain cases. Projects and recurring operations are so entwined together nowadays, that both functional order and the chaos of change coexist in most working situations.

One of my clients recently told me that:

“There are so many projects in our organization that it is a challenge everyday to both realize those projects and do our operational work properly. If we compare our current operations to the action of driving a car, those projects make us feel as if we have to change the car engine while still proceeding at full speed with our car ride”

All these projects still cause much confusion in organisations, most of them having yet to put in place a proper corporate project portfolio management system; that is, from my observations and experiences, the reality of the vast majority of the organizations I came across. Basically, I found the following project environment in those organisations:

• Upper managers do not agree on the number of projects taking place in their organisation, estimates often differing by a factor of 10
• Year after year, most managers complain that they have too many projects to realise (they are understaffed)
• The syndrome of «the Project of the Day» is ever present, new urgent matters taking over current ones
• Resources are spent on projects that have little or no value for the organisation
• A lot of efforts are spent on starting projects that end up never being completed

Amidst all this confusion, this multi-project environment has also created a new kind of project management reality that of the part-time project manager working with a part-time project team.

What I am going to say now is not the result of a formal study (which will be done in the near future), but rather a generally conservative measure of the “Project Age” dynamics, based on informal surveys. Again and again in the organisations I worked for as an external project management coach and in the workshops I have given to hundreds of project team members from all kinds of organisations, I have received the following answers when I inquired about their project-related circumstances:

• About only 1 person out of 15 (7%) works full time as a project manager
• Out of those who work full time as a project manager, only 1 out of 10 works on only 1 project at a given time (so 1 out of 150 people, less than 0,7%, manage projects work as a full time project manager on a single project)
• 149 people out of 150 (99,3%) work on many projects at the same time, only 10 of them doing only project work.
• The remaining 140 people (94%) work both on recurring operations in a traditional functional role and on many projects at the same time
• More than 75% of the people surveyed work on more that 5 projects at the same time, 20% admitting to work simultaneously on an unbelievable 10+ projects simultaneously (while doing recurrent work at the same time)
• The vast majority of those projects are multi-functional, meaning that a large part of the project team does not come from the same functional department as the project manager, hence do not report to the same functional boss
• The vast majority of people working both on projects and recurring operations have performance evaluations, on which their promotions, salary raises and bonuses depend, that do not evaluate their performances on projects and their contributions to project results (…so, what’s in those projects for them?).
• 8 persons out of 10 (80%) say that the priorities given to the projects they work on are unclear and are continuously changing for reasons unexplained to them.

….Consequently, in this added confusion of priorities and unclear management goals, the vast majority of the people surveyed admitted that, unless there is “urgent” work to do, as required by their hierarchical boss, they decide on their own which project they are going to address on a given day… and the basis of their decision is “what pleases or interests them most, on a strictly personal level”.

So what does that say about the case for Agility, and what kind of Agility are we talking about?

As I see and experience it, current organizational project environments have nothing to do with the paradigm of a world of projects run by professional project managers with dedicated teams. At best, we are talking about organisations that largely run projects in “weak matrix” mode (no full time project managers on most projects). For those organisations “being a project manager” is not a formal position on an organisation chart, but rather a role, an extra hat worn by people who have others things to do and manage than projects. Those people work in an ever changing project environment, where priorities are redefined continuously, often for legitimate but badly communicated reasons. Such an environment requires a lot of flexibility from project teams to adapt rapidly to new situations, which is basically what Agility means.

In a business context, Agility means “the capability of rapidly and efficiently adapting to changes” (3). However, in the multi-project context depicted above, Agility represents a bigger challenge than putting together processes where humans “physically” move together towards a common goal. We are talking here about humans “psychologically” moving together, aligned by a common vision, while servicing different individual interests achieved through many individual, yet coherent and congruent goals. Short to achieve that, as said Albert Einstein, no physical means will ever compensate for the confusion of goals pulling all of the project team members and whole organisations apart.

Agility is not only a must to move through the chaos of the Project Age, it has to be Agility achieved by mobilizing all stakeholders to act individually, but “as one mind” moved by a common vision, freely adhered too. All efforts of an Agile project management process have to be concentrated in achieving this alignment of individual minds and individual goals. Project stakeholders have to share a common vision and move towards a common outcome, a “individually” desired project outcome, while working on all their other required simultaneous operational and project tasks.

How can we design an Agile framework doing just that? I will offer an answer to this in my next blog entry: “Part 2- 8 principles of successful Agile projects”. I will present 8 elements that have to be put in place to succeed at agile project management.

Don’t forget to leave your comments below.

---

 

I’d like to begin this post by trying to describe some of the anti-patterns or characteristics of non-transparent work behaviors. This list will probably not be complete, but it should give you a sense of the other side of the fence.

• There are several show-stopping defects in your current code base and you are either not tackling them with your best people or hoping their intermittent nature won’t surface inopportunely before general release. So essentially you are throwing a few bodies at the problem and hoping nobody truly notices.
  
  

If you’re transparent, you must acknowledge and manage quality—being willing to “stop the line” if things aren’t’ right and fix them. This takes courage and commitment.

• Your team is working incessant over-time; making more and more mistakes as they go—daily adding rework and risk to the project on a daily basis. Not everyone on the team seems to think you’ll miss the deadline and nobody in management is willing to “admit defeat”, so all project status reports are still shown as GREEN and the project as “doing fine”.

If you’re transparent, you resist the lack of character & courage to tell the truth about project state for fear of ramification. Instead you routinely tell it “like it is”, and look to make healthy adjustments from “where you are”.

• You began this project three months ago and the business stakeholders were ecstatic when you kicked it off. They even threw a party. But then they “went away” and you haven’t been able to clarify and reconcile numerous requirement questions with them along the way. You’re having your release demo tomorrow and now they all seem to have the time to come and check out the results. The “Great Reveal” is at 3pm and it should prove to be exciting.

If you’re transparent; folks need to be willing & sufficiently engaged to participate and evaluate, in real-time to the good AND the bad of your project state. They need to literally get in the game with you and become involved in moving the project forward— guiding the project towards success.

• You are struggling to deliver the fixed set of features in your latest release. You know which features are at risk, but can’t have the discussion to drop any of the features because the business insists that ALL are 100% required. As a result, you slipped the release date five times and eventually delivered a release with low quality, 14 weeks later than your initial commitment. Oh and did I mention that seven of the most critical features were missing?

If you’re transparent, you acknowledge adversity, look it square in the eye, and make adjustments to your goals. You do so from a position of business value and priority—realizing that everything isn’t equal. You realize that delivering something has great advantage over oscillation.

Now that you have an idea of situations and responses that can be linked to transparency, let’s delve further into more definition.

What is transparency?

From my perspective, it’s the honest and open dialogue about the current state of software development within a project context. There’s no real value in telling you what you want to hear. No providing misleading or hiding information. I have the phrase “It is what it is” running through my brain whenever I think about transparency. What you need to do is show off all the gory details of a project for the world to see, digest and then constructively and realistically react to these details. For example:

• Show your open defect counts and their rate of increase/decrease
• Show your number of sprint escapes or rework that cascades into the next sprint
• Show your project feature-set burndown for the release
• Show your teams’ sprint burndown
• Open the door to your daily stand-up meeting; ask the team not to filter anything as a result of attendee mix
• Open the door to your sprint planning sessions
• Open the door to discussions around what to do about your highest priority feature that is  struggling to see the light of day
• Run a company-wide retrospective for your latest release; taking feedback on all aspects

As an Agile Project Manager, you want to create situations where your progress is simply – transparent in as many situations as you can. There’s the notion of Information Radiators in the agile methods that are intended to serve this purpose. They don’t comment on state as either good vs. bad. They simply radiate it for everyone to see, digest, and react to.

What does transparency create?

Transparency creates congruent conversations which drives congruent actions. Imagine one of your teams having the following burndown chart for an existing sprint and your progress is right in the middle of the “danger zone”, where it’s obvious that “things” aren’t going too well. 

 I’m actually delighted when this happens. And when a stakeholder attends one of our daily stand-up meetings and quietly listens to the discussions. Afterward, they pull me aside at the sprint burndown chart and ask—“We’re not doing so well right now, are we?” And I say “No.” But beyond that, they ask for more information and recommendations for corrective actions—“What do we do now?”

Ah, now that opening leads into all sorts of prime conversational real estate:

• We can and should start looking to jettison content from our sprint goal if possible. No, not the highest priority things, but the lowest. Additionally, can we reframe stories so that we can still hit the goal, with less scope?
• Another point is to get the team engaged in the discussions. In fact, they’re behind in their own commitments for the sprint—so they need to be engaged. What ideas do they have about root cause and corrective adjustments? Can they move work around the team or attack things differently? Do they have any impediments that they want to disclose?
• Does the experience of the team come into play? Is the wrong person attacking this work? And would an assignment change, shifting work around, help us to recover?
• If it’s related to defects, is this an ongoing trend? Is it related to exhaustion or excessive overtime? Does the team lack core, requisite skills? Or domain experience? Or are they simply sloppy in their professionalism?

You see, transparency leads us away from obscurity and into clarity. It’s all about delivering our goals. If there is a risk, our mantra should become – How can we deliver the most value? Short-selling quality should not be an option. Working like dogs is also not an option. Making scope compromises based on early detection and early, mature, and considered reactions to reality is the only option.

Reactions must be made, tightly partnered with your business stakeholders, in a non-confrontational, but truly collaborative fashion. Agile Project Managers must do everything they can to effectively guide their project stakeholders and teams in THAT direction!

Don’t forget to leave your comments below.