Comparison of Traditional Versus Agile Planning

Either by working on an Agile project in a company with a traditional project management office, or by struggling with reporting project status back to the PMO because traditional project measures do not match Agile concepts and practices, I find as an Agile consultant that the biggest impediment in the success of an Agile adoption is the organization itself.  In my experience I have come across five different stages of project planners:

• Traditionalist – A project planner that follows the letter of the law of PMI and expects everyone else to do it the same way.
• Receptive Traditionalist – A project planner that seeks comfort in traditional project management but is open to other schools of thought when it makes sense.
• Agile Student – In this beginning stage, the Agile student follows the teachings of one Agile master precisely. He or she focuses on the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the work, he or she concentrates on just the one way he or she knows.
• Agile Practitioner - The Agile student begins to branch out. With the basic practices working, he or she now starts to learn the underlying principles and theory behind Agile. The Agile Practitioner also starts learning from other Agile Practitioners and Masters and integrates that learning into his practice.
• Agile Master - Now the Agile Practitioner isn't learning from other people, but performs his or her practice. He or she creates approaches and adapts what he or she has learned to his or her particular circumstances.

Of the five project planner types listed above, which one do you feel is the biggest impediment to Agile adoption? The Traditionalist project planner. How do you know if you or a person falls into the Traditionalist planner type? To borrow a line from the comedian Jeff Foxworthy, you might be a Traditionalist if:

• You insist that all requirements are detailed ad nauseam before the project can begin.
• You must have all the requirements before you can estimate when the project can be completed.
• You are okay with change as long as a work order is put in, determined, budgeted and scheduled for after the project is complete, and the critical path based on detailed engineering phases and tasks is updated.
• You don't understand why Agilists do not know the entire scope of their project and why they are not concerned about that.
• You dream about Gannt and Pert Charts.
• You are confused when Agilists state they will deliver what is done when it is done, done.
• You are confident in the beginning you will hit your implementation date, and nothing will change, and you will fight any attempted change as hard as you can.
• You insist that testing cannot be started until everything is developed first.

It was necessary to review these project planner types to explain how Traditional and Agile planning is different in most organizations.  These differences can cause much contention due to the expectations being different.

Attributes of Traditional versus Agile Planning

Planning Attributes

Attitudes

After creating all-inclusive requirements and design documents, a traditionalist can chart out what needs to be completed in each phase and has a high confidence level as long as we keep the target and stay on schedule, we will meet our objectives.  Because everything has been thought of already, the traditionalist attitude is one of optimism and confidence that the project will not fail.

In contrast, the Agilist is one that knows that he or she will never be able to think of every obstacle or feature. Additionally, they know that once the client sees the product, he or she will invariably change his or her mind based upon what they know now. The Agilist offsets that knowledge with thoroughly documenting the first 30-90 days of development. The Agilist will also work with the Product Owner and team to record the next 90-180 days at 80% and the next 180 – 270 days at 60%. There is no need (and waste) to document everything at once if you know it will probably change. The goal of Agile is to get the product in front of the Product Owner quickly so that the team can fail fast, learn, and adjust. An Agilist knows that the product will continue to morph from the original thought and welcomes that. The Product Owner, in the end, gets what they need.

Change Control

In a traditional project, a change request is needed for all scope changes. This change request will need to be evaluated, scoped, estimated, approved, and more money allocated to the project if needed. Traditionally, this work is slated for after the project completion, or more people are brought on to still complete with the original release date. Alternatively, some work may be descoped from the project to make room for the change request.

All work in an Agile project comes in the form of a user story. So, if a change is needed, a user story is created, estimated, refined and then put in the backlog. If the Product Owner feels it adds more business value than the stories currently slated for the next sprint planning, he or she may list them as candidate stories. It will be up to the development team to decide whether those stories can be completed in the upcoming sprint timebox or not. The most significant difference here is that in Agile you have a fixed date and budget, but a variable ever-evolving scope. If a Product Owner wants something new, then something already scheduled must come out and be considered after the project completes as original work.

Communication

Communication in a traditional project is typically done in the form of a weekly status meeting.  This helps the Project Manager to keep an eye on the commitments and the critical technical path and to react if something is gone off course with the team.  These weekly meetings are then summarized into a monthly status report that gets sent to stakeholders and the PMO.  Additional meetings are scheduled for change control and project review.  Decisions are made at these meetings and can become roadblocks if appropriate choices are needed. Moreover, due to the "we must no make mistakes" culture new risks and problems are often only revealed when there is no more chance to hide them (all the time hoping that somebody else has to report a delay first).

In an Agile project, the authority to govern and make decisions about the project is given to the Product Owner and the team. The team and the Product Owner meet daily to discuss what is occurring on the plans. This usually is a quick 15-minute meeting where all the team members go around and talk about what they are working to complete. Anyone, from the CEO to the janitor, is welcome to attend this meeting, but they have no voice. Only the team and the Product Owner have the right to talk at this meeting. The daily sessions make these projects highly transparent and relevant. The goal is to remove any roadblocks the team has that same day. An additional Sprint Review meeting is held every two weeks where the Product Owner demonstrates working software to the Product Manager and Key Stakeholders of the project. There is no need for formal reports as all communication is handled live.

Focus

A team on a traditional project can quickly lose focus because they see the entire workload of the project.  It is straightforward for a developer to lose sight of what the real priority is. In an Agile project, the development team only focuses on one sprint at a time, which usually is 2-4 weeks in length. The Agile teams are more team focused because they agreed to accomplish work as a team for an entire sprint. If one developer is struggling, it is up to the team to pick up the work and complete it on time. The team members work much closer together than on a traditional team.

Planning Participation

