Have you ever experienced bad organisational decisions being made during software projects? For example, has the task to clean up important technical debt been postponed again? Has an unrealistic deadline been set? Are more people being added to a project in an attempt to complete it faster?
I don’t know about you; besides the common mistakes, I’ve seen some crazy decisions being made. Like when immediately after a new business application went live (v1.0), the responsibility was handed over to a maintenance team, and ALL the developers were re-assigned to other projects or contracts ended. No one was there to fix bugs or performance issues.
In some cases, bad decisions were even made democratically. E.g. one project consisted of a majority of businesspeople and a minority of techies. Despite all the techies recommending one path, the business decided to follow a different path. In this specific case, it didn't turn out well. At the end of the day, usually, the business pays for the project and has the final word.
How can we avoid or minimise such issues?
The goal of this session is to identify, discuss and rank the most common issues we have all experienced. Finally, we will give them memorable names and publish them in a public wiki — kind of like a living manifesto. By calling out bad decisions by name, it will hopefully prevent some of the common mistakes from happing and make all our lives easier (including the business side). For example, “Clean your hands before you operate” could mean “Fix critical technical debt before adding new features”. Anyone from the business side would understand the first statement.
A little surprise will await you at the end of this session.
About your facilitator:
Jonathan Crosby has been working in various roles in the IT industry for 25 years. A few years ago, he decided to write an introductory book on software projects for non-techies and beginners.