5 horror stories of agile project management

Halloween is upon us and yes, this is another spooky article leveraging this seasonal time of the year to talk about horror stories of agile project management that our colleagues have shared with us.

Do you dare to enter our haunted house? You’ll come across dead projects, zombie ships and vanishing team members. These stories will surely give you a fright. Are you brave enough to stay and read our heart-wrenching stories? If not, you can always use a shortcut and check how to stop having nightmares with our intuitive and easy-to-use tool for agile project management.

5 horror stories of agile project management

Horror Story #1: The mysterious vanishing of the Project Owner's assistants

The project was going so well that the client demanded more and more from us. We were so happy about that! On one hand, this allowed us to build more exciting and innovative stuff and, on the other hand, we were able to handle it well using our agile methodology. However, this extra demand had an impact on the Project Owner’s workload, who had to answer more questions, attend more meetings, provide us with more quality bandwidth, etc.

One day, the Project Owner showed up in a meeting and unexpectedly introduced us to his new assistant, who was meant to help him unblock some tasks. However, after only a few days, this assistant... never showed up again.

A few weeks later, he turned up with another assistant. This one, we were told, would stick around. But again, the assistant disappeared without a trace! Shortly after, two more assistants disappeared in strange circumstances...

These four assistants were never heard of again. And the tasks were never unblocked.

By Xavi Julián, frontend developer at Kaleidos

Horror Story #2: This project is dead…

We were so proud of our work! Everything had gone smoothly and the results of an 18-month project would benefit tons of civil servants. This would be a major leap towards a more modern public administration and a better citizenship engagement. It was more than that, though. It’d be considered a future-projects’ template —the ripple effects would be enormous!

On the last demo day, we awaited for final approval to start deploying the new software platform with the client’s help. After that call, our managing director came out of his office with a big smile on his face. “I have great news!” he announced. “I had a long conversation with the client and the project has been cancelled” he continued. Our heart rate skyrocketed but we managed to remain silent, eagerly waiting for the great-news part to be unveiled. “This is the definition of a perfect project...” he went on, unaware of our growing desperation “...we get paid, the project is finished but it doesn’t go into production, so we won’t get any bug reports or support requests!!! Come on, I’ll buy drinks for everyone!”. Silence.

By Pablo Ruiz Múzquiz, CEO at Kaleidos & Taiga

Nosferatu likes agile Nosferatu likes agile.

Horror Story #3: Soft fright (commitment) vs strong fright (commitment)

We had this great project a few years back. It was quite challenging because there was some uncertainty around its technical feasibility —pushing the limits of the web browser— but also because the concept itself was still tough to grasp. The founder talked and talked about his grand vision but many of us were unsure of what he really meant. “No problem”, we said, “we shall iterate in an Agile way: validating hypotheses as we go and reducing as much waste as possible through sprint demos and approvals.”

For months, this went really great. The technical challenges were sorted out and the client attended ALL sprint demos and gave positive feedback before saying “this is great, go on this way”. Until… one sprint demo past the project’s midpoint, we saw the client visibly anxious. He waited until the end of the sprint demo and then he said: “this is all great… but when am I going to get what I really need?”.

Our jaws dropped. “So-sorry? What do you me-mean? You have been validating and approving user stories for many sprints now, we thought we were on track!” “Oh”, he replied. “Yes, of course I was saying OK all this time, but I never thought it meant real commitment, I thought you were always asking if I had any issues with the work. I didn’t. It was a polite conversation and all that. But now I need to get what I really want. This has deviated too much for my liking now.”

Epilogue: after some conversations, this founder accepted our request for him to step down as Product Owner.

By Pablo Ruiz Múzquiz, CEO at Kaleidos & Taiga

Horror Story #4: The nightmare of a ‘full-equipped’ contract

Years ago, I worked for a product company, on a business and industrial management software. One of my colleagues and I were responsible for the app's adaptations of each user's workflow.

The parent company had a very effective salesman who managed to sign a quite big contract with an important manufacturer. The problem was that he forgot to define the scope of the work. The contract only specified that, for a fixed cost, we would "adapt the software to the company warehouse and production plant".

At first, things went well. We did quite a good work uploading their material catalogs, typing in their workflows and particular business rules, writing custom scripts and software modules... in just a few months we had a respectable MVP and the client was very happy.

But he kept asking for more. When we started talking about the work being finished at some point, he always said "your salesman sold me a 'full equipped' contract". He quoted those specific words. I'll never forget that sentence. Basically, he understood that we should go on until we implemented all of their work in the software.

Obviously, this was a bottomless pit. A company has an almost unlimited and ever changing set of workflows and tasks that may be managed by an ERP and CAM software. So we kept working with increasing tension. Eventually, the money that they paid us ran out, and we started working at a loss. So we began doing overtime and even overnight, while also working for other, more lucrative, clients.

Any attempt to negotiate with the client was unsuccessful. He kept using those damned words "fully equipped" to prevent any attempt from closing the contract and opening a new more reasonable support service.

At the end, our CEO himself traveled over there, and went through quite tiresome talks with him until he accepted renegotiating the contract. Finally, the situation was improved, and we had a successful work relationship for years.

That first year, though, will remain a top ranking nightmare in my professional career!

By Andrés Moya, software engineer at Kaleidos.

Horror Story #5: The bombing of the zombie pirate ship and the absurdity of allocating resources and budget.

Once upon a time there was a project proposal I was tasked with as part of my pre-sales responsibilities. Agile was in its early years and not well known yet. I laid out the major tasks as well as the number of people and how long those tasks should go on for. I was very proud of how I had managed to smartly overlap different stages, team members and allocated time until the head of department and the sales manager came around. They made some calculations and firmly disapproved. My plan was 300% above the client's budget and, what was worse, it was 400% above what our company wanted to offer as a discount.

They were happy with the project’s overall timing: a whole year. Everyone seemed to agree with the fact that this was a long project, but they needed to make cuts everywhere else. Soon I learned that you could have 34% of an engineer for two months and then do some testing for 9% of their time for a couple more weeks. Team members would pop up at random project milestones to add 13% here or 27.5% there. An Excel sheet based on rates, discounts, roles and times flourished and withered many times at the mercy of their fingers. I had this mind picture of designers lending 3 fingers, engineers contributing with the left leg and one eye. However, there was one resource allocation that remained solid and constant. In that Gruyere cheese of a planning, there was a 15% “Project Manager” allocated. “The client won’t believe a project plan with anything below 15% Project Management”, they sternly said, “it’s an industry standard”.

I was happy we didn’t win that project. It would have been the equivalent of setting sail to a bombarded ship full of zombie body parts led by a screaming head nailed to a mast.

By Pablo Ruiz Múzquiz, CEO at Kaleidos & Taiga

Pirateship gif

You've made it this far! Thanks for reading. Hope you found it interesting, inspiring and who knows... you might even want to give a try to Taiga is the easy-to-use agile tool that helps you manage your projects effectively. Go on! Sign up, it's free.

blog comments powered by Disqus