Traditional project management is generally a process-oriented approach that involves a sequence of activities. Planning in a traditional project can be done with the PMO, Project Management, product managers, and other requestors in the organization. Any deviation from the plan is looked at as a sign of concern and may be escalated up the chain of command. It is generally the project manager who is accountable for useful accomplishment of the project, and he or she makes choices on various aspects of the project. Traditional projects stress all-encompassing planning and observance to the project plan. Changes are accomplished through a formal change management process, and value is produced at the end of the project when the product is provided.

Agile project planning is scope/deliverable based on various refinement levels and accomplished in detail at the team level and the defined final decision maker, usually the Product Owner, clears any impasse. In Agile, there is no scope for planning on its own. Team knowledge and know-how are used to evaluate the requirement to the plot, split it into continuously smaller and refined parts, and evaluate and perform the equal work necessary for the project. In Agile, all-encompassing planning in full detail is not done before closing to the end of the project. Planning of prioritized work packages is completed during Iteration Planning.

Business Value-Driven Delivery is a vital advantage of Agile and delivers by drastically improving the throughput of business value. Because of the iterative nature of Agile, there is always at least one release of the Minimum Viable Product (MVP) available. Even if a project is dismissed, there are usually selected paybacks before early completion. One of the notable distinctions is the level of ownership and culpability that leadership offers to team members. In traditional project management, a PM hat the entire ownership of the project. Clients are involved with the planning phase, as the development completes. In Agile, every team member is required. Each has a responsibility to finish the iteration within an agreed time-box. Everyone involved has complete transparency to the progress throughout.

In traditional projects, clients are highly involved in the beginning. Their input is the requirements of the software application to be developed and how they picture it to work. Clients have reduced participation after the development begins. They usually get to see the result after the development is finished. In contrast to Agile, the clients remain involved throughout the development process. They can review every package of deliverables and make recommendations for enhancement. The clients are more engaged in the development process. This leads to a delighted client.

Product Delivery

The traditional project management approach is linear where all the technical phases/stages of a process occur in sequence for the whole scope. Every project follows the same lifecycle. The complete project is scheduled forthright without any room for varying requirements. This methodology believes that time and cost can change, but requirements are fixed. This is the cause of the budget and timeline issues in traditional projects.

Agile is iterative by design, and a working product can be sent to the client after each sprint. Each iteration increases the level of confidence of the project, as the client then also has the chance to provide feedback and change his/her mind regarding the direction the results are going. The basic concept behind Agile is that it embraces change and collaboration to deliver products, rather than to following a structured process. Being able to adapt consistently is the most significant advantage that Agile has.

Making changes in Agile is more accessible than in traditional projects. Team members have the luxury of being able to experiment with different paths that may be better than initially planned. Agile makes it possible to be able to be more flexible in that regard. Agile is about delivery products and less about following procedures. Changes are not only expected in Agile, but they are welcomed.

Agile takes a mindset to change. A developer must build their product with the intent that their code can go out into production with each sprint. An Agile developer uses Feature Toggles to turn off their code, so it does not get executed, which allows the code base to be installed in production. This eliminates the need for complex branching strategies.

Supervision

In traditional projects, the Project Manager is in charge. He or she has the responsibility to plan and document the life of the product being developed. Customers are engaged in the planning stage, but once implementation begins their involvement is not required. Since the Project Manager is responsible for the project, team members don't usually have a lot of say in how the product is put together. The requirements are done before most of the developers start on the project.

On an Agile project, the team members contribute to the ownership of the product. All members are responsible for a continual review of the requirements, help to estimate the time and effort. The key to Agile success is complete transparency in both directions (inside and outside of the teams). Having transparency allows people to speak up and point out when something could be done better and leads to a productive and highly involved team.

When impediments do arise, they should be reported up the chain. By attempting to do so may introduce roadblocks in themselves. Agile teams can make decisions on their own for the product they are building. If the decision affects something out of their area, they will need to get permission on how to proceed or ask for help. The team tries to resolve their issues. Agile teams infrequently need to raise significant problems to their leadership.

Testing

The traditional testing approach bases comprehensively on the accessibility of accurate and revised documentation. These documents are acute contributions to software testing in the life cycle. The end customers typically do user acceptance testing.

In Agile there is a substantial dependence on the team interaction. The testers are continually in alignment with the developers and design the testing strategy appropriately. QA can execute the acceptance testing due to the acceptance criteria being a part of each user story. Agile testing is much more involved daily and in the definition of requirements than in the traditional approach. This additional involvement gives a greater responsibility for QA. Testers are expected to perform manual and automated testing.

With traditional projects, QA performs test planning. The tester must create test plans, strategy, test scenarios, and test cases. The testing is based on the requirements, and each test must be accomplished within a specific time frame (including potential fixes by development and retesting). Exceeding the prescribed timeframe can extend the development effort. If development takes longer than their timebox, the testers time frame is typically shortened.

In Agile there is no longer a need for test planning. It is an essential part of the iteration planning. The Agile team is responsible for the quality of the end product; therefore, testing effort is no longer estimated by the Project Manager, but by the whole team.

In traditional projects, the test team works mostly in a silo. In Agile the testers are combined with the developers. The testers are always involved in all facets of the project, to include the requirements and design of each component.

Transparency

In Agile methodology, all things are transparent. The clients and decision makers are actively involved with the teams in the initiation, planning, review, and in the testing part of a product. Whereas in the traditional approach, the project manager is holding reins of the project, thus others don't get to make significant decisions. The Agile methodology facilitates team members to view the progress right from the start to the end with a full explanation of the background and the "why" of requirements. Also, it facilitates the PO and all involved stakeholders to see results and experience issues with the requirements and plans first hand. This level of transparency plays a considerable role to constitute a healthy work environment.