There are certain software projects, that if mismanaged spiral towards mediocrity very quickly. Why do they not spiral toward a certain death? This is because in the end, most software projects deliver something. They may not deliver the product vision, but through all of the pain the team end up delivering something.
Why do I think these projects are poisonous? It's simple. In almost all cases no-one likes using or engaging with a mediocre product. Customers love using, and love sharing, products that exceed their expectations. Mediocre software deliveries rarely exceed Customer expectation and consequently rarely get used by the end Customer they were intended for. Sure there is the odd occasion that a mediocre software delivery is loved by the intended Customer base. This is rare.
Also mediocre products are rarely loved by the people that create them. If this is the case then the software delivery team will rarely promote their own work. They will rarely be proud in their work and in most cases they won't have an interest in taking ownership of their work. A sense of ownership within a software delivery team results in actually allowing the team to engage and grow with the product they they can then strive to improve to exceed expectations.
So how do you determine if your project is poisonous, and how do you deal with it spiralling towards mediocrity? A really clear indication would be if several, or indeed many, of the delivery team leave during the project lifecycle. This really should set alarm bells ringing, and theoretically trigger a response. Clearly acknowledging there is a problem is the start to finding a solution to solve it.
A group of people leaving a project is the clearest indication of a poison project. A pretty simple way of finding a possible solution in this case is to ask the people leaving what they think would solve the problem. even ask them if there changes were instigated would they consider staying? Who know's it might be the kick start needed to lift the project above mediocrity.
As an example in a previous occasion when a number of people left a project that I knew about, they mentioned that communication with marketing and stake holders was a continual problem and that no matter how much they tried to solve the problem they met brick walls that they could not overcome without further support. A simple solution here might be to sit the delivery team e.g. marketing and technology together. If this is done communication is no longer a process but rather an instinct. It is almost impossible for a team that sits together to not communicate better! If communication is an issue, remove barriers that are making it an issue. In this case what would there be to lose? Things cannot get worse!
Another means to determine if a project is heading towards mediocrity is to simply ask the people who are working on it if they are happy. If there are then it's a pretty safe bet that the project is adding to their level of well being and this typically would indicate a measure of future success on the project. If the team on a whole is down, then rest assured something is wrong with either the product or the process that is being followed to deliver it.
What can be done to fix this? Well the answer is simple again. Let the team decide how to fix it. A delivery team, in most instances, doesn't need to be directed from on high. A delivery team, if correctly staffed with the right level of experience, knows what it has to do to get something out the door. This is where the beauty of the Agile software delivery process comes into play. Agile promotes self inspection by the team who own the product and delivery process that they are working on. If things are not working correctly, then the team, not an individual, decides on the best approach to improve.
No comments:
Post a Comment