Projects and project managers in Agile SW development

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.


2 Comments on “Projects and project managers in Agile SW development”

  1. Vasco Duarte says:

    There’s a good point in this post about “traditional” projects versus the new way (agile, I presume) of doing projects. But can you expand more on that point? Why do you think “traditional” projects are bad for software specifically? Just because they are done wrongly? Because there’s something inherently wrong in that approach?


  2. Ari Tikka says:

    Thanks Vasco for the encouragement… There is a reason why I did not try to open that point in the blog. I mentioned a few in the list regarding bad experiences, but for a compehensive treatment I would need to repeat a lot og Agile litterature 😦

    The ground reason is in the world view – values, assumptions and mental models. What is controllable, how do complex processes behave, what is really the value of knowledge and how you develop that, how do you make decisions, what is the purpose of a company, a huge list. With certain basic assumptions and some superficiality you end up doing what I called “traditional” projects.

    In some following blogs I will try to open up more carefully some points that I have not seen elsewhere. Soon.