Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Thursday, July 26, 2007

Will My Software Project Fail?

There are a lot of reasons typically given for software projects failing, poor management, lack of requirements, and lack (or excess) of talent are common reasons I've heard(used) for failed projects that I've witnessed(particpated in).

Coding Horror has an excellent article that presents 3 alternative reasons that projects may fail that might not be intuitive at first.

Will My Software Project Fail?

CH presents three new pillars of successful software projects.

  1. Version Control
  2. Work Intake Management
  3. Build System


These are three things that I've lobbied for in every project I've ever worked on, even when I couldn't articulate what I wanted because I hadn't yet seen it in action.

Submit this story to DotNetKicks

Wednesday, June 27, 2007

Tsst.

Every wonder what career a character like Cartman might gravitate towards when he grows up? If you said Project Manager then you probably work as a developer too. Pushy, whiny, demanding, self-centered and glad to criticize you while you are working.

Well, the trick is to assert your dominance and become the alpha dev of your team. Not that you want their job, just that you need to assert that you are a confident professional. But unlike Cartman's mom, you can't actually pinch your PM's in the neck. What you can do is assert your own authori-tay.

If your PM has as much willpower to control work intake as a greedy little piggy then you need to take action. Tsst! They need to flip the words around in their title and learn that if they don't want to look bad they need to "manage projects". It's not your fault they promised that the invoicing changes, website updates, database optimization, customer xyz's customizations and anything else they see lying on the ground while walking to their desk, would all be done by Friday; it's theirs. Sit down with them, list the projects they want to accomplish and figure out what you can finish by Friday. Then work out what it will take to accomplish the entire list. They can then take that to whoever they swore their first born to about that Friday deadline and take their lumps. Don't work overtime just because they cry "but maaa-aam, I want you doo eet, whaaa!". You are only reinforcing negative behavior. Overtime should only be allowed in the case of actual emergencies and by emergency I mean that space aliens and the government are somehow involved.

Pretty soon they will get used to actually working WITH you to plan their projects. And with patience and proper manager training, you will win the war and find yourself in an agile shop without a single shot being fired*.

*Or you'll be fired. This is insanity, I am an insane person. If this works for anyone then they should get their own television show.

Submit this story to DotNetKicks

Clumsy Development

Basically it's the George Costanza model of software development. The only requirement is to know the vocabulary, not that you need to know what the words mean though.

For example.

Agile says to not have constantly changing priorities while expecting your developers to change on a dime.

Clumsy says, the more projects the better, what else are the developers going to do with their time? Test, bah!

Agile says to keep meetings to a minimum.

Clumsy says that whoever passes out from lack of oxygen first wins.

Agile cares about the developer's quality of life and acknowledges that it is important for the long term success of the project.

Clumsy says "Whip the horse until it's dead." (This I have on reliable hearsay was an actual statement made by someone with a very fancy title and doors on his office.)

Submit this story to DotNetKicks

Saturday, May 12, 2007

What is "done"?

Back when I was just getting my teeth into agile software development I was confused as to when a project can be considered done. Some colleagues said that when it was good enough or when they stopped being paid; but most of the definitions were too vague and indeterminate. When can we step back and safely say that all the necessary steps for producing a quality product have been satisfied? I sat down and considered all the "musts" and "shoulds" from a variety of sources and created the following list.

What is “done”?

Done is…


  • … the software has been written to address the requirements of the end-user. No more, no less.

  • … the software has a suite of tests written to exercise and validate that it meets the requirements and is technically valid.

  • … the software’s source code has been reviewed by a peer, preferably peers.

  • … the software’s source code meets the development teams coding standards.

  • … the software’s source code has been factored into logical and easily readable sections.

  • … the software’s functionality has been tested by integrating it into the system it will reside.

  • … the software’s functionality has been documented and described for future developers and users.

  • … the software has been tested and reviewed by a quality assurance expert.

  • … the software has appropriate installation and/or configuration procedures created and documented.

  • … the software’s functionality has been verified as meeting the requirements of the end-user by the end-user.



Special thanks to Derik Whittaker for digging up this document, the original is archived on some backup disc that I will have to find eventually but it was written in the Autumn of 2006. Click over to Derik's blog and read some of his stuff, it's worth your time. Derik Whittaker's blog.

Submit this story to DotNetKicks