Log in

No account? Create an account

Previous Entry | Next Entry

Be at work today.

We've been told that we're going to a Scrum (agile) development process. All the planning has been done for that.

Except no, it's agile with exceptions.

Because you see, some projects are high priority, so they take precedence over other projects. Except there isn't one person who sets the priority, the priority is set by the individual project manager.

So each project becomes the highest priority.

I say "Oh, no it doesn't." And I will push back on the issue.

I get told to be careful of what I push back on.

And there are some projects where they want to pull off developers to dedicate their time to those specific projects. Meaning that I will be the sole developer working on our next software release.

Okay, but you may not get all the features and bug fixes that you want. In fact, you may get very few of them.

Well, the expectation is that we will have a certain feature set completed, or at least a significant part of that feature set. Say 70-80 percent.

What you want and what is actually there may be two entirely different things.

I did not mention anything about biting any part of my anatomy.

I will however be enforcing the warboard for all projects. If anybody wants to complain about software not getting done, there is very rigid proof of what exactly is happening.

I'm pissed off. And I need to relax and let it go.



( 8 comments — Leave a comment )
Apr. 3rd, 2008 09:03 pm (UTC)
Okay, here's the deal: Project Prioritization has abso-fucking-lutely NOTHING to do with Project Delivery Methodology.

And Change Management operates on any project methodology. Want to pull a developer? Sure, but here's what it will cost you, in both dollars and delivery. Want to deprioritize a formerly-high-priority project? No problem, but here's how it will bite you in the ass.

Really, all this paperwork war does is give you that lovely feeling of smug satisfaction when you say "I told you so."
Apr. 3rd, 2008 09:36 pm (UTC)
...but be sure to document everything so you can pull out a twenty-four-point presentation on how You Told Them So, when You Told Them So, and what You Told Them.
Apr. 3rd, 2008 10:45 pm (UTC)
I think there needs to be some shoving of something into some orifice or another as part of that presentation. The pointy bits just add to my satisfaction.
Apr. 3rd, 2008 10:43 pm (UTC)
There's a disconnect in some of the management folk about the results of pulling a developer or reprioritizing. They don't seem to understand it.
Apr. 3rd, 2008 10:55 pm (UTC)
Once they fuck over a couple big projects, then bring them all into a conference room for a little exercise in Kindergarten math... math with bagels.

Give them each 2 bagels, and then have one take one bagel away from another.

The dude with 3 bagels can feed himself for all 3 meals, or feed 3 people. Meanwhile the dude with 1 bagel can eat for one meal, or cut up his one bagel and only have a wee snack for 3 meals.

Bagels = resources.

Hopefully it sinks in. Plus, you get bagels. And everyone knows managers come to meetings with food.
Apr. 3rd, 2008 09:20 pm (UTC)
To amuse you:
I thought that you would be amused that Marcus has taken to saying "Yes mother" in a perfect Rodant Kapur impersonation whenever I tell him something.

It is most annoying.
Apr. 3rd, 2008 10:44 pm (UTC)
Re: To amuse you:
Good boy. :)
Apr. 3rd, 2008 11:09 pm (UTC)
One of the docs I sent you should have a risk analysis section in it.

The two primary keys for successful push-back are:
Feasibility - constraint by technology
Resource - constraint by people/time/money

Other important ones:
Alignment with business priorities - does this project/enhancement request fit with the business objectives - in what way?
Compliance - is there anything in this project which would require us to validate compliance with X (security policy, HIPPA, SOX, GBLA, PCI)?

Combining feasibility and resource - you get to the point that lexinatrix made -

"I have N developers that provide so many development hours per time period. These projects will take this many hours (Total). See how the total is bigger than my number of resources? Right? Are you going to provide more resources or change priorities?"

As a PM, it is your job to make the decision makers deal with reality. If something cannot be done with a technology or in a given time or with given skill levels, give them (the decision makers/sponsors/steering committee) the options, give them your recommendation, propose a workable solution (the go-forward plan), and let them make the call. If they cannot decide in an appropriate timeframe, your proposed workable solution is the updated project, by tacit consent.
( 8 comments — Leave a comment )

Latest Month

April 2012


Powered by LiveJournal.com
Designed by Tiffany Chow