Reply to: Technical term for a brain dead management technique?

[eliquant]

Agile

[Zippy]

I booted a "PM" out of one of our Scrum meetings cos he couoldn't stop putting his oar in. The deal was that the devs would meet every morning for 10 mins and talk about what they had done and what they were going to do, plus any blocks. No other chat was permotted (apart from the lads sorting out the jobs for the day). But this bloke just kept on wittering... so I kicked him out.
Not a popular Zip
He came round to the idea in the end, when he saw that stuff got delivered on time, but it was uphill work,

[NickFitz]

This is one of the things Scrum meetings attempt to overcome - the us and them thing. In the ones I ran there was no hiding place - and the devs didn't attempt to do that(once they had got used to the idea). What actually happened was someone would talk about a problem he was having, then someone else would offer to help. It worked well.

WSS, although if anything it was the PMs getting used to the idea, whereas the devs were well up for it - we all knew that if we can get another guy's problem sorted out, it means we won't get interrupted later, and conversely, if they can sort out our problem, we won't have to disturb them later and risk getting punched in the gob - some people take unbelievably complex intellectually challenging problems so seriously

The PMs were good at things like sourcing the squeaky toy (a very vicious-looking plastic rat in one case) used to stop people who went on too long, and looking after the beer kitty funded by those who were late without a good excuse - oh, and moving the PostIt notes around the board so as to give the impression of things happening

[Zippy]

I have found the opposite at many places - quite often someone sitting in the corner who is struggling with their work and doesn't want to come clean and admit it.

This is one of the things Scrum meetings attempt to overcome - the us and them thing. In the ones I ran there was no hiding place - and the devs didn't attempt to do that(once they had got used to the idea). What actually happened was someone would talk about a problem he was having, then someone else would offer to help. It worked well.

[MPwannadecentincome]

PMs do not need to make team members artificially keep in touch with one-another, we do it anyway as and when required.

I have found the opposite at many places - quite often someone sitting in the corner who is struggling with their work and doesn't want to come clean and admit it.

[thunderlizard]

Last time I was involved with scrum the "team" was just several independent contractors each with their own area of responsibility and no overlaps. "Daily Scrum" never lasted more than 90 seconds.

[NickFitz]

PMs do not need to make team members artificially keep in touch with one-another, we do it anyway as and when required. I've always found PMs to be unnecessary overhead who are only told things they want to hear or that they can understand without a massive technical briefing in order to try and keep them out of the way of the productive people as much as possible.

Granted I've only ever worked with bad PMs, I am currently unaware that there are any other kind. Perhaps if they had an experience of development in the technologies in use on the project they would be helpful.

One thing that I found very useful about the morning stand-up was that, very often, it brought up matters that could be dealt with very quickly, in a way that avoided delays, inconvenience, or interruptions.

So, for example, I might know that I need Fred to do foo sometime today, but I don't know how long that will take him. By mentioning it as a blocker at the morning stand-up, it's possible for him to say "Oh, that'll only take me two minutes, I'll do it straight after the meeting." If I left it until I actually needed it later that day, I might find that he's nose-deep in some complex task which means he's ignoring email and IM and will probably lose a couple of hours of productivity if I go and tap him on the shoulder and break his flow.

