Jan. 11th, 2005

ravencallscrows: (goldfish)
I'm going to toss this out here because there are a number of software people as well as some non-technical, non-software people who read this.

Have you ever been in a position where you mistook a process with the result, or confused tools with the methods?

At work, we are, as you're all too sick of hearing by now i'm sure, having Agile Development methodologies forced upon us. But i'm beginning to suspect that the people who are on the receiving end of the process understand what is expected of us better than the people who are initiating and driving the whole process.

We all got summoned to a two-hour meeting today, specifically for the purpose of playing a game one of the folks in charge of implementing the change found- you know the sort- those 'motivational, team-building' exercises in which everyone i know hates being forced to participate so that we "can all see how the process is supposed to work."

We're all objecting. After all, we all have real work which needs to get done. We had the two hour sit-down last Thursday and walked through the process. We pretty much understand our deliverables- for the most part, they haven't changed a bit, we're just going to focus on smaller discrete chunks rather than whole projects.

But the Higher Ups want us to do this exercise- to the point where they're volunteering to postpone delivery dates for the stuff which is supposed to go out this week- and they seem to think it's important that we spend two hours making paper boats and hats rather than delivering software for which the end users were promised very concrete street dates.

So much for valuing individuals and interactions over processes and tools. So much for responding to change over following a plan. There are two of the four points of the Agile Manifesto right out the door already, and we haven't even completely implemented it yet. And that's not touching the twelve principles of the whole mess. By pushing back the dates, they'd blow away the first one- the "highest priority is to satisfy the customer through early and continuous delivery of valuable software. We've already nuked the fifth one, which says that projects should be built around motivated individuals, and that those individuals should be given the environment and support they need to get the job done. Likewise, the eleventh- saying that the best stuff comes out of self-organizing teams- is history.

It doesn't matter that we're all pretty much unified in saying "just let us work on the stuff already, we don't need to play games- we've got the idea, if we have questions, we'll ask or figure them out ourselves (my guess is that the latter approach is not only the only one which would work, but the most efficient as well)." It's important to them that we play the stupid game- which is yet another sign that the process is more important than results; and that not listening to the people who are actually going to do the damned work is the best way to make sure that they're motivated, empowered individuals.

Oh, yes- and we didn't end up playing the game today anyway, because one of the people who was coordinating it was insufficiently prepared to have us do it. Efficiency at its finest.

Profile

ravencallscrows: (Default)
Vanya Y Tucherov

January 2025

S M T W T F S
   1234
567891011
12131415 161718
19202122232425
262728293031 

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 4th, 2025 02:56 pm
Powered by Dreamwidth Studios