Table of Contents hide

1.2. CONS

2. AGILE

3. SCRUM

4. SCALED AGILE FRAMEWORK (SAFe)

5. LEAN

6. KANBAN

7. WHICH ONE TO CHOOSE?

8. ABOUT US

Just about perfect guide to IT Project Management

To most people, the term project management sounds very abstract and vague. Ironically, we are all doing some type of project management in our daily lives. Surprised? Every single task that you do during the day, every little step you take to finish your daily tasks, that is all some form of project management. Project management is all about the proper organization, distributing tasks and workflow so you can be as much time and cost-efficient as possible. The ultimate goal- well, to get a job done in the best possible way.

And although it sounds fairly simple, when it comes to business matters and delegating teams it becomes much more complex. Not to mention that there isn’t a universal one- fits- all system that you can just copy-paste on every task or project. I probably can’t stress enough how IMPORTANT and both money and time saving it is to have a trusted team of professional project managers, but hopefully, by the end of the article, it will become much clearer.

Since there is no universal system, many different methodologies have been developed over the course of time. Each of them has its advantages and disadvantages and depending on your company’s needs one works better than the other.

TRADITIONAL PROJECT MANAGEMENT

Traditional project management (TPM) is also referred to as ‘ the waterfall’ project management because it follows linear order. In other words, you can only get to the next phase or stage once you have completed the previous one. It is all about planning and breaking the project into smaller tasks which need to be finished before moving on to the next stage. And although you do have the freedom to break the project into the steps of your own choice, there are six specific stages: initiation, planning and design, execution, testing, monitoring and completion.

Initiation phase

As the name suggests, it is the phase where the team brainstorms about the product and requirements needed in order to get your product and project to the finish line.

Planning and design phase

I like to refer to this phase as some sort of a match-making phase because it is at this phase that you try to find the best design to meet the product requirements. They need to fit like a glove.

Execution and testing

This is where things really start heating up and when the previous phases are put to the test. A logical step to follow is naturally, testing. You need to see if there are any technical, design or whatever other sorts of problems or glitches that you’ll have to fix. Remember, you can’t move on until each stage is completed. So, everything that still needs to be fixed takes one step back to the execution phase until everything runs smoothly. And yes, you got it right, you might be getting back to the execution phase multiple times before moving to the next phase. As annoying as it may seem, it is crucial that everything is ironed out.

Monitoring and completion

It seems like the final phase, and it is, but it is the one that is never-ending in a way. Although your project/product has come to life, it still needs regular maintaining, updating, support and improvement.

Depending on the project, you might not need all of the phases, but you’d definitely need a good TPM tool. Since this methodology is heavily time-focused, what’s better than Gantt chart? For more info on PM tools, make sure to check our article on this topic-here we can provide a link if possible)

PROS

Nowadays many people frown upon anything related to tradition, thinking of it as something out-dated or old. And although that can very well be true in some cases, when it comes to the TPM, its ‘old’ values are actually the ones keeping it still alive and kicking. There is no way it would have been able to stand the test of time unless it has qualities. The biggest advantage of the TPM is its structure and organization. This is good in the following situations:

– There is a contract turn key and it’s for a short period of time.

– There are specific regulations (like Healthcare) with specific constraints that need to be set up before.

– There is an extensive and complete documentation on what has to be prepared.

– It is a project that involves IT in a minimal part overall but involves operational and functional departments. Everything is so thoroughly laid out, with enough time to test things properly to make sure the end result is the best. This reduces the amount of stress and mitigates the risk of a failed project.

CONS

Quite often we witness that the greatest strength can be the greatest weakness, too. You know, like two sides of the same medal. If we apply that to the TPM, it means that its rigidity can be its main enemy. Now, more than ever, we live in a society that constantly changes and at such a high rate that sometimes it is hard to keep up with everything. Thus, the problem of the TPM is its inability to be more flexible, to bend a bit, to be less rigid. Ideas usually look nice on paper, but in order to deliver a product that would meet those criteria that takes a lot of trial and error. In other words, the team needs to have that freedom to experiment and change things last minute without affecting the end-result. With the TPM, that is just not possible, because its structure is fixed and planned. Still, each methodology has its niche and the same is true for the TPM. If you have read our previous articles, you could’ve figured out by now that each methodology can be perfect depending on your needs.

Let’s continue our little walk down the methodologies lane. Next stop: Agile.

AGILE

Although Agile has been around since the 1950’s, it became popular in 2001 when Agile Manifesto was published. It provided something that the TPM was lacking: flexibility and ability to change ( hence the name agile). Agile or iterative approach delivers work in small increments, with the emphasis on collaboration between the teams. Unlike the TPM, each phase doesn’t have to finish for the other to start. You work on each step, task individually, test them, connect all dots and get a big picture. These small individual steps allow sudden changes and adaptations which are inevitable to happen.

PROS

It is exactly this flexibility that represents the greatest advantage of Agile and it is the reason why so many other methodologies use it as the framework. You can pretty much shape it into any form you want. It is suitable for open-ended projects.

CONS

By now, you are probably not at all surprised that Agile’s greatest advantage would be its greatest disadvantage. Yes, I am talking about flexibility. You probably know it from real life, too. Sometimes when you get all the freedom you want and a clear path to do whatever you want, it is then when you feel most lost, not knowing what to do. One might argue that it is a part of human nature that needs to be guided or at least to have some kind of guidelines. When we apply this to Agile, it means that being so flexible can make it more easily to lose direction. It makes it harder to see exactly how the project is going. To put it simply, you can easily lose your focus so it is a must to make sure teams are communicating all the time.

And once again, if Agile isn’t your thing, luckily for you, we have some more methodologies up our sleeve. The next one on the agenda is Scrum.

SCRUM

As expected, Scrum combines some features of the TPM and Agile project management and provides an organized, and yet flexible structure. It was first introduced in 1986 and the term is borrowed from rugby, believe it or not, where it refers to the formation of players. You can safely conclude that one of the main features of Scrum is the importance of teamwork. In other words, the team works as one. Same as in Agile,tasks in Scrum are also divided into smaller ones that are independent of each other in terms of completion. Furthermore, each task gets a sprint- allocated time during which task should be shipped. Sprints can last from two weeks up to a month, but most commonly two weeks. You can have daily sprints too, where you ship just a certain phase of the project. Precisely this ‘obsession’ with time links Scrum to the TPM and provides more structure. An interesting thing about Scrum is that it starts from the premise that we can’t fully anticipate the level of change that will inevitably occur and that it is most likely that a client will change their minds about their needs during the process. As such, you can’t have already made plans and strategies. This is where teamwork steps in. Since you can’t fully predict how things will develop, instead of focusing on things you technically can’t control, teams focus on quick delivery and fast adaptation to ever-changing circumstances and market conditions. In order to maximize efficient delivery, the responsibilities are divided into three roles: the Product Owner (PO), the Scrum Master, and the Team. These roles optimize communication between team members.

The PO is a spokesperson for the client. They make sure that client’s needs and wishes are clearly expressed. This person needs to have a broad picture because they link the development teams and stakeholders. Their task is not to suggest a technical solution but rather to communicate what the business needs, ask why they need it and convey the message to all stakeholders.
The Scrum Master is not a traditional team lead or project manager but acts as a buffer between the team and any distracting influences. The scrum master ensures that the Scrum framework is followed. They encourage the team to improve. What sets the Scrum Master from a traditional Project Management is that they don’t manage people, or in other words, they provide very limited guidance because it is expected from the team to be self-organized.
The Team– we’ve already mentioned that the team is in a way the basis of the Scrum methodology. It functions as a unit that carries out all the tasks. Unlike in more traditional approaches, the team is self-organized and even encouraged to directly communicate with clients and stakeholders in order to better understand the pains and get valuable feedback.

What also sets Scrum apart from its siblings is the number of meetings. Scrum consists of five types of meetings: Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.

Backlog Refinement or grooming is the ongoing process of reviewing product backlog items, checking that they are appropriately prepared and ordered , so the PO can decide where the focus would be and how tasks should be prioritized. Needles to say, this would ultimately define the efficiency of sprints.
Sprint Planning logically follows the previous meeting. When the PO decides where the focus would be, the team gets a clearer picture of what they need to build and why.

Daily Scrum Meetings are simple day meetings that shouldn’t last for more than 15 minutes. They are also called stand-ups. The main purpose of these meetings is for the team to update each other on the progress.

At the end of a sprint, the team holds two events: the sprint review and the sprint retrospective.

Sprint Review- Since it is desirable that you have a shippable product at the end of each sprint, the review is extremely important because it gives an opportunity for team members to present their work to the stakeholders and to see to what extent the needs are met.

Sprint Retrospective takes place after the sprint review and it provides the space for much needed feedback. It is here where the team discusses what went well, what things they still need to work on or improve, and ultimately, what things need to come to an end.

PROS

Scrum is suitable for projects where the delivery needs to happen quickly. Moreover, Scrum helps the team adapt to sudden changes. By doing things in smaller increments and constantly testing them, it is much easier to realize where the problem lies and fix it in almost no time. And although the sheer amount of meetings and delegating tasks can seem a bit daunting and even overwhelming at first, it comes in handy when you have inexperienced people in the team who still don’t fully understand the projects or the tasks. Here, it is ok because there is always someone who takes care of the entire project.

CONS

Yes, you probably know what’s coming next. The vast amount of meetings and sprints can also be a disadvantage. Some people find it truly stressful because they have the feeling that the accent is more on planning sprints than on actual work. It also becomes more complicated to prepare budgets and plans, to estimate an overall project if there are many functions, and finally, to integrate a project scrum that has other departments not working on Agile. Another minus according to some is that the need for such a quick delivery can perhaps kill off some ideas that would have flourished given enough time. Last, but not the least, some people believe that the shipping doesn’t need to happen that often.

We are somewhere half through our article and so far we have discussed the TPM, Agile and Scrum. The following pages will reveal another three methodologies: Scaled Agile, Lean and Kanban.

SCALED AGILE FRAMEWORK (SAFe)

I like to refer to it as a baby of the family, considering its tender age of 9, with the latest edition being published in January this year. But be not mistaken by its young age. SAFe has a lot of things to offer and according to the statistics it is one of the most popular and common PM approaches nowadays.

Let’s see if it is well deserved. The SAFe is designed not so much as a single methodology, but as a big knowledge base of proven best practices that teams have used to deliver successful software products. In a nutshell, the knowledge base consists of proven, integrated principles and practices to help enterprise agility. It is an ongoing process because new things and practises are being added as we speak.

The Scaled Agile Framework is based upon ten principles meant to improve the company as a whole by inspiring lean-agile decision making across functional and organizational boundaries. These principles are derived from existing lean and agile ones, and they are intended to influence the decisions of not just leaders and managers, but of everyone in the organization. We won’t go too deep into these principles here, that is a topic on its own, but if you do feel like reading more about the SAFe, feel free to read our last week’s article about it -here the link).

The 10 principles are:

Take an economic view
Apply systems thinking
Assume variability; preserve options
Build incrementally with fast integrated learning cycles
Base milestones on an objective evaluation of working systems
Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths
Apply cadence (timing), synchronize with cross-domain planning
Unlock the intrinsic motivation of knowledge workers
Decentralize decision-making
Organize around value

Core principles aren’t the only core of the SAFe. It also has a set of core values. Same as values in everyday life refer to the things we need to have or work on, the values in the SAFe imply the same. They are improving the work culture while pointing out hope people should behave within that culture and be more efficient. And naturally, these core values are intertwined with the principles.

PROS

The SAFe is definitely suited for companies with a great number of teams, it makes projects more transparent, it helps cross-functional teams communicate better because it requires a high level of coordination and alignment across teams and management levels which increase work dependency. It enables the people involved to see the big picture.

CONS

On the downside, some believe the framework is not pure agile, because it requires too much upfront planning and process definition. Furthermore, it has more of a top-down approach to decision making rather than a team-based approach which can undermine some of the core agile principles—such as collective ownership, adaptiveness, and less fixed roles. This disadvantage led to the SAF-e being criticized as hierarchical and inflexible in a way.

As you can see, regardless which approach we are tackling, the biggest pain points so far seem to be inflexibility and rigidity.

LEAN

Before moving on let’s just have a quick recap. In a nutshell, apart from the TPM, all other approaches or methodologies sprang from Agile one way or the other. Same as Agile, they all try to break the project into smaller chunks. They differ in many things and one of them being management of each part of the project.

Agile is all about shippable parts, Scrum is about solving the management issues with loads of meetings, the SAFe goes along the lines that a lot of heads work better than one and now comes Lean. It also heavily relies on Agile but of course, it brings the features that don’t exist in Agile. That missing link is workflow processes. The focus is on steady and unchanged quality, that each portion of your project is shipped with the same quality. The lean approach aims at reducing everything else which does not add value.

The Lean methodology relies on 3 very simple ideas:

deliver value from your customer’s perspective
eliminate waste (things that don’t bring value to the end product)
continuous improvement

It also lays on five principles.

PROS