By having a fifteen-minute stand-up meeting at a fixed time each day (between 10 and 11 AM is good, as you don't want to force people to get out of bed too early) there tend to be no end of little things that get sorted out that much easier, and many fewer interruptions and temporary diversions throughout the day. It's surprising how beneficial it can be.

[shoes]

[QUOTE=original PM;996917][QUOTE=NickFitz;996907]You could indeed

Firstly, it's not micromanagement: it's as much about the team keeping in touch with each other as anything else.

etc

A very good point and one I shall remember oh hang on the basic assumption in all of this is that you are dealing with profesional motivated people!!!!

PMs do not need to make team members artificially keep in touch with one-another, we do it anyway as and when required. I've always found PMs to be unnecessary overhead who are only told things they want to hear or that they can understand without a massive technical briefing in order to try and keep them out of the way of the productive people as much as possible.

Granted I've only ever worked with bad PMs, I am currently unaware that there are any other kind. Perhaps if they had an experience of development in the technologies in use on the project they would be helpful.

[original PM]

**** gimme your job!

[NickFitz]

A very good point and one I shall remember oh hang on the basic assumption in all of this is that you are dealing with profesional motivated people!!!!

Why would I waste my time working with any other kind?

[original PM]

or to put it another way

your frognostificator is already 3 days behind schedule because you were pulled off the project to fix the MD's laptop - after 3 days of trying to do this by phone you go to the MD's luxury mansion to find his son has swapped his laptop for an etch-a-sketch

in addition to this the guy building the widgetiser is the boss's mate and so does not need to stick to any schedules and wo betide anyone who tries to say anything against him

and besides the whole frognostificator project has been put on hold as some bean counters projects show that the frognostifcator project will be 2 p over budget and so approval from the board, the exec, god and Davros the Dalek must be approved before that project can continue.

and I am no longer a PM I am now a Solutions Architect - whatver one of them may be - so I suppose I should change my name.

[Mustang]

so it would seem that a group of correctly skilled motivated people who are committed to achieving the project goal will achieve more than a bunch of seperate people who are hung together by a process.

so choose the right team, make sure they understand the goal and keep them motivated - and your project will be a success regardless of the methodology you use.

Which is why project management cannot be learned from a book.

You can tell from the posts on this thread who are PM's and who aren't!!

[original PM]

[QUOTE=NickFitz;996907]You could indeed

Firstly, it's not micromanagement: it's as much about the team keeping in touch with each other as anything else.

etc

[QUOTE]

A very good point and one I shall remember oh hang on the basic assumption in all of this is that you are dealing with profesional motivated people!!!!

[cojak]

Nice post Nick!

<squirrels away to 'Reference'...>

[NickFitz]

Does micromanagment of this nature actually work?

surely if you have decent profesional people then you do not need to check they actual did any work yesterday and then check they are going to do some work today??

And in fact the very act of checking and re-checking is more demotivating than laying a cable in their morning cuppa?

I could be wrong but......

You could indeed

Firstly, it's not micromanagement: it's as much about the team keeping in touch with each other as anything else.

It's also not about checking up on people: it's about checking up on the state of things and catching potential problems before they become significant. It also lets you discover potential wins you weren't aware of.

To take an example: I explain that I spent yesterday finishing off the frobnosticator, and that is now checked in. This means that the person responsible for QA of the frobnosticator knows that it's there for them to start poking at. However, I point out, it currently has the rather basic UI I defined for it; the UED person remembers that they have that on their list of things to do, and makes a note to let me know when they've decided what colour it should be.

I then announce that today I plan to commence work on the widgetiser. However, I have a blocker: the widgetiser is dependant on the WTTP protocol being implemented, and the last time I looked the server didn't support it. Up pops the server chappy: no problem, he says, he's just got a few more tests to do and he can get the WTTP handler deployed.Do I need it this morning? No, I say, this afternoon would be fine.

At this point one of the other developers reminds me that he's already got a basic implementation of the WTTP client code that he started a few months ago; we should get our heads together and see about using that, rather than starting over from scratch.

So, at this point, I've been speaking for about twenty seconds in total, and we've got the QA guy knowing he's got something to do; the UED lass reminded of something she'd put on the backburner; the server chappy aware that others are waiting on his WTTP implementation; and myself aware that there's a half-made wheel I can use, and that somebody has some knowledge I can take advantage of.

Best of all, none of us end up wasting a whole day because "I emailed so-and-so but she hasn't got back to me yet."

At no point has a manager had to try to organise things: we've all organised it ourselves, and the PM can see that things are running smoothly.

Every person has their thirty to sixty seconds, and everybody knows everything of any importance about the current state of the project.

Of course this all assumes the rest of the Scrum process: the concept of sprints, backlogs, and so forth to provide the meta-management and overall structuring of the project. But within that framework, the daily standup meeting is an epic win for the sake of fifteen minutes a day