50 Shades of Agile

Last 15 years we all observe like agile methodology stormed the old-fashioned project management practice. Today Agile is almost treated as a legacy as this started new approaches to be developed.

With no doubt, Scrum is a winner, and I don’t know anybody, literally anybody, who has not touched it from the project management community.

This opened a door to many other methodologies like LeSS for large scale projects - development but also KanBan as one of an agile methodology.

Originally KanBan comes from manufacturing, which helped to provide visibility and quality control in the automotive industry. But it quickly found its way in other disciplines, where the specific repetitive process is used on projects.

I had the pleasure to be the Program Manager of a program where KanBan was used, and it replaced many of the project management functions.  It had its price, but in the end, it was worth dropping old Gantt charts.
Let’s talk more details.

The Case

The project was part of a large digital transformation program. The customer (telco) was replacing almost all business functions with one suit.
It is quite painful and challenging. But consequences were all systems which were not to be replaced like a data warehouse, BI, … had to be changed as well.
The requirement was to have almost the same set of reporting and analytical capabilities as before, so the transformation change does not disrupt this part of the business.

As part of the scope, there were multiple hundreds of reports to be resurrected with new fresh data. After taught analytical work, the cleanup process left the project with fewer hundreds of reports, but still hundreds.

Introducing KanBan

For the reporting migration part, we had started with traditional planning based on business priorities and visualize it in the Gantt Chart. As planning was not trivial, but a doable task, after a few weeks our visibility where we are dropped dramatically. We simply could not make sense of the Gantt Chart anymore to represent where we are. During project run many reports migration and development got stuck on… Where are they got stuck?

We simply could not talk about each report where it got stuck. Each report had its own story. It was impossible to get a status. This was a moment we turned to KanBan. We used one of the known platforms to build the board. We did not have to change a team setup. Analysts were still analysts and developers and testers stayed at their roles. We chopped business groups for reports for different colors and each report as one ticket.
Voilà! The tickets start to move!

 

“We simply could not make sense of Gantt Chart anymore to represent where we are.

This was a moment we turned to KanBan"

How it Helped

The number one benefit was visibility. Assuming all are disciplined understanding what is stuck was a piece of cake. Each report on the board was simple where it was in reality. Because our rules were to push the ticket (in most cases) - it was easy to make a discipline of updating the board.

Number two was board was self-running. In the Gantt chart to collect status, I had to go around and find the status. Sometimes true one, sometimes just promises. Then all information needs to be updated on Gantt. It is a monster job to be done every week. Almost no way to find the moment to understand real status.
With KanBan, every team member was updating status by itself. So, the Project Manager could finally focus on issues.

Thirdly reporting capabilities for status to customers. You can present a lot of different perspectives and focus on real issues. Moreover, the customer was part of the KanBan board, so status was available constantly.

What was Missing

We moved with progress immediately after we deployed KanBan. It was good. But of course, KanBan is not Wunderwaffe to manage projects. It has its price, also, literally. You miss schedule information. There is hard to answer the question when. It is not impossible by estimating the speed of tickets, but it is not as easy as in a Gantt.

The second component is the cost information. If You have a constant team - no issue, but on large projects, very little people have the comfort to have a constant team. Again, this can be monitored aside, but require some additional effort outside KanBan.

Perfect Projects

The above case worked with KanBan, but not all projects are suitable. What is a project You should think of KanBan?

Anything where the process is repeatable and in large elements (scope). DevOps projects are a great example. But also, migrations of report like the one I described. KanBan if set up properly is very simple and requires almost no introduction to team members but a 1-hour presentation. The benefit is also good reports from the board. Specifically, if You want to show it to the customer. As I have never seen a customer who enjoyed the Gantt Chart for status reporting.

 

Marek Rudnicki With over 25 years of experience in new technology companies specialized in professional service and consulting business solutions. Working for different industries like banking, insurance, telecom, e-commerce, manufacturing with a vast track of the delivery of data analytics solutions. The key experience is consulting and project delivery - from presale into program management and project portfolio management and practice/portfolio governance. Most of the career working within a multinational environment, managing team, and in a very distributed model organization.

 

Note and Disclaimer: The author of this Blog post is Marek Rudnicki. He is the guest author of PMI.hu. The writing reflects the author's own professional opinion, findings, and conclusions, which do not necessarily agree with the position of PMI Budapest, Hungarian Chapter, and cannot be considered as an official recommendation, resolution, or opinion of PMI Budapest. The copyright and publication rights of the writing belong to the original author.