What makes Lean so great is its flexibility and focus on the quality of each stage. Moreover, it encourages shared responsibility and leadership. Lean beliefs in people behind the project. It believes that everybody in the project hierarchy can contribute and provide useful ideas or feedback. It also tries to shorten product development cycles and rapidly discover if a given business concept is viable ( eliminating waste). When the team is focused on delivering value, they will be more productive and efficient.

CONS

Remember the delivering equal quality that we mentioned as one of the unique traits of Lean? Yes, yes, you are right, it is one of its weak links too. Lean treats everything the same, every step, every portion of the project, and in reality, and in practice, not all the steps are equally important for the completion of a project. That doesn’t mean that you shouldn’t pay attention to them, but they don’t all need the same level of attention so to say. Considering that one of the focuses of Lean is the continuous improvement, it might not always be clear if the project is really finished or not.

And last, but not least is:

KANBAN

At first glance, Kanban might look the most chaotic out of the above-described approaches. If you wonder why, the reason is simple: you can leave tasks of the project at various stages until they are needed. That spells trouble and might give you the impression that things aren’t going according to the plan. But, the reality is different. The two primary practices of Kanban are to visualize your work and limit work in progress (WIP). Kanban manages workflow directly on the Kanban board. The WIP limits for development steps provide development teams immediate feedback on common workflow issues.

Kanban boards, designed for the context in which they are used, vary considerably. The aim is to make the general workflow and the progress of individual items clear to participants and stakeholders. While physical boards are popular among some teams, virtual boards are a must in any agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.

Kanban requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every part of the project at any time. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Kanban can be as flexible as you want it to be but it has four principles to help the shipping of the project:

Cards: Each task has a card that includes all relevant info about it; It is a sort of a reminder where the most important info are all in one place
Cap on work in progress: Limit how many cards are in play at once; this prevents teams from over-committing
Continuous Flow: No rest for the wicked. You organize the list of backlogs in order of importance and make sure there isn’t an idle moment but that something is always worked on
Constant improvement: Analyzing the workflow to see how efficient your work is, what needs to be improved or changed.

PROS

Kanban is definitely very well suited for teams that don’t need that much management and are self-motivated. By assigning only the required amount of work to your team, Kanban helps in reducing the stress over the deadlines and it makes the team more focused. It is more relaxed than Scrum, there isn’t such a high demand for sprints, and there isn’t work overload.

CONS

If, however, you do have a project that you must ship before a certain deadline, the laid back Kanban approach might not be the right fit. Also, taking into account that the teams using Kanban should be quite independent so to say, it might not be the best solution for teams that need more structure and guidance, and for teams where team members don’t have overlapping skills.

If you weren’t familiar with these approaches before reading this article, it can be mind-boggling to put all the things into perspective. That’s why we are going to make a table for you with all the key features for every approach.

WHICH ONE TO CHOOSE?

As it has been mentioned quite often in this article, and our previous project management articles, there is really not a definite nor the right answer to this question. This just about perfect guide is exactly what the name suggests- a guide so you can get the basics and see the comparison between these methodologies. Each of them shares some similarity with the others, but each of them has its own specific traits that make it unique. Software development teams, in general, tend to fall for agile practices because they acquire basic principles relatively quickly. If you are lucky enough, you’ll be able to immediately find your perfect approach. But as it turns out more often, you need to try and combine many approaches before you find that perfect one for your type of company. The crucial thing is to just use any approach because it will provide some form of structure and then over the course of time, you can know better what your company needs.

Or you can hire a team of experienced project managers who will help you organize projects and provide more structure and growth to your business, so you can do what you are an expert at, while the PM experts are doing what they are specialized for. At the end of that day, it is as simple as that.

ABOUT US

Let’s start with Luciano Castro, founder of the company. Luciano is a business-driven manager with over 15 years of experience as a CTO and CEO in multinational companies and startups. He has a strong technical background in IT and excellent management skills and is in love with Agile and Lean methodologies:

15 Years of experience

8 Certifications

11 Books published

But, there is no I in the word Team, so Luciano isn’t the only person you get when you choose us.

You will get a team of seasoned Project and Product Managers specialized in Scrum, Waterfall, Design Thinking, and Lean. We have more than 2000 projects under our belt both with small and big teams. We also possess multiple certifications in PMP, Agile, Scrum, ITSQB, ITIL, and Microsoft. These numbers are impressive but we wouldn’t have been able to do it successfully without being dedicated, passionate, and working hard to provide the methodology and approach that suit you best. We will manage every stage of your product’s journey and organize your tasks and projects by phases and priorities.

Our team will be there to continually track every step of the process and help your business grow even more.