Nobody Goes Home Until...

Have you ever had a manager use that phrase or something similar before? It's a downfall of development methodologies, or simply bad management.

Assigning a date to development has always been more than difficult. Estimates are made using best guesses, and in a perfect world they're based on similar work done before. That never means the estimate is guaranteed. Sometimes it takes less time, maybe because that task had in fact been done before. Sometimes it takes longer because of unforeseen events. Sometimes you get lucky and it's spot on.

I had a manager who was famous for using the phrase in the title of this post. I recall distinctly his use of that phrase four days in a row. Sadly, my team had discovered the problem and issued a fix at the zero hour on the first two days, leaving us feeling like we'd "trained" him to know he could get results by uttering those words. Never mind the arguments against carrying out such work. We would lose time on the planned work we had to do, the "fixes" weren't fully tested, and we had little idea of their long term effects. We knew we were making problematic software more problematic and falling behind. He knew he got results.

The reality is sometimes issues come up that weren't planned for. Projects have to be flexible enough to at least attempt to address those issues. If customer ABC cannot get their work done, you are failing them and need to be able to get them back on track. Sometimes, though, it's a problem of managing expectations. "We asked for the font to be pink two months ago! It's a simple change, why can't I have it now?"

I know of no development methodologies that solve this. Waterfall would have you put this issue in a next release. Agile would have you push this issue into a meeting where you decided when you could get to it, or which issues you would have to let slip in order to address it. Either way, something is going to have to wait, and sometimes that's not acceptable.

Steve Yegge described his view of Google's methodology on his blog a while back. Google seems to have more of a FIFO stack with an environment that nurtures good development. No real methodology to speak of, at least not one that's defined in books and expensive presentations. Really, what they've implemented seems to be more of a common sense approach.

We all know there is work to be done, and that expectations are that it does get done in a reasonable amount of time. Do we really need a rigid ruleset to follow in order to be sure it gets done?

When I'm asked what methodology we use, I think my answer is fairly typical. We borrow good ideas from methodologies and incorporate them into a hyrbid of sorts. I like the idea of scrum meetings, and we have a daily meeting where each developer on the team discusses what they did since last meeting and what they're working on now. That leads to another topic in the meeting I like... architecture. After our scrumish meeting, we discuss any problems that were brought to the table and possible solutions. This can't always be done in a single meeting, and if it takes longer, we'll either schedule a meeting to focus on that topic or table it for the next meeting to continue discussion.

We have milestones, but no hard dates. Hard dates promote hurried decisions and hurried coding. I want my developers to think about their solution and make sure it's right for our framework and architecture. The milestones we have merely give an order for incremental releases. That doesn't mean those items are all that is worked on until the milestone is hit, but they are the main focus. I like iterative releases to UAT. Users can test portions of the application while development moves on. What could be more efficient than that?

My goal on projects, after defining the project itself, is to allow developers to do their work in an environment that allows them to do it. I don't stand over their shoulders. I don't dictate what pieces of the project they work on in what order. I don't commit to dates that can't be met or are questionable.

I do report on progress. I do have a project plan that shows what items are being worked on by whom, and about how far along those items are. Dates have to be set because that's how project management software works, but they're slippery. I have confidence in my team and they're professional enough to continue work on their pieces of the puzzle, and that they'll come to me if that's problematic.

In a nutshell, I facilitate. I'm the middle guy between the folks who are getting the work done and the folks who are funding that work. Both sides want information, and both sides want to see progress. I don't believe it takes a particular methodology to accomplish that. It just takes professionals with some common sense.