A quick glance at the dictionary gives us a definition of the word agile – “marked by ready ability to move with quick easy grace.” The IT community has co-opted this word and extrapolated a meaning that is really beyond description. Of course, what else were we supposed to do?
Much comparison has been drawn between building software and physical construction (e.g. building a house). But this comparison really isn’t fair. While it’s true that it’s extremely costly to make changes to a building after it is erected, the same multipliers used in that industry cannot be applied to software. Seriously – have you ever had to bring a demolition crew in to remove a section of code? The delete key is our wrecking ball.
At some point, I’m sure a manager looked at this software construction like building construction parallel and said, “I need you guys to work in a more agile manner.” And there it began. Sure, there were puzzled looks in the conference room, but then they all went back to their war room or desks and started figuring out what the manager meant by agile. Today, we have a half dozen agile methodologies that address this perceived need to move fast. Each of them has their own caveats of “this may not be the best approach for you.” Unfortunately those sections seem to be often skipped.
The Software Development Life Cycle you choose for your project should not be dictated by whichever magazine article is sitting on your desk at the moment. It is a choice that needs to be carefully made based on your entire situation. What is the makeup of your team? Do they work best on well-defined tasks or are they better when left to find creative approaches? What is your relationship and level of involvement and commitment with your customer? What type of project is it – are you solving a well defined problem or is further research required?
My parting thought for today is a continuation of the last paragraph’s them – ask questions. If you are the team lead or project manager, your value comes from applying the experience you’ve gathered from past projects. When your customer or manager makes a broad statement, dive into it and understand what he is asking for. You will then have a much clearer shot at success, no matter what methodology you choose to deliver it.
Image via Wikipedia
If you have spent any time on a formally managed project, you have no doubt seen the status reports with the green / yellow / red codings. These symbols are taken from the traffic signal concept, a concept that is universally accepted. Green means go, red means stop, and yellow means SPEED UP!!! Just kidding – yellow means caution / clear the intersection. With such clear meanings while driving, and the generally anal nature of project managers, you would think that clear meanings would be established for green, yellow and red signals on project status reports.
You would be wrong.
My favorite current example is a project whose one-slider (one slide divided into four quadrants for accomplishments, issues, milestones and budget) is covered up in red on the milestone sections. It is clear that the milestones that have been set have been blown through, and the work necessary to complete that milestone is late. However, the project overall was still showing green on time. This is a project that has not met A SINGLE DELIVERABLE DEADLINE. How can you be green on overall time, but red on practically everything else (the milestones that were still in flight were showing yellow). This led to a somewhat heated debate – and I got my point across. The project is now at least showing its tracking yellow.
My point here is not to throw anyone under the bus, but rather to share a lesson learned. You need as a team to agree up front on how status will be reported and what the criteria for having a green, yellow or red color code is (or whatever system you are going to use to give high level status). That way, the status is not being re-negotiated when it really should be black & white (or in this case red).
My PMP credential is up for renewal at the end of this year, so I’ve been closely watching the calendar and course offerings from PMI education providers. I think I’m only short 10-14, and there are a couple of books I’ve read on a self-directed basis that would probably fit that bill, but I’m always on the lookout to further my education and expertise in the project management realm. I took a class a couple of years back on Building High Performance Project Teams that I thought was excellent, and have recently been toying with the idea of taking an eSeminarsWorld class on Effective Project Communications and Control for Virtual Teams since so much of our work is being implemented off shore.
One interesting alternative that just popped into my inbox is an offering called Alaskan Recovery Simulation: Project Scope Management. The thought of doing a simulation is very appealing since it engages much more of your mind than a book or even a moderately interactive course. Sadly, it’s only 3.5 PDUs, so I’ll have to see where it fits into the grand time / money tradeoff, but it’s definitely on my mind. Has anyone participated in this simulation (or one like it) that would like to share some feedback? Please hit me up in the comments!
There is a first time for everything, and several weeks ago I experienced my first video bug report. At first I was excited – it's not often that you can follow a use case all the way through and see a random defect on a client machine. Then, I was dismayed. You see, it came as an attachment to an email. The subject line was "Authenticated search bug". The body of the email only contained the video attachment. The video did not have sound. So, I watched the video and played go-fish for the bug.
In the end all I saw was a beautfully rendered search results page.