Why Project Focused Mentality is Killing Software Development

california damian morys larry apke agile doctor
California by Damian Morys
California by Damian Morys

So, the other day I was listening to NPR in the car (like most people when they listen to talk radio). And the talk was about peace in the Middle East. One of the experts mentioned that, in his opinion, unless both sides owned the process, it was never going to come to fruition. This reminded me of Mark Fritz, international speaker on leadership in today’s organizations, and a compelling blog post he wrote about ownership. I thought this was interesting because there was an interwoven thought he drew upon throughout the post that I believe is applicable to Agile and software development:

“You never wash a rental car.”

I have used a similar phrase many times before when describing the project-centric mentality that pervades most large software development shops. I tell people that, in order to have good quality code, in order to do the right things by the code (BDD/TDD, continuous integration, etc), you must own the code. Therefore, we must move from project to product management, from renting our code to owning the code. So now you know why my brain went from the Middle East to Mark Fritz to rental cars, and now here we are!

Also, I distinctly remember a recent talk when I proposed that in order for better quality products we must eliminate the PMO and replace it with a PPMO (Product and Project Management Office). Interestingly enough, I remember this talk was given to a roomful of project managers who conveniently heard the first part of the phrase and not the second part.

The bottom line is that Agile is about creating high quality software quickly. This cannot be done long term without doing the things that come with owning the code. No project, which merely rents the code, is going to spend their budget making sure that the next group to rent the code has an easier and better time. There is no incentive in project focused organizations to do the right thing! The pressure is on chasing the next bright, shiny object as quickly as possible (e.g: feature chasing) with zero regard for the long term stability of the product.

Before you know it all you have is a big pile of mud that no one can safely enhance or refactor without high chance of regression defects. The time it takes to bring the new, shiny objects to market becomes longer and longer because no one bothered to create the necessary infrastructure. Why not? You might as well ask yourself why no one washes a rental car.

Larry Apke

Chaos to Waterfall to Agile – The Evolution of Software Development

I spent some time recently in a PMO meeting about project  metrics. Seems that the big bosses want to create some service level agreements based on these metrics. The most interesting part of the meeting was sitting back and watching the process. As an Agile proponent I was amazed at the lunacy of central planning. Each project was on a master project list and resources (humans as I like to call them) were assigned based on their time estimates. These folks were scheduled months in advance. During the meeting, the leader of the PMO said that it was incumbent on the individual project manager to make sure that the assigned resource begins and ends their work as based on this long-term plan. Anyone who has spent any time in software development should realize that the odds of the working as slim to none. Funny thing, every PM in the room, even the head of the PMO, who has a background that includes Agile, thought that this was an appropriate methodology.

The kicker for me was when the head of the PMO stated that a successful project was one were estimated time was plus or minus 20%. A simple calculation told me that I was glad that I was not a PM responsible for a downstream project. If a resource is off by 20% on estimation of a large project, then my odds of getting the time I was promised from this resource is is low. Let’s say that the resource is committed to 160 hours of work on a project upstream of mine. This project can be successful even if this resource goes over 20% or 32 hours. If I only needed him for a week or two,  I certainly will not get the work I need or something else will need to slip. Add scope creep, poor requirements, etc and you have a very small likelihood of success, hence the CHAOS report results for project success.

Continue reading “Chaos to Waterfall to Agile – The Evolution of Software Development”