An Agile Framework Part 2 – 8 Principles of Successful Agile Projects

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.

---