Monday, August 29, 2016

Think smaller

Over at my other blog, I mentioned the fact that the Danish Tax Department is going to go through a major overhaul (Denmark overhauls its tax department).

One of the major triggers for this overhaul, is the problems that the Tax Department have had with creating new IT systems in recent years. Two major IT systems have failed - one which was going to calculate the taxation value of property, and another which was going to be used to collect overdue taxes and other debt to the state.

The failure of these IT projects have cost billions of dollars in both wasted development costs and in lost revenue to the state of Denmark.

As a frontrunner to the overhaul of the Tax Department, the Ministry of Taxation had already decided to not let the Tax Department do the development of the property system but instead do it themselves. This was a major break away from the traditional roles of the Ministry and the Department, where the Ministry was focused on law-making, while the Department had the responsibility of enforcing the laws (e.g. collect the taxes), and make the systems necessary to do so.

As part of the Ministry of Taxation's decision of taking the responsibility of developing the property evaluation system, they also decided to do it in-house, rather than using public tenders to get it developed.

I was recently at a talk given by Steen Larsen, the head of development at the Ministry of Taxation, called "A New Way of Doing Public IT", where he explained the things they had done to create a succesful project, which would deliver a working system on time.

This was very interesting, though I think the title was overselling it a bit, as there are several public agencies and departments which do much of the same as what he described.

Listening to the talk, and seeing the ideas behind the overhaul of the department, I can't help worry if they have identified the right problem.

It seems to me that they still have a tendency to think in large monolitic systems.

As Steen Larsen described it, the IT system they were building was both a system for evaluating the properties, and for the case workers to do their work.

It seems to me, that it should be possible to split these areas of concern up, so they could be considered two different systems, and making the sizes somewhat more manageable. Generally, this allows for a greater chance of success.

Hopefully, the tendency of thinking in monolitic systems is only when they describe the systems, and not when they do the actual development.

Project managers vs Product owners

I frequently come across discussions on the internet about using project managers as product owners in Agile projects.

These discussions often spring out of discussions on what the role of a traditional project manager is in an Agile project, and since project managers often prioritize work in traditional projects, it makes sense to think of using them as product owners, who, after all, should prioritize the work that the developers do.

I disagree.

When Scrum was created, and the roles of Scrum Master and Product Owner came into existence, the people who got those roles, were the traditional project managers - at least according to what Jeff Sutherland said when I got my Scrum Master certification at his course.

That probably made sense back then, but I think it is a bad idea to do so now, for several reasons.

First, and foremost, I think it is a bad idea, because you need the project manager to focus on the project and its priorities. Unless you run an extremely agile project, there is still a need for a project manager taking care of the non-development aspects of the project (e.g. resource planning, dependency management with other projects, and other tasks ignored by Scrum and other Agile methods). In other words, project managers need to focus on the restraints and barriers of the project, and ensure that these doesn't affect the project and its progress.

Product owners, on the other hand, should represent the business/customers, ensuring that they get the most value out of the project as they can, within the boundaries set by the project manager.

Secondly, I think the skillset required to be a good project manager is orthogonal to the skillset required to be a good product owner, and it is best to use people in the role they fits the best.

A good project manager is good at forecasting and evaluating risks for the projects, ensuring that the people inside the project can perform optimally. A good product owner, on the other hand, understands the needs of the business/customers, and can translate this in a way that the developer team (including testers) can understand. This is why good product owners often are business analysts with a developer or tester background.

Thirdly, in most projects, being a product owner is a full time job. The number of developers in a project generally outnumbers the product owner by a fair margin, and having the product owner do project management as well, will slow the project down - or at least limit the number of developers that can be in the project.

All of the above is based on the premise that projects still need project managers, even if the development process (e.g. Scrum) doesn't call for it. If that's not the case, then the only relevant objection is my second point, about the necessary skillset being quite different. But this is a major point! In my experience, the role of the product owner is essential for the success of an agile project, and all too often, the selection of the product owner is taken too lightly.

If you want to find a good place for your project manager, look at the Scrum Master role, which has many similarities, focusing on sheltering the developers and create the framework for the development process.