My previous article talked about the unsuitability of a Project Manager for an Agile project and as was to be expected, this position did not go down well with those who belong to a different school of thought. The article was not designed to impose an opinion on the audience but to provoke the audience to some independent thinking backed hopefully by some further research. This week I will continue by discussing some of the factors that made me arrive at that somewhat unpopular conclusion. I will compare the principles and practice of a quintessential Project Manager and an Agile Leader in an Agile environment using Agile Values and Principles.
Agile Values
1. Individuals and Interactions over Processes and Tools
Agile places human interactions and relationships over processes and tools. You would agree with me that Traditional project management is not focused on human relationships, its emphasis is on the efficiency and effectiveness of the project tools and overall process. Agile on the other hand is keenly aware that projects are about people as the project is undertaken by people, problems get solved by people, solutions get proffered by people, the Definition of Done is agreed upon by people and the final acceptance of the project work is done by people not tools or processes. So essentially, to the agile mind, higher importance should be given to the team and its human interactions than to the processes and tools used for the project. This would not work well under the guidance of a traditional Command and Control approach of a Project Manager.
2. Working Software over Comprehensive Documentation
This places emphasis on the need to deliver the system the project was designed to deliver in the first place. This value helps to redirect our focus to the product we are actually meant to deliver as against mere paper work that in actuality adds little or sometimes no business value to the project at hand. A Project Manager who is by default in control of the project would place emphasis on paperwork as is the case in Traditional Project Management where documentation is almost as important as the end product itself. Management is frequently more interested in the accuracy of our artifacts than on the business value the system we are developing presents to the customer. For example, Agile would recommend displaying Kanban boards, flow diagrams, task lists etc. that are easy to create, understand and time saving rather than devote time to producing a Gantt chart that would convey essentially the same message. Agile encourages management to walk into your team room to see the project progress for themselves even without calling the attention of team members and taking away from project time. This helps to eliminate waste in the form of time wasted. As a matter of fact, Agile’s approach to documentation is “just enough, just in time and sometimes, just because.” Please read my article titled “Agile Means No Documentation. Myths. Assumptions. Facts” for more information on this.
3. Customer Collaboration over Contract Negotiation
Agile calls for flexibility and adaptability rather than rigidity which is what obtains in Traditional project management. Traditionally, a Project Manager ensures, almost upon his life, to capture all of the customer’s requirements in the project Scope document. The Project Manager then proceeds to ensure that changes do not occur to this scope and in the event that a few of the most critical changes manage to survive this change suppression process, the changes go through such a rigorous process that it is safe to say that changes are not welcome under the stewardship of a conventional Project Manager. Agile on the other hand, recommends that its Servant Leader who doubles as a Coach, welcomes and embraces change and for this to be effective, an Agile Leader must be flexible and pay more attention to “doing the right thing” than on “being right”. This is yet another polarization factor evident in the functions of a Project Manager and an Agile Leader.
To support this claim, we must bear in mind the fact that Agile projects are most suitable for exploratory, high risk work that are hard to define upfront and as a result require ongoing collaboration with the customer. This is certainly not in tandem with Traditional requirements which are gathered and baselined at the commencement of the project. A Project Manager wants his requirements baselined upfront, an Agile Leader is flexible and open to change.
4. Responding to Change over Following a Plan
At the onset of knowledge work projects, the information available is incomplete and by extension, our initial plans are insufficient to complete the project. As a result, rather than baseline these insufficient requirements and then begin to battle endless change request processes, Agile recommends that we devote more time and resources responding to the changes that are bound to arise. You would agree with me that it is smarter to be flexible and plan as you go (especially when you have insufficient information) than to draw a baseline and then begin to try to make endless changes to completed plans. Agile suggests that you do not attempt to baseline your requirements until you are sure of all your scope inclusions and exclusions which is usually at the tail end of the project. This is particularly so in software development projects where the rate of innovations can almost now be compared to the speed of light. Customers who are in business to make profit might put themselves at a disadvantage if they stick stubbornly to a plan/feature that might become obsolete very shortly after their competition brings up a new innovation. A successful knowledge work project must be open to change to remain competitive. Alas, this is not the recommendation for projects with a Project Manager, change is most unwelcome to the Project Manager.
Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is one of Agile’s priorities but this does not match the priorities of the quintessential Project Manager; the Project Manager’s highest priorities are working within the 3 project constraints of Scope, Time and Cost along with ensuring his deliverables are accurate and ready as at when due. Customer satisfaction for the most part, frequently takes a back seat to these. The average Project Manager’s focus is usually not on early delivery as delivery only happens at the very end of the project. In like manner, continuous delivery is not an option for a Project Manager as the project is planned to deliver in full, once, at the end of the project.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Welcoming changing requirements does not and can not happen in mainstream Project Management. “Even late in development”, impossible situation. Project Managers would know exactly what I mean; since a baselined Scope is the very foundation of the project, this Does. Not. Happen. with emphasis on “welcoming.”
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
First of all, frequently? No, this does not happen in mainstream project management as the product/service/software is only delivered when the stages of initiating, planning, executing, controlling, and closing have been completed in a single continuous process. There’s no “shorter timescale” as what exists is a single delivery.
4. Business people and developers must work together daily throughout the project.
From my experience, we Project Managers don’t even want to see or hear from the client after the Scope document has been completed and signed off; we do not welcome change, after the fact. At the onset of the project, yes, there are a few meetings/interactions to ensure that we have captured every possible requirement of the client and after that, we almost wish to change our contact details until the project is ready to be signed off. This Agile principle is therefore contrary to the workings of the mind of the average Project Manager.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
Sometimes you are lucky to get a Project Manager who pays attention to the level of motivation of his team but more often than not, most Project Managers work under enormous pressure and pay little or no attention to that. Incidentally, Traditional project management gives preference to processes and tools over human relationships so your guess is as good as mine as to what happens on most project teams. “trust them to get the job done”, this right here is laughable to the average Project Manager; he is trained to direct and control because he is responsible and accountable for the outcome of the project. In Agile, the Project Leader; Scrum Master/Coach is not responsible for the outcome of the project. The Project Leader is responsible for ensuring that the team becomes Agile in their thinking and approach to project work, the Product Owner is responsible for the requirements and the team, for the deliverable.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is completely not in tandem with how a Project Manager works; I’ve had many instances way back where I shot off emails/used different tools to communicate with team members sitting 2 seats away from me not only because I felt I was too busy to walk over but because I did not know the importance of face-to-face interaction. I have the benefit of coming from a Traditional project management background and this makes it easy for me to see the distinctions between the roles of a Project Manager and an Agile Leader. Though Traditional project management encourages direct communication but the need for face-to-face communication is not emphasized. Traditional project management thrives on documentation and relies largely on it along with various tools for communication.
7. Working software (system) is the primary measure of progress.
Within mainstream project management, a working system is only one of the many measures of project progress. Artifacts such as status reports, the project management plan, risk management plan, communication management plan, stakeholder management and release management plans, alongside the master test plan, test cases and UAT/BAT test plans amongst many others are just as important or almost more important than the product/service being developed up until the point where the customer’s acceptance is required. This is yet another extreme deviation from the priorities of the Agile methodology.
8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
This is not a priority to the average Project Manager, as a matter of fact, overtime is quite common under the guidance of the mainstream Project Manager as all hands are frequently on deck to bring the project under control and within the constraints of time. To combat this, Agile frameworks like Scrum have in place the concept of Velocity. Velocity is a metric that is arrived at by reviewing work the team successfully completed during previous sprints/iterations; for example, if the team completed 10 stories during a two-week sprint and each story was worth 3 story points, then the team’s velocity is 30 story points per sprint. Hence it relies on it’s velocity which helps to ensure that the team works at a reasonable, realistic and by extension, sustainable pace. Other Agile frameworks like XP also ensure to maintain a sustainable pace, Kanban utilizes the Pull system which means that once a work item is completed, this triggers a “pull” to bring in the next item to be worked on.
9. Continuous attention to technical excellence and good design enhances agility.
Agile teams are encouraged to pay close attention to keeping the product design clean, efficient and open to changes. This is because cleaning and preventive maintenance is better than fixing problems. Agile frameworks such as eXtreme Programming utilizes practices such as Collective Code Ownership, Code Standards, Metaphor, Continuous Integration, Test Driven Development, Refactoring, Simple Design, and Pair Programming just to ensure that technical excellence is achieved and maintained. This is over and above the steps a Waterfall project would take to ensure technical excellence under a Project Manager.
10. Simplicity‑the art of maximizing the amount of work not being done‑is essential.
Agile encourages its customer’s and teams to focus on simplicity especially in the software world where most of the features end up as nice-to-haves and are rarely or never used. Therefore, to avoid waste, as Agile is very Lean in its approach to product development, Agile asks that “what is the simplest thing that could possibly work” and recommends that this solution be built first. Because of the nature of Agile contracts (read my article on Agile Contracting for more details), Agile projects still make their profits using this approach. At the other extreme is the conventional Project Manager who is not inclined to make this recommendation to a client. Time is equal to money in a Traditional project management environment and in the mind of the Project Manager. The more complex a solution is, even if 50% of it will be waste, the more time it would require and by extension, the more profit the Project Manager’s firm makes, so essentially, mainstream project management is not lean in it’s thinking; there is no deliberate avoidance of waste in the form of customer investments.
11. The best architectures, requirements and designs emerge from self-organizing teams.
People are at their best when they are trusted to use their discretion. Self-organizing helps people determine the approach that is most productive for them. You would agree with me that you do not have to sell an idea to a team if the idea originated from them in the first place. Knowing that they helped design the process they are using ensures that they are passionate about it and will therefore be committed to making it work.
In line with the above, the members of a self-organizing team are the closest to the technical details of the project, and are therefore better positioned to identify issues along with the opportunity to fix them. The team members are the most informed about the project and have the most at stake in the project. A Traditional project team is not in the least self-organizing, all the authority in the team rests with the Project Manager.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Both Agile and mainstream teams have lessons learned sessions but the frequency and objective differ greatly. A Project Manager will organize a Lessons Learned session to review the lessons of a project that commenced probably a year ago and the team is compelled to go through what is akin to a history class, sometimes not remembering the details or outrightly forgetting what was once upon a time an issue on the project because it was so long ago. Agile on the other hand, has frequent retrospectives which takes the form of a learn-as-you-go session. These lessons are still actionable on the current project and would help to guide the remaining part of the project. The retrospectives are done at the end of each iteration/sprint and this creates regular opportunities for the team to review its progress.
Hopefully these few points have been able to further position you to decide for yourself if a Command and Control personality such as a Project Manager, truly fits in Agile’s humanistic, nurturing and self-organizing environment.