Mendix and beyond

There is exactly one universal rule about all development environments, that they are all different.

In my previous incarnations I worked in a medium sized development group split into smaller teams per project, often consisiting of one developer and one analyst/tester. Working as the development management team, we investigated what methodologies we could use within the environment. After examinations of project management, agile methodologies, various other literature and the preferred management, team personalities and development styles, we ended on a project orientated, agile method. This was obviously not a formal style and will start many hearts palpatating with the risks and inconsistencies this fr-agile approach takes, but lets not go into the details of this now.

This approach worked with its own hiccups, projects were delivered and of course there was always debate on improving delivery, issues. But what this did lead me to was the world of PMI project management.

From that starting point I then got to experience some more tantalizing environments ranging from very formal waterfall to very formal scrum environments to single man teams and throw numbers at the problem development environments. And slowly my framework, as everyones does, grew.

Now where is this all going? Well, debate within an environment is always good particularly when people are open to it. One thing I have always found when discussing development methodologies though is much fear and loathing of project plans, the dreaded GANTT chart and in turn project management. Furthermore for development teams it brings back often scarring memories of waterfall.

Personally I believe the first plan of any project should be burnt just after it has been saved and only looked at when reminiscing about the past. Although not important to the actual workers involved in a project, it is a valuable tool in visualising the work which is to be performed across a company not just a single development team and in communication with the management and greater business unit.

Now this is where the biggest dangers come in, in many cases an initial single project plan is presented to management and presented as a series of static milestones, often as a static pdf. Which is ofcourse how the management interprets it and this then gets filtered through the entire company and down to the development and other teams to implement with disregard to changes. Now this is where real project management is meant to step in. A project plan, schedule or GANTT chart should be an evolving document as scope, time, cost and risks change, and should never be provided without the details of the variance which can be expected. But importantly it is the project managers responsibility to ensure the management team understands the pan and variances.

Now in the scrum environment it is very important to know where the responsiblities of the project manager fit in with the product owner, scrum master and development team. In many environments the project manager often becomes the scrum master, however, this causes a major conflict of interest as the project manager is on the line to deliver the project and can start manipulating the team based on pressure of the project to deliver rather than faciliate delivery. The project manager as a product owner doesn’t work  as the project manager cares only for the product in the terms of the project. As such any other projects or company requirements will be removed for the sake of the project. This is often no problem in a new product or single project product, but where the product services a larger company audience this will cause conflicts of interest.

This then leads many down the lines of saying a project manager doesn’t belong at all. However, these projects are not oten limited to a single product development but include multiple team coordination, budgetting, preparing a physical operations environment (call centres, marketting, retailing) as well as other legal and reporting requirements. These responsiblities are very different to the product owner as they are of limited time and scope.

With the above concerns I would say that a project manager still belongs in the environment, working very closely with the product manager and only interacting with the development team with the product managers involvement. This allows the product manager to maintain their product and team while the project manager can do their job on the project. Of course this all relies on the close relationship of these two people.

And with that here are some interesting articles for food for thought:

http://www.goodproductmanager.com/2007/09/24/product-management-vs-project-management/