What is a premortem?
A premortem is a project postmortem that’s run before a project. During a postmortem people analyse and discuss what went wrong, what went well and what could be improved.
While postmortems are very useful the problem is that by the time we run them the project is usually over and not much can be done about success and failure.
Hi, my name is Simon and I am a Project Manager at Trade Me. Sandy kindly asked me to contribute to her blog, and I consider it a great honour. Below is my story about how we embraced Agile to inject magic into our project.
My client, a New Zealand government department, is in the process of introducing Agile-Lean. They are currently in a trial phase to see if it is for them and during the early stages they’d like to run Agile and non-Agile projects in parallel.
Fair enough, but how to choose whether a project should be run Agile or Waterfall?
One of my current clients, a large government agency, have recognised that their current monothilitic waterfall approach doesn’t work all that well and are trying to decide whether to change their delivery approach to Agile or “just” Iterative (mini-waterfall style).
Following last week’s interview with a newly-minted Scrum Master this week I have had a conversation with developer Mateusz Udowski. We talked about how SilverStripe’s adoption of Agile and Scrum have affected him and why he thinks SilverStripe is now more intelligent as a whole than it was before.
In many companies, especially those who provide services to external clients, the main focus from a project management perspective seems to be on resource allocation and utilisation. People are viewed as individual “resources” and an important goal is to maximise people’s utilisation (Before you say this is not true, think about how important this metric is at your company and that people tend to optimise what is being measured).
I know that especially for vendors who often charge by the hour or have to keep cost down in a fixed price and scope scenario, utilisation is hugely important. That’s fair enough. However, making utilisation the main driving factor, will backfire and ultimately lower utilisation.
By foregoing the team approach, aiming to maximise utilisation and piecing together projects through dynamically allocating and re-allocating people we:
“When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.”
— Nanny McPhee (via Lyssa Adkins)
I am an Agile coach and the goal of my job is to put myself out of a job.
My mission is to teach people Agile and to make sure they understand and correctly apply Agile values, principles, frameworks and techniques. This is quite a big deal as Agile often forces us to change the way we work on a daily basis; how we organise our work, how we collaborate, which tasks we perform and how we communicate with each other and the rest of the organisation.
There’s a saying in software development “If someone gets hit by the red bus … “ which roughly translates to that if you lose a project team member or two you still want to be able to get the work done and finish the project.
Normally, red busses are rare: The realistic worst case scenario is one or two team members out with the flu or someone quitting their job. A good team can normally recover from such disruptions.
But red busses can be bigger and more damaging and wipe out large parts of a team: This usually happens if a new CEO, new management or a new government revokes funding, recession hits or an organisation just plain runs out of money.
In this case one of two things normally happen:
This is bad news for everyone but has a devastating effect if your project runs any flavour of the waterfall methodology: