97 Things Every Project Manager Should Know

(Rick Simeone) #1

(^44) 97 Things Every Project Manager Should Know


Empowering Developers: A Man Named Tim


Empowering Developers: A Man Named Tim


Ken Sipe
St. Charles, Missouri, U.S.


oFTEn ThE BEST ThIng a software project manager can do is set the vision, set
the priorities, and get out of the way. Here’s a true story about a man named Tim.


We found we needed another team member on our project, so we posted the
opening and began to interview. One individual soon rose to the top of our
candidate list.


His name was Tim. Tim stood out significantly from the other applicants, and
it would have been a “no-brainer” decision to hire him. But, there was one
dissenting vote. All resources hired into our department may rotate between
any one of three project managers. One of those PMs had previous experience
working with Tim and indicated that he lacked motivation. She painted a pic-
ture of Tim web surfing regularly while on the job, and being a slacker.


This was a tough situation. When making a hiring decision, more weight
would normally be applied to a project manager’s personal experience with the
candidate as compared to a cold interview. However, from a technical perspec-
tive, Tim’s skills significantly exceeded those of other candidates. He was hired
despite the dissenting vote. The project was run using an agile development
methodology, so we had an open meeting at the start of the iteration.*


The opening meeting has several main purposes:



  1. St ories† are created and their priority is established and communicated,
    based on user input.



  • Iteration: A short period of time chosen by an agile project team (a week, two weeks, a month,
    etc.) during which a key requirement chosen by the customer will be developed, tested, and then
    delivered to the customer for approval or comment. The next iteration will then begin to develop
    the next most important requirement and/or correct the work done in the preceding iteration.
    † Story: A high-level description of a software requirement, usually broken down into single devel-
    oper tasks, with just enough information to allow a developer to estimate how long it will take to
    create, test, and/or implement it.

Free download pdf