Communication & PM Tools (Agile vs Waterfall) | Project Management

This reflective journal is based on 2 broad topics – The importance of Communication (effective behaviour) and Different Project Management Tools (Agile vs Waterfall).

The following sections are divided in 3 sections – What? So What? Now What?

Project Management Tools – Agile, Waterfall, Scrum or Kanban?


Agile in my opinion was an amusing selling term for “Documentation doesn’t matter – don’t bother with paperwork, it takes valuable time away from the programmers”, and the place I previously worked in, they were happy to validate this concept for me.

Scrum felt like another marketing term to throw process where it wasn’t needed, but in action it felt very light.

So what and Now what? – So I looked into the different kinds of methods that most software development teams use:

Agile: Development usually follows exactly the same process as Waterfall except that it follows the process for just one or two features instead of doing each step for the entire product before proceeding to the next step.

Most developers don’t believe me when I say this, but they sort of get it when they stand back and think about it, and realize that continuous integration and deployment is automated QA / testing and “install” steps. The business advantage of this is that in 12 months ‘ time you don’t need to sit down and work out 500 features. All you need to do is find out what a couple of things you want on Friday.

Now, it sounds great, but it actually needs a little discipline. Small iterations like this often mean that it is possible to rush and incomplete the specification or design. The fact that the time limits are so tight means that a system is down or the work of a co-worker is not ready can lead to “blocking” of a developer. To bring order to the chaos, PM needed something more structured (relatively) – Scrum

Scrum: which is about a team coming together to “pass the parcel(bomb)” when problems occur and emphasises communication between the person in charge of the specification (product manager) the team and amongst team members. Features of the SCRUM process include:

  • A period of time in which a group of features will be developed called a Sprint
  • A sprint planning meeting to discuss the features for the next sprint and to estimate the time taken to produce them.
  • Daily scrum meetings where each team member discusses what they did yesterday, what they plan to do today and what they are blocked on (if anything)
  • At the end of the sprint, a review meeting where a discussion is had to figure out what went well, what didn’t and how to fix it. The method has an in-built process for self-improvement

SCRUM’s biggest complaint from developers is that it feels like meeting overload-the sprint planning meeting often takes several hours, once a week or fortnight. The review meeting normally takes at least 1-2 hours. The daily meetings are normally limited to 10-15 minutes, but they can feel disruptive.

The real danger though is that often a developer will get blocked on a feature and start work on something else until they’re unblocked and 90% of the time those features are still there at the end of the sprint unfinished. PM needed something to solve this issue – Kanban

Kanban: which is based on systems thinking and sees development as a production line. A developer is required to reduce Work-In-Progress (WIP), and so when they get blocked, other members from the team moves to unblock them as soon as possible. There is no sprint planning, simply a weekly (shortest) meeting to talk through priorities in most teams, and people in the process are responsible for pulling work off the pile and pulling it through and on to the next stage. The entire team is motivated to see a feature get through to being positioned and handy rather than leaving it to rot on the blocked pile.

Waterfall: the name given to the process where we exactly go through each step of development in order and wait until each step is complete before passing it onto the next stage. Those stages are:

  • Specification – Data collection – What do we want the software to do?
  • Design – User interface user experience in software’s – How do we want to do it?
  • Development – The process of taking the specification and design documents and turning it into running software
  • Integration – making this piece of software talk to everything else it needs to talk to (other software, hardware, etc.)
  • QA/Testing & debugging – Checking that the finished software product conforms to the specification and design documents, and fixing bits of the software when it doesn’t
  • Installation – Delivery to the customer
  • Maintenance – Dealing with ongoing customer support issues

This model cascades the product down, hence the name. It is inspired by the construction industry and borrows a great deal from the manufacturing industry.

Communication Management


It is said that one out of five projects are unsuccessful due to ineffective communications

I strongly believe that communication leads to relationship building, which is of the most important aspects of PM. It be a client or members of the team – communication is the grease between the wheels in a project. Which gets us to the question of how should a PM communicate. Lets assume for a minute that by communication we are talking about motivating the team to move forward. The way a person communicates (motivates) is obviously something that is inculcated from the type of leader they are, and therefore both these characteristics go hand in hand (the articles throws light upon how different leadership theories leads to different communication techniques). For instance, certain leaders believe in reprimanding their team versus some believe that instead of calling them out, they should encourage them to move forward.

The following paragraph is referred from (It’s a great article to understand obstacles in communication)

So What?

A lapse in communication can happen at multiple places in the chain:

  • Between organizations (e.g., customer-supplier);
  • Between departments within an organization (e.g., marketing-IT);
  • Between teams within a department (e.g., testers-developers); and
  • Within distributed teams (e.g., part of the team is in Seattle and the other in Mumbai).

We took the example of motivation in the previous paragraph, let’s now have a look at communicating ‘technicalities’. Open question to anyone reading this – Do you think it is important to explain what you have understood in the easiest and simplest of the words to the other stakeholders? This is not rhetoric at all – I have at some times in my career felt that it is necessary to withhold information even if it can be communicated easily.

Now What?

Here are some ways that are effective ways that Project Managers can streamline things:

  1. Get a date when you ask people to do something. If they do this in a meeting, it’s better, so they’ve committed to their peers.
  2. Confirm that people really know what to do. You might have said it a billion times, put it on paper, published it in the project plan, etc., but people still misunderstand and forget.
  3. Look out for people who are no longer involved in your plan. Maybe they stop attending your meeting. Or they stop providing status. Get them on a call. Set up a 1-on-1 meeting with them and figure out what’s going on. Be insistent but don’t blame or condemn. Instead, be honest about your apprehension and ask if they’re blocked, need help, or are overloaded, etc.
  4. Always think about how you can support people. This might be removing an obstacle or dependency to a task that you’ve asked them to do. Ask them how you can help them. Even “grunt” work like scrubbing bugs or editing documentation. Make it clear you are there to serve them. People will appreciate this and reciprocate.
  5. Publicly recognize people’s good work. Be grateful always for good work and express that gratitude publicly and frequently. Make it authentic and really feel it. Make sure manager’s and project sponsor’s hear this too. Say “thank you” for good work, delivered on time and note the positive impact it had on the project.
  6. Maintain a healthy level of paranoia and push. Be wary about the status of your project. Is there anything you can do to nudge things a little faster? If you’re feeling relaxed then trouble may already be brewing. Go talk to people you haven’t talked to in a while.
  7. Under-promise and over-deliver. This is perhaps the most important, and difficult, because it involves scope management, planning and stakeholder management. Any project can be seen as a success or failure depending on stakeholder’s expectations. However, if you’re too conservative people will question your planning and accuse you of not being forceful enough. Being aggressive with scheduling can also create some urgency with your team so people don’t feel too relaxed. Seek to achieve a balance between conservative and aggressive planning.


Serrador, P & Pinto, Jk (2015) Does Agile work? – A quantitative analysis of agile project success. International Journal Of Project Management. [Online] 33 (5), 1040–1051.

Cervone, H. Frank (2011) Understanding agile project management methods using Scrum. OCLC Systems & Services: International digital library perspectives. [Online] 27 (1), 18–22.

Azanha, Adrialdo et al. (2017) Agile project management with Scrum. International Journal of Managing Projects in Business. [Online] 10 (1), 121–142.—a-basic-introduction.pdf

Like this article?

Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on Linkdin
Share on pinterest
Share on Pinterest

Leave a comment