What’s the degree of PMP and Agile within a project,(Part 2 of 2)
My first grasp of the toxicity level for a project template was many years ago, during a meeting (which, taking into account the fees of the participants, wasted more than 2000 Euros per hour), its topic being the template (with capital T) about to be used for gathering some trivial piece of information. Should we keep the X area? It doesn’t seem to apply in our case … I say we should; if it’s there, we might need it. Let’s leave it as it is and we’ll figure out what to write there. And so on and so forth, hour by hour. No wonder this type of experiences make the practitioners want to run away (when can we work if we sit in meetings all day long?) only when hearing about project management. The problem is that the opposite – anarchy – is just as bad as a strict setup.
Now coming back to the original question:
How much Agile? Enough to make the team members shovel their breakfast thinking about all the interesting things they will do when they get to work and enough to make them lose track of time when it’s time to go home, at the end of a working day. Those passionate about something, regardless of its type, know exactly what I’m talking about.
How much PMP? It may come as a surprise for an Agile practitioner, but in my opinion all; however only in spirit, not translated into forms and reports! This can only be possible with a right approach.
This way, the goal of the project can very well be represented through cartoon user stories, Doors (the IBM application, not Jim Morrison’s band) not being an imperative for managing the requirements. Taking into account the iterative nature of the Agile projects one can easily lose the Work Breakdown Structure (WBS), however a Product Breakdown Structure (PBS) can constitute a big help with making the backlog. The risk can be addressed by means of some plain sheets of paper kept in sight on your whiteboard.
Same way, one needs a Gantt diagram to see on the time axis the important milestones within a project, having this way the opportunity to instrument the existing interdependencies; however it is absolutely pointless to use Microsoft Project for the daily timesheet. Success is measured by quality software, not by man hours; if anyone has any doubts, I suggest attaching a timesheet record to a one star Android Market application and see the rating improvement.
QA, cost management, acquisitions … I recommend a simple exercise: randomly open the PMBOK and read the first word you set eyes on: you will probably think it wouldn’t be a bad idea to have something like that in your Agile project – of course, the mandatory condition being the literal observance of that concept specified in Agile Manifesto, Individuals and interactions over processes and tools.
Did you miss Part 1? Here is the article.
What do you think? Please share your comments below.
Image taken from HERE