Working on projects with Scrum and Kanban: which to choose from both

First of all, determining the selection of the most correct method is the nature of the assigned task – creating a console application that we will install in hardware.

In other words, you need to create software with a good and easy-to-use user interface that can be seamlessly integrated into the device. This type of task requires a creative approach from team members and, given the less detailed specifications, is likely to be refined as an idea in the course of the work.

Our customers often subsequently want to add additional functionalities, often change their requirements for some initially sought-after product qualities, and there are many cases when our experienced senior experts make particularly successful proposals to improve/change the product, which is met by the client with enthusiasm.

This experience so far shows us how important it is to be flexible, fast, and resourceful. Unfortunately, the latter would be impossible if we use the waterfall method.

Although suitable for products with clearer specifications, relatively well-defined characteristics, and a sufficient amount of binding documentation, waterfall often creates problems even in these situations.

When the original idea proves inapplicable or ineffective, we harness all our creative potential again to solve the problem and leave our customers satisfied.

In this sense, I strongly believe that the scrum method in this case is the most appropriate for the whole project. It will provide us with creative freedom, better communication, the opportunity for adapted product improvement, and certainly faster results.

In addition, the project meets all the basic requirements for the application of scrum – a relatively complex product that must be created in a complex and changing environment; changes are expected in the course of product development; the need for close collaboration of cross-functional specialists, who form relatively independent teams working on different components of one product.

It is paying considerable attention to the latest specifics, I offer a specific variation of Scrum, which in my opinion is extremely suitable for our project: “multi-team Scrum”. [Reference]

By applying the above method, we will provide all three teams with the necessary independence, but at the same time the invaluable opportunity to be part of one team, as their work is subordinated to a common goal – creating a single product. Therefore, they will have only one product owner common to all teams and one Scrum Master.

The first will communicate with the client and will be responsible for the strategic and priority management of the project. The Scrum Master will also have a huge and very important role – to provide continuous assistance to teams in mastering the “scrum mindset”, and in particular – self-organization, discipline, and close communication/coordination not only within the team but also especially between teams.

In this case, it will be good practice to hold the so-called sprint in the middle of each sprint. sprint backlog refinement meetings that facilitate coordination between teams to validate, prioritize, and contribute to effective work planning for future Scrum sprints. [More on the topic]

These meetings are important because in this case, the work of the teams is, on the one hand, relatively independent (everyone has their part of the project), but at the same time, all three teams are dependent on each other.

The more timely, early, and fast the coordination and exchange of information between them, the more unified the final product will be.

Otherwise, it would lead to a ready-made console application with a tried and tested user interface, but technically incompatible with the hardware device, for example.

Timely clarifications between the teams will eliminate discrepancies at a later stage.

That is why we avoid the waterfall method. As I mentioned above, if the product was described in more detail in the written documentation, if there were specifically set parameters that are not subject to change under contract, and along with all this was simpler, I would no doubt recommend waterfall. However, this is not the case.

In summary, the scrum methodology should be applied to each of the teams, primarily due to the complex nature of the software product; the possibility to change aspects of it in the course of the work, and the dependence between the individual teams, which is present until its completion.

Only the scrum method can meet all these challenges at once. However, it is worth noting that its application does not preclude the parallel use of Kanban.

On the contrary, especially when it comes to Team 1 and Team 3, where there are experienced professionals with many years of experience, we could also integrate Kanban. Reference: “Waterfall vs V-Model vs Scrum vs Kanban

If the teams are doing well, in the future we can consider whether they would not do well on some projects and only through Kanban. The latter would only be useful if we have enough evidence that their members are disciplined and self-organized. In this direction, we can consult with the leaders of their teams.

For the sake of completeness of the analysis and to illustrate how I concluded the most appropriate method for each team, in the following lines I will consider separately the characteristics of each.

Team 1 – Maybe this is the team for which the application of scrum is the easiest to justify. Software development is rarely fully and pre-defined. Usually, if the software is not very simple, it requires adaptation in the course of the project and improvement.

The selection of the agile method gives us preliminary freedom and peace of mind that we will react flexibly. The only ones in our practice were the blank and simple software tasks, which require us to be performers rather than creatively oriented “authors” of the product.

I even think that a step forward in the future, namely using a method like Kanban, would be a well-deserved compliment to our senior experts with proven experience, independence, and discipline.

Team 2 – The creators of the graphical user interface also face a lot of challenges and have to react quickly to changes in product functionality.

They work closely with Team 1 and need to be quite open to communication and adaptable. It is very rare to be given an almost complete product with complete and clear documentation.

In these cases, even beginners in the team with minimal supervision can perform the task according to the old waterfall method. However, this is not the case here.

Team 3 – Here, compared to the other teams, perhaps we could most boldly apply the waterfall method without any problems.

With a ready-made product (a console application with a good user interface), we could follow a sequence of pre-defined steps known to us from previous experience.

These are the cases where the first team presents to the third application-programming interface, for example. Then they strictly follow the instructions given to them.

Such projects in our company are rare, on the one hand, and on the other – such an approach blocks our ability to use the potential of our talented senior experts, who have repeatedly developed new functionality based on the provided application programming interface (API).

However, the latter will not be possible if we apply only the waterfall method and follow the known procedures.

If we implement scrum, we could give our team the freedom to make adequate planning, agreed in advance with the client, act flexibly and adaptively during the work cycles, and present a satisfactory end product.

This is what I think is the goal of this project. Moreover, our company is distinguished by its innovative and creative approach, which we can establish and develop precisely by applying scrum to the growing challenges facing our demanding but loyal customers.

Leave a Reply

Your email address will not be published.


Become a CERTIFIED Project Manager

Online Exam: $280 $130 Get a FREE Mock Exam