There is a lively discussion going on about project management in software development. In this Agile age, is project management still relevant? Scrum (I will base my comments on Scrum) and other agile development methods do not have a project manager role. So what happens to all those project managers out there?
They split up. The role formerly known as Project Manager is split into a Product Owner and a Scrum Manager. Changing a title is easy, changing the ingrained way we work is anything but. It is by far the most challenging aspect when changing over to an Agile development method.
The traditional way of developing software (Waterfall) is based on the idea that you design and map out everything you are going to build before you begin. So a project manager can map out the development schedule, build a Gantt chart and tell the stakeholders with confidence that the software solution will be delivered on such and such a date, costs this amount of money and requires that number of hours of work. The Project Manager controls what happens and when.
Agile methods (Scrum in this case) starts with an overall idea of what needs to be built and uses self-organising teams to develop the overall product in short cycles (Sprints) that create small functional blocks that can be used immediately. The Product Owner keeps an overview of the functionality and the Scrum Master keeps the development team working smoothly.
So what are the similarities?
The common denominator of both methods is of course the goal. The aim is to develop a good software solution and do it in the most efficient way possible.
Both methods start out with a vision of what is needed. Terms like a Project Initiation Document and Project Plan (traditional) and Vision document (Scrum) contain roughly the same information. The only thing that differs is the level of detail.
Both methods are cyclical, especially when you are using Prince2 as a project management method. In Prince2 it is called a Stage and in Scrum it is called a Sprint.
In some ways, the methods also show a great deal of similarities. For instance, each Stage ends with a Lessons Learned Log and a Quality log. Every Sprint ends with a Retrospective meeting to record lessons learned and how to improve.
The main reason more and more organisations are moving towards an Agile development method can be found in the differences. Within Scrum, there is a general overall plan, not the detailed and fairly fixed master plan of Prince2. With Scrum, the product grows “organically” instead of the predetermined outcome that has been locked in by the Project Plan. This increases the flexibility of the Scrum method. Often during development the functionality and requirements change, sometimes by quite a large shift. This is caused by the deeper understanding and insight the stakeholders acquire using the first functionality of the product. As an added benefit, the customers have a much higher commitment and trust in the system.
The biggest change and therefore the change that gives the most trouble, is the change in management. By definition, a Scrum team is self-organising and flexible. There is no project manager who is the “boss” over the team. The team, together with the Product Owner, agree at the start of every Sprint, which functionality will be built. The main determining factor here is this; how much value will this function add to the business? No management decisions, no outside control but simply, what will add value? This is why, with Scrum, you get an application that adds value almost straight from the start. With Waterfall you get a complete working application delivered at the end of the project. Not very flexible. This is the difference that makes the difference.
So how is project management implemented? Because after all, it is a project and it does need to be managed. The role of project manager is split down the middle. The Project side is handled by the Product Owner, while the Manager side is done by the Scrum Master. The Product Owner is the person that talks to the stakeholders (Customers, Line management, etc) and monitors the functionality. The PO represents the customer in the Scrum meetings. The Scrum Master is the people manager, manages the team, the procedures around the Sprint and controls the build speed and results. Software development is more and more becoming a team sport.
So, what is the conclusion, is a Project Manager for software development a thing of the past? Yes, the Project Manager is no more, but project management is very much alive. It has become much more flexible, much more customer facing and indeed, a lot more fun to do. The more senior Project Managers, especially if they are flexible enough, will become Product Owners or Program Managers (managing several Scrum streams and PO’s) while others will feel more at ease managing the development teams as a Scrum Master. The flexibility and self-empowerment within the Agile development method simply means that there is a bright future ahead for our current Project Manager.
Using the internet these days is very revealing. It is clear that almost all of the information you place on the internet can and will be analysed, and, by just being on the internet, you generate a lot more information about yourself, often totally unwittingly.
This project aims to stop all that. The goal is to develop an application that will protect your data and your privacy, and will keep you safe from hacking and spying. It is a solution that uses encryption and some clever processes. It is designed from the ground up to protect the privacy of your communications. The project started last year with the initial development and testing of the concepts. We are now ready for a larger organisation.
This organisation is now set up across the world and it is truly amazing how quickly this became a working, cohesive and enthusiastic group of people working towards a common goal. Despite all of this, it remains a challenge to manage such a group of people remotely and make sure all are on track. Weekly meetings are not enough; there are a lot of informal conversations going on, especially in the beginning, to make sure everybody “gets” it and knows the overall direction needed. Once that was defined, all we needed to do was adjust for the local conditions and markets. Who knew that kids in the Netherlands do not care about their on-line privacy while kids in France do?
The cross cultural aspects of the wide organisation also are interesting. Some of the language used is wildly over the top for my Dutch plain speaking habits. For me this is one of the enjoyable aspects of this project. Working together with people across the world gives you a much more varied and shaded look on the world, the people and the different ways of life.
I really like this project.
This project was all about contradictions. It had to be accessible by all, but had to be totally secure. We had to track every single vote but the anonymity of the voter had to be absolute. It had to be very easy to use, but the technology we were using was complex and new.
But we managed all that and more. When we started the government themselves stated that it probably was impossible to do, certainly not done in a way that was easy to use and understand.
Despite these reservations, we managed to do the project on time and within budget. Not only that but we were never hacked, security was good enough (nobody could cast a fake vote) and the pilot project delivered results.
I was the team leader in developing the technology, creating the methods we were using, both for the website as for the security of the vote. We used biometrics (fingerprint readers) for identification and a PKI set for security. On top of that we also encrypted the vote itself.
The only real security hole we found during the project was the human aspect. We had 1 laptop that could access the system to create a voting form. So this laptop had to be secured. The subcontractors left it on the table in an unlocked office room and sure enough, the laptop was stolen. It gets worse, they didn’t tell us about it. Not so surprising, these guys claimed to be Internet Content Specialist, the best in the country. They managed to mess up the first page (a static web page explaining the project), by making all the important words blue and underlined. Not links, just blue and underlined.
I often said, I learned a lot of stuff I did not want to learn. But then learning is good no matter what.
All in all, I certainly regard it as one of my better projects and one that I am quite proud of.
We had a very litigious customer who had an application that ran his complete business process. All of it was built by a third party and it was not to his satisfaction.
So he sued them and gave the project to us.
The aim of this project was to restructure the application is such a way that using a few simple parameters it could we configured to work for a completely different market area. I know, it is all a bit vague but legal issues require me to be slightly reticent here.
There were two main challenges in this project.
1. Managing the customer, especially function creep was a big problem.
2. Complexity of the software, with hidden functions and everything.
We managed to do it, and do it within the time frame we had available. Regardless of the outcome, we already knew the customer would sue us as well, just to try and pull the same trick again. He tried and failed, got thrown out of court.
Overall, it has been a great help in a lot of projects. The idea is simple and using the image makes it instantly clear to all parties involved how it works.
It has been extended to a larger overall structure, but I am not happy with it. It feels convoluted. So I have stopped developing it further for now, but continue to think about it. I can’t help myself.
I have often thought about the requirements gathering process and the rule that you should never have pre-conceived ideas about the possible solution.
First gather all the requirements and then this will resolve into a solution.
This places most of the burden on finding all the requirements. If you fail to find 1 or 2 key requirements, you might not have an optimal solution.
I think that doing it a different way, might be more effective. It is a method that I was taught at IBM in a consultancy class for a different way of consultancy. It is for a different discipline, but it works for requirements too. The methodology was: Form a hypothesis, define the real check questions to check the value of the hypothesis and adjust if needed.
For finding requirements it would work just as well. I called it the Hippo method.
Get the first requirements defined. This automatically gives you an idea on how the solution will run. (Don’t deny it, you do it automatically, you can’t stop it). Define this solution far enough so you can start defining the proper questions to ask to check the validity of what you think. These questions will generate a better insight and might even generate better insight in the customer too. Then check your hypothesis, modify it to suit the new data and write some more check questions, refining as you go.
The big issue here is that you must be willing and able to drop a hypothesis if the answers point you into another direction. After you have invested quite some time in the hypothesis, you might not want to drop it. You might try and fit the facts into your preconceived plan. If you can avoid that temptation, this method might be for you. Also, you need to make sure you drill deep enough, don’t skimp on the check questions.
I found that I subconsciously worked this way and found that I had a great deal of trouble dropping a well developed hypothesis when the last few questions resulted in the 1 or 2 key requirements mentioned before and they negated my hypothesis. It was then that I truly understood how my mind worked in this aspect and embraced the change. It was a nice moment. So now I consciously use this method and it has often worked in my benefit.