Agile for Traditional Projects

By Susan Parente | Risk Management Guru – Agile Generalist – Instructor and Consultant, IIL

“Can Agile practices be incorporated with traditional project management?” This is a very common question today, and the answer is yes!

In this blog, I’ll cover two great Agile practices that teams have found to be valuable to incorporate on traditional projects, and which may help your team make the shift from traditional to Agile project management: A Daily Stand-up meeting and a Kanban board.

The daily stand-up meeting

The daily stand-up is used in Scrum, one of the most popular frameworks for implementing Agile. In this meeting, the project team members answer the following three questions:

  1. “What have I completed since yesterday that supports the iteration goal?”
  2. “What do I plan to complete today to support the iteration goal?”
  3. And lastly, “What are the barriers or impediments that are getting in my way in completing the work I have to do to support the iteration goal?”

This truly is a stand-up meeting, where all participants are standing. The meeting is time-boxed which means that it must end at the allocated time, generally 15 minutes. This forces people to prioritize what they talk about and to make sure they are efficient with the use of meeting time. (If you decide to have a daily stand-up meeting and let it run over 15 minutes, you’re not actually doing the practice of a daily stand-up, as it is a time-boxed event).

What you will likely find is in the first few daily stand-up meetings, not everyone will have an opportunity to speak; however, after a few meetings, people will figure out how to be succinct so that everyone has an opportunity to speak. It’s important for the Project Manager (PM), team lead, or facilitator in a traditional project to allow the team to work through this, as it is a part of the process of team development.

It is also important for the PM to take the lead and provide meeting support, but only to remind team members to focus on the three questions they need to answer (as noted above) and remind them if they’re getting off-topic with doing so.

Keep in mind that the purpose of the daily stand-up meeting is for the team to provide status to all team members, not to report to the project manager or the customer. Of course, it is valuable for the project manager to attend this meeting as the team facilitator; however, their role is more focused on listening and enforcing process than leading the team.

The Kanban board

A project Kanban board, or task board, is used by agile team members to work through project tasks. The project sponsor need not know that you are using an Agile method, and neither do your team members. In some organizations, it can be worrisome to customers and team members to use ‘Agile’ if they don’t know much about it. It can be an intimidating change. Using the Kanban board has been very effective for teams that I have coached or led because the teams had multiple tasks that changed every week. It is an easier way to manage these tasks and to make sure they get completed in a prioritized order while being able to track who is working on which tasks.

As designed, a Kanban board minimizes the project work-in-process and allows the team to complete all of the project work, not knowing necessarily how long each task would take. As each task is completed, the team member who completed it updates the board and assigns themselves to the next prioritized task.

Other Agile practices that teams have found to be valuable to incorporate for traditional projects include:

  • Information radiators
  • War rooms (collocation of the team)
  • Team retrospectives
  • Burndown charts
  • Relative sizing/estimating
  • And others

What is nice about incorporating Agile practices while doing traditional project management is that you may receive some benefit from using these practices while your organization may not be ready for an Agile project management approach. As a PM, you probably have some authority as to how your development team works and are able to use some of these tools even without agreement from senior management, or from your customer.

By incorporating Agile practices into traditional project management, you can reap the benefits of these practices and also, in the meantime, educate your team and your customer on Agile practices so they are more comfortable with using them. 

Related Courses from IIL:

Courses can be tailored to meet your organization’s needs. Request a free consultation


Susan Parente (PMP, PMI-RMP, PMI-ACP, PSM I, CSM, CSPO, CISSP, CRISC, RESILIA, ITIL, MS Eng. Mgmt.) is an instructor and consultant at IIL, an Adjunct Professor at the University of Virginia, Post University (CT), and Montclair State University (NJ). She is an author, mentor and teacher focused on risk management, traditional and Agile project management. Her experience is augmented by her Masters in Engineering Management with a focus in Marketing of Technology, from George Washington University (DC), along with a number of professional certifications. Ms. Parente has 18+ years’ experience leading software and business development projects in the private and public sectors, including a decade of experience implementing IT projects for the DoD.

Agile, Scrum, and Kanban: What the Heck Do These Words Really Mean?


If you want to be the smartass of the crowd, you should use the word “agile” in every other sentence when you are talking about the work process. It has a pretty wide range, does not obligate you to know much about the subject you are talking about, and it is a really nice adjective or adverb: “thinking agile,” “agile approach,” “according to agile principles.” But what does “agile” really mean?

