For a start I would like to say something about projects and software development. The first thought is that software projects usually are no projects at all. A project should have a clear start and end. But software projects tend to continue until they are out of production. Which could mean 1 year of development and 10 years of maintenance. So if you really want to do a software project, you should also think about maintenance.
Economic Pressures and Development Strategies
Well we do not need crystal balls anymore to tell what has happened in the past. For something like three years now we have faced that customer wants tightly framed budgets. The reason behind it is that it gives us a feeling of control. Maybe we can even think that it is easier not to fail when there are budgets for money and time.
People usually think that agile methodologies and budgets do not belong to the same sentence. However, budgets are no problem when doing stuff with agile methodologies. I would even say that they are essential. In agile methodologies you start with the most important stuff and when there is no more money or time you stop. That sounds simple. However in most cases you have some quality requirements which have to be dealt with. And then it feels more safe to use strict project management as those requirements are probably built into the contract.
So what is wrong with strict project management? Maybe nothing. But usually in software development there will be some surprises. You can probably try to deal with them beforehand, but usually things go wrong in some way and you react fast when that happens. In agile it is built-in that you make changes to your work plan all the time. Every developer has been in a situation where difficult work becomes easy or vice versa. It is not a problem if work becomes easier because then you have time to make your product better in some other ways. For example you can make your tests better, upgrade integration pipelines and so on. Stuff that you don’t normally have time. But if the thing is another way around, then it means that you probably have to give up something. Maybe it means that you do not create some feature or you will create it later. What if you do not have money or time later? With agile methodologies you should be in a situation where everything important has been done when the budget ends. Then it does not matter if you do not have money or time for some of your features.
Customer is responsible for quality
When doing agile development it requires a lot of work from the customer as well. There should be a Product owner who loves the product which is in development. Product owner is responsible for creating tasks for developers. Of course developers and agile coaches can help with this. Most of the software projects fail because of lack of requirement specification. This means that tasks should be specified well enough that developers understand what they should do and also what should be prioritized.
In strict project management the starting point is to create a project plan from start to finish with detail. This sounds reasonable. However, in software projects it can be challenging. When the project plan is ready, the mindset is that all parties also expect that the project will follow the plan exactly. Even if the project manager would be very skillful she cannot notice every detail. And even if team members would read the plan carefully, in practice there will be surprises. Because of this choosing between project management and agile development has to be assessed carefully. I want to say it here again. There will be surprises. If your time and money budgets and scope are fixed, that means the only flexible thing is quality.
Lessons from Failed Agile Projects
I have to be truthful here. If there is lack of guidance from the customer then there is a huge risk that the agile development team does nothing valuable. Agile development is very hard. Consultants are there to help customers achieve things that the customer wants to achieve. If there is no product owner who is actively joining to product development how can consults know that they are doing the right things? I am sure that almost every agile development team wants to do the best job possible. The only problem is that if developers do not know what they should do, then they do nothing or concentrate on the wrong things. They are not going to ask what they should do. The only solution is that there is an agile coach or scrum master who helps the team to achieve customer goals. My honest opinion is that generally consultants should do better, even without an agile coach. Consultants should be professional in their field. If we are doing agile, then we should know how to do agile.
When is time for project management
Project management in software development is needed in some cases. Those situations are places where we have to plan our whole lifecycle for our software. Really good examples would be software in space, and also probably in defence industries. There you have to use time to think through how you are going to build your software and you know when you are not going to develop it anymore.
However, like I said before, agile development is hard and it needs commitment from the team and the customer. If a team is not committed to do agile then it is probably better to do things with project management frameworks. After this probably the quality of the product will decline.
As a customer how do you know that team is committed to doing agile? That is a very good question. I think this goes back to the fact that you should try to understand what the team is really doing. Like I earlier stated, the customer is responsible for quality, in the end the customer is also responsible for how the product is developed.
Best Practices for Agile Integration
When we are talking about creating software my suggestion is to use agile methodologies. They work in the best way when you are working on something new, like almost every software project is. And actually the best thing is that agile development is not planned for projects, it is planned for processes. And usually when the software is “done” there is still a lot of work. Probably your software is dependent on other software and those dependencies should be upgraded on a regular basis. Also nowadays you have some CI tools and pipelines and you should keep those up to date as well. In some point somewhere happens to be breaking change. Then you have to recreate some parts of your software. In software development, the project usually is never over.
.png)
Niko Vuorinen,
Agile Coach
