Comments on: Three Ways to Get Developers to Keep You up to Speed

By: sameera

sameera — Thu, 25 Dec 2008 15:32:55 +0000

Hi Ben,

You write well and make a lot of sense. I have only heard in name about the Ajile methodology and can only imagine how you might have to change the documentation dynamically.

Good luck to you. I am glad to have asked for the archives.

By: one man writes » Recently Read

one man writes » Recently Read — Sat, 05 Apr 2008 13:02:46 +0000

[...] a read, particularly if you are looking at launching your own technical community initiative. Three Ways to Get Developers to Keep You up to Speed A simple reminder of how to get things done, the kind of advice that sometimes seems very obvious [...]

By: Staying on top of changes by Communications from DMN

Staying on top of changes by Communications from DMN — Wed, 02 Apr 2008 13:03:11 +0000

[...] This blog post offers three ways in which you can make sure that developers keep you informed of all changes and new features. While I think that the third piece of advice — Look up the ladder — is a bit drastic and can generate animosity, it can definitely remind people to keep you in the loop. Sphere: Related Content [...]

By: Ben

Ben — Tue, 25 Mar 2008 00:33:26 +0000

Not an insane policy, just cautious.

By: PM Hut

PM Hut — Fri, 21 Mar 2008 01:12:02 +0000

You can’t believe how hard I’m laughing about the last thing you said. You must working in a company with an insane internet policy (oops)!

Your blog is great but is very new and I want to introduce it to PMs out there, I would like to reproduce one or more of your articles on PM Hut.

Please email me if you’re interested…

By: Ben

Ben — Thu, 20 Mar 2008 23:26:38 +0000

Thanks for the comment. It wasn’t my intention to make the situation sound out of control (and I don’t see anywhere that I said “substantial” in the first paragraph). My point was just that designers or developers may decide that a slight wording is better or that clicking a certain button should execute an action a little differently than originally decided upon. A quick change for a developer has the potential of affecting quite a bit of the documentation.

For anyone who isn’t familiar with Agile methodology, one of the fundamentals is that the customer is involved throughout the lifecycle. She doesn’t put together a requirements document, throw it over the wall, and wait for a perfect product to come back over. We work in iterations of two to four weeks in length. A scheduled set of functionality is developed and tested (and documented) within an iteration. In our flavor of Agile, prototyping is done several iterations ahead, and the customer gives approval. The customer must also review and approve the work done in each iteration or group of iterations.

This gives the customer the chance to say something if he realizes that the project’s direction needs to be adjusted. Let’s face it: Sometimes, the customer may not know what the best solution for his needs or business is. Guidance can be given at the beginning, but unfortunately, it’s only as the project moves forward and the product takes shape that the customer gets a more solid idea of what he needs.

By the way, I tried to hit this page at work when your comment came in, and the filtering system blocked it, probably because of the word “speed.” I had to chuckle. Also, the PM Hut looks like a great resource.

By: PM Hut

PM Hut — Thu, 20 Mar 2008 04:09:07 +0000

I was reading your post and it was interesting when I read your first paragraph, which was about the amount of substantial changes in software projects. In my opinion, this is a sign of bad project management probably resulting from lack of stakeholder support. Of course, changes are inevitable, but not to this extent…