10,000 Foot Developer

I was watching some of my buddies on a project and they have been living in the bowels of hell.  They are on an Iterative Death March project.

A Death March Project classically defined is a nightmarish high risk, huge overtime/grueling work, looming deadline project. Oh, the horror.  You can read about it in wikipedia (Death March)  or in the book that I first remember telling me about this methodology — Death March by Edwartd Yourdon.

Iterative Death March is the agile version, but repeats itself every sprint and for the whole release.  The poor participants are doomed to live in hell over and over week by week with more mission critical deadlines.  It is much much worse than classic Death March technique, like having your head held underwater repeatedly.

I’ve been on a few myself.

The Problem

Iterative Death March is an agile style that is very common today.   If you read my post Agile Steamship Part 1, then you can see some of the causes.  But basically, for a developer, the experience is like this:

• The project is at mission critical according to some higher-up and time is running out towards the deadline.
• Hardly any requirements have been fleshed after months, MONTHS, have went by.
• Technical expertise was never consulted, and there is no cross-team technical vision or architecture.  The same work gets repeated over and over.
• There are plenty, PLENTY of PM’s who partake in daily blamestorming meetings.  In fact, before the actual work is done the framework for whom to blame (developers) is well architected and set into place.
• Agile is dropped into place so that developers can be blamed more efficiently.  By making them put their names on tasks, they are now accountable.  But, none of the poor planning and inaction is tracked up to that point.
• Bodies all over.  Tons of them.  People brought in off of projects.   People with knowledge are reassigned though.  new faces with no domain knowledge are brought in.
• Due to the bodies the effective people’s productivity is reduce so they can train them, contributing to blown deadlines.
• Bugs are logged on unfinished software before its released creating a faux backlog of yet more work in the way of actually accomplishing something.
• Repeat.  Iterate in short sprints.
• Meeting hell.   Developers never get more than 20 minutes of contiguous time to actually make the software.
• Weekends, holidays, and evenings bled from peoples’ lives on short notice with the classic huge pre-release work spike common to many poorly executed waterfall projects.  Just on a nice, short time frame.
• Scope on the agreed sprint work is changed mid-sprint making code bad and work lag even more.  The about face exerted on development efforts for multitasking like that is well documented and results in 30-60% inefficiency, depending on the circumstances (daily interruptions vs. multitasking on several things.
• Attrition and apathy.
• Less software.  Poorer quality.  Higher cost.

I have been there.  No thanks.  Al this crap is in the old Mythical man Month book (from 40 years ago) and still there are teams that don’t listen.

My Solution

Alleviating a management team that will do this to developers has made me no friends, because of a lot of reasons, but mostly because there are other forces like promotions and political power struggles going on outside of the project.  Frankly, its annoying.   But it can be alleviated by taking thee steps:

• Make an accountability trail for everyone, this is the trust framework.  Culturally this is a huge move.   Trackable sharepoint for the BA’s and the PM deliverables WITH tech team signoff.
• Bring tech leads in at the start
• Plan to the point of paranoia.
• Tech team makes a plan to build, and the PM does not control what’s in it at the tech level as long as it lines up with the business stories and the agreed time-boxed schedule.
• If the dates can’t be hit, don’t hit them.  Nothing in the world is important enough to do a crappy job that does absolutely nothing good for the company while people’s lives are trashed.
• Smaller, more expert tech strike teams.
• No new faces during building unless absolutely agreed upon.
• NO scope changes mid-sprint.   The sprint is an agreed contract between the coordinators (PM’s, business) and the people who know how to build the software (which the PMs and business do not).  Changing scope changes outcome, causes attrition.
• Ruthless focus on the task at hand.
• A well planned, sustainable pace.

Last Thoughts

I thought about my buddies on that Iterative Death March team, and some of the other personnel and the business unit and realized that the reason these types of projects come about isn’t because of the project itself, its because of the people.   That’s right — its PEOPLE who create a good or bad atmosphere.  We are the ones who fail or succeed at the planning, or the builds, or the scope management.

And that’s why my best jobs in my career, it was the people who made it great and not the work.  If the people are great the work becomes creative, inventive, and effective.

Hmmm.  Interesting.