“Agile” refers to “agile software development,” the approach to development that follows agile principles. But what the heck are “agile principles?” Take a look at the Agile Manifesto and at the 12 principles of agile, which lay the foundations of agile development. From the Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Agile principles encourage continuous delivery of functioning software, close communication among teams, and high adaptability to changing needs. If you follow these values and principles in your work, you can say that you are working in an agile environment. So, agile software development is not a methodology, it is just a set of different methodologies, frameworks, and techniques that follow the same principles. It can be said that “agile” is a framework for thinking and making decisions.

Agile is a framework for thinking and making decisions.

But why is it so important to follow these principles in our work?

The Manifesto and principles are the result of searching for the best solutions that have evolved over the decades in response to the challenges of software development. Throughout the 70s, 80s, and 90s, different developers and teams all over the world had been experimenting with methods of working and approaches to problem solving, inventing different frameworks and techniques (such as scrum and Extreme Programming), and even coming to the same ideas in parallel. Finally, in February 2001, seventeen developers got together and found the common denominators for all these diverse ideas and experiences. That is how the manifesto was created.

The Agile Manifesto is the result of different experiences and practical solutions that emerged over the decades.


If you talk about “agile” methods without knowing what they mean, you may slip up and say things that will uncover you in front of the interlocutor who knows the subject: “Scrum and other agile methodologies.”

Scrum is not a methodology, though we’ve all heard it called such more often than the number of killings inGame of Thrones. Scrum won’t give an answer to every question, and it won’t provide you with the precise procedure for responding to every situation you face. And probably as a result of this incorrect interpretation, most scrum implementations are also wrong: Teams don’t get value. This results in probably the most foolish statement about scrum: “Scrum doesn’t work.”

What is scrum? The Scrum Guide defines scrum as:

“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
So it’s a framework, and like any other framework it can be, and regularly is, used the wrong way. Using scrum effectively requires not merely adopting the structure set out by scrum, but having a deep understanding and appreciation for agile principles across the entire team.

Scrum consists of three roles: Product Owner, Scrum Master, and Development Team; four ceremonies:Planning Meeting, Daily Scrum, Sprint Review, and Sprint Retrospective; and three artifacts: Product Backlog, Sprint Backlog, and Product Increment. It is organized into regular time frames, which we callsprints. Sprints should last between one and four weeks.

The Product Owner, or PO, is responsible for guiding the project’s direction. As new tasks and features are determined, the PO adds them to the Product Backlog. A sprint starts with a Planning Meeting where theDevelopment Team selects the tasks from the Product Backlog to work on and plans how they will be implemented. That is followed by development, during which the Dev Team uses the Sprint Backlog to track progress and meets for the Daily Scrum in order to synchronize activities and adjust the plan, if needed. The result of development should be a Product Increment, something that can be applied to the product and released immediately. At the end of the sprint, the Product Increment is presented to the Product Owner at the Sprint Review, where the product backlog is augmented if further changes are needed. Afterwards, the whole team attends the Sprint Retrospective (also known as the Pub Meeting) where they talk about the work process and how it can be improved.

The basic Scrum framework.

That’s it in a few sentences, but if you need a detailed explanation of how scrum works, check out this article written by yours truly.

It is easy to learn and understand scrum, but it’s hard to adopt. There are many reasons this framework may or may not be a good fit for a project. It often requires a lot of changes, not only in everyday development, but also culturally. Scrum fits best with development of complex products, ones that last a long time and that include different kinds of specialists.

Why is scrum so popular, and why does it have an advantage over the traditional waterfall model? Simply put, because it delivers more value to a product and customers. With “heavyweight” methods such as waterfall, horror stories abound in which nobody sees anything of the project for months. With scrum, that is not possible.

Scrum is all about the value that is delivered to end users. If you really utilize scrum, you need to deliver something of value every sprint. The value can be measured, and the team is also forced to inspect impediments and adapt, with the goal of delivering more value in the next iteration.

In most software development we are not building a skyscraper; we don’t need to have the whole plan ready before we start, and stick to that plan until the end. We are developing software, and we have the ability to adapt to different situations and to change the product requirements during development. For a long time, many developers saw this as the eighth deadly sin, but from the product perspective it is a huge benefit for optimizing predictability and controlling risk. Scrum is developed around this ability, and its implementation gives a reliable and efficient way of dealing with necessary changes.

Many techniques are used in conjunction with scrum: planning poker, pair programming, test-driven development (TDD), behavior-driven development (BDD), and others. They are not really a part of scrum, but rather compatible techniques. One method often mentioned at the same time as scrum is kanban, and there is a lot of confusion about what these two things mean in relationship to each other.


When you talk about scrum and kanban, one frequently asked question from the crowd will be, “Which is better, scrum or kanban?” And you won’t know what to answer because it’s like comparing apples and oranges, or asking, “Which is better, pancakes or beer?” Both are better.

Kanban is a simple method that aims for just-in-time delivery while not overloading the team members. It is similar to scrum in that the goal is to deliver maximum value at the end, but it is much more flexible than scrum.

Kanban was not invented by the software development community. In fact, it has its origins in manufacturing processes at Toyota, and it has wide usage in other spheres. There are no strict procedures that you should follow, and no strict way you should implement and use kanban; it is, rather, a set of principles and practices, and you can choose from these practices to suit your needs. But there is one most-often used implementation of kanban in software development that includes the usage of a kanban board, consisting of columns representing stages of work, and tasks.

Columns represent the state of a task in the development process. The simplest example consists of three columns: “To Do,” “In Progress,” and “Done.” So, tasks are added to “To Do,” moved to “In Progress” when development starts, and considered “Done” when moved to the last column. But of course, it could be more complex:

“Backlog” → “Defining Specification” → “Ready for Development” → “Development” → “Code Review” → “Testing” → “Deployed” (→ “No one really uses it” → “Completely Removed”).

Every column can have subcolumns; for example, “Development” can be divided into “Planning” and “Coding”; “Testing” can be divided into “Unit Testing” and “Integration Testing,” and so on. Columns might be dedicated to specialists, if appropriate. The team defines the columns and stages according to its needs. Per the “pull” philosophy, tasks should only enter the workflow when the demand for them is immediate.

Kanban boards help visualize the workflow.

The purpose of this board is to visualize the workflow, which is the first key practice in kanban. In fact, kanban can be done without a board at all! It could be a simple list of tasks in a Google sheet with different background colors indicating the state of the task, or it can be Gantt charts, diagrams, tables… It could even be a set of buckets in your office, where each one represents the state of the task, and where balls are used as tasks. Just visualise the workflow and provide transparency to the whole process.

Another important principle is to reduce the batch size of your efforts. Simplified, this means avoid multitasking. That can mean reducing the volume of tasks you work on at the same time. If you have three designers in a team, the team might set the maximum number of tasks in the “Designing” column to three.

Like scrum, kanban also sees the team as the most important figure in the process. But it doesn’t suggest roles as scrum does, and you may keep the existing roles to avoid making changes to your existing process. The same stands for continuous improvement: Kanban generally encourages you to learn and improve continuously, but does not prescribe a specific event just for that process, as does scrum’s Sprint Retrospective.

Which Should I Use?

Scrum and kanban are not mutually exclusive and not really comparable. In scrum, there are defined roles, while kanban says, “What the hell, keep your current roles and responsibilities.” Scrum will force you to change your way of working; kanban lets you start with your existing process. In scrum, a clear schedule for events is prescribed by the framework; in kanban you don’t have events. Yet, they have a lot of similarities: Both are value-centric, team members are respected as “bosses” of the system, and essentially, they have the same mission: To continuously eliminate waste and remove obstacles.

But the question, “What should I use in my particular project and with my particular team?” makes much more sense. Kanban doesn’t require so much of the process and cultural changes, and, in most cases, it will be easier to adopt than scrum. Scrum, on the other hand, offers significantly more structure to guide the process, which can eliminate a great deal of overhead as long as everyone is on the same page.

But the beauty of both is that neither is a strict set of rules. There is nothing stopping you from picking and choosing the best scrum elements for you, such as a daily meeting or review. And there is no reason you cannot incorporate a kanban board into scrum.

Scrum has proven to be a highly effective framework when the whole team understands it well. However, in my experience, I find it hard to work in scrum with some clients. The process and cultural changes required for proper scrum implementation can be too much (especially when dealing with someone who believes that he is making a new Google!). On the other hand, kanban is more flexible and doesn’t force people to change. Some authors also say that kanban is a good path to agility, and offers easier implementation of scrum. Others say that using scrum should lead to kanban at the end.

The truth is that every project is different, and there is no one-size-fits-all solution. As a project manager, it is up to you to determine what works best for your team.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.