Projects and project managers in Agile SW developmentPosted: August 11, 2009
Clearing some mess around project in Agile context. Thanx for Glen B. Alleman in his blog for the impulse and discussion.
A project “is a temporary endeavor, having a defined beginning and end.”
In SW development the development work, the actual knowledge creation, design decisions, stories, whatever, is best to do in flow, small batches. The work is complex in nature and benefits from really tight feedback and conversation, including the end user. Does not sound a typical project.
However, a release in most cases fits a definition of a project. Especially when we draw the system envelope so that it includes the paying customer. The new SW to be taken into use is causing a one-time change in the socio-techno-economical system of the customer and end user. It will be considered carefully before the investment decision. In some cases this can be a sequence of improvements, a flow. In most cases, I argue, it is a big change, definitely a project. (In this perspective every project is an organizational change project.)
Now, what is so bad about the concept of a SW development project? It comes from the experience of doing it in a stupid way:
– command and control projects, bad interaction, “resource management” approach
– focusing to a one time solution in a messy org, ignoring long term learning and portfolio management
– wishful up-front planning, ignoring the complex nature of SW development
Agile, look at the values, is a counter-argument against this stupidity. I think the question how much value PMI and other institutions add, is how the learn and cope these experiences.
In other words, a “traditional” project is a bad metaphor and practice for creating software. A project done wisely is often a good way to manage customer requests and releases.
I hope to blog soon why we have messed up with projects in the course of organizational evolution. People always make wise decisions in their local context.
Then the worry of the people and the organization; What to do with the project managers. Scrum does not mention a project manager. Clearly, based on the above, the product owner does that work. But the work of the PO is increasing, a natural place for the ex project managers’ contribution. They might be called customer project managers.
I often hear a suggestion that the project managers would become Scrum Masters. Dangerous generalization. In most cases I have seen, the project managers move naturally to some kind of a product owner role. Some human oriented PMs become good Scrum Masters. Then also the organization needs to relearn the role of these persons.
What is clearly disappearing in both cases is the resource coordinator/management role. So the ex project managers will be working more with the product substance. One overspecialized role less, provided that the whole organization is improving.