Last week, a friend who owns a software company called me: “After working for a software company for six years, I started my own company. I hired top graduated students and paid them well, I had several customers and my company grew fast. However, currently we are having problems with high defects and schedule slippages. If these problems continue, my company will be in trouble. As the owner, I usually spent most of my time with customers to bring in new business so how could I fix these problems and continue to grow my company?
I told him: “You can not ignore problems by spending time with customers and let people work without any supervising. Defect correction requires most of developers’ time and it is probably the main reason for schedule slippage. The urgent thing to do now is focusing on finding and fixing defects. I think you need to conduct more reviews to identify defects and correct them as soon as possible. In these reviews, you must have all developers and testers come and learn how defects were made and how to fix them.
He asked: “Why everybody? I can not have people who do not work in the same project to attend the reviews. It is a waste of time”.
I explained: “Typically, developers in project always have reviews among themselves to find and fix defects. These defects are “unknown” to other developers who did not attend reviews and they could make the same mistakes again. The reason for “exclusive reviews” is developers do not want others to find out about their mistakes. However, as the company owner, you should consider reviews as learning process so every defect found is a learning opportunity. The more developers know about the cause of defects, the easier it is to avoid making them.
He seemed satisfy: “OK, I could start with reviews and have all developers to come and learn. What else could I do?
I continued: “Typical software project starts with few people then as it progresses, you add more people to it. Most project management courses always teach this gradual approach and it works well with construction business. You only need few architects in the beginning but when architect and design phases are done, company brings in more workers to do construction. However, with software project this approach does not work well. It would be better if you could start with a full staff in the beginning.
He was surprised: “Why do we need more people in the early phases? That will cost more money”.
I explained: “That is why many software projects are having problems. You start with only few people to work with customers’ requirements and they understand what to do. Then they begin to architect and design the system. Because they work on the project from the beginning, they get along well. When you add more people to the project later, new people do not have time to know each others or form an effective teamwork. Personal conflicts may happen during this time. New people do not have time to understand requirements but they have to design and write code immediately.
They may not know how to integrate their works with the system architect. They may not understand the functional detailed of the system but they have to get their works done within limited schedules. This is where many mistakes are made. The new people are expected to figure out everything on their own in a very short time. Of course, they have questions and they have to ask others who are there in the beginning to help. This may disrupt project works because the time to teach new people about the project always take longer than expected, so the project may be late. Due to schedule pressure, people must hurry to get their works done and more defects are made.
He nodded: “I never think of that, you may be right. There are problems between new people and old people, they argued all the time” What else do I need to do?.
I told him: “The traditional software life cycle is a serial approach similar to the assembly line in industry. First, requirements engineer works with customers to document all requirements. The system architect would figure out how the system works based on these requirements. Then developers would designs and then write code. Next, testers would test them. After all tests are completed, the software product is released to customers. Let’s look at this approach. The requirements engineer only concerns about what customer needs and focuses on document them. The architect based everything on the requirements document and designs the system. The developers focus mostly on writing code based on the design. Testers do not care how the whole system is designed but only on their test cases whether the code passes tests or not. What would happen when the requirements are wrong? What would happen if the design is missing some functions? What would happen when testers checked in code that is not documented in the requirements document? What would happen if there are new functions added at the last minute. If the testers do not know about the new functionality, they can’t test it. That is the reason this assembly line approach really does not work well with software. The waterfall life cycle is good for teaching, it is easy to understand but it does not work well in the industry.
My friend hesitated for awhile: “That is what we always do? What do you suggest that we do differently?”
I explained: “That is why software engineering training requires that company must define the development process that fully integrate all team members as early as possible. The defined process is not a serial activity but an incremental with all roles fully integrated. It is very important to start with a full staff or at least a majority of people in the beginning. The project manager must discussed each team member’s role, responsibilities and what each person needed to do to be successful. The teamwork training in the beginning will create a number of discussions, where team members can talk about what they need from each other. The team then present their needs, their views to the project manager. After the first few weeks on the project, the team can come up with a process that everyone know what their tasks are, and how to work them. This information should be documented as part of the project team process where everyone know what the project priorities are, and how to make decisions to satisfy the project needs.
My friend asked: “Why do you need few weeks to build team? Is it too much?
I answered: “Teamwork is the most important activity in software project. You can not expect that people who do not know each other will get along well in a few days. They need time to know each others and come up with a defined process that everyone would agree to follow. Instead of a serial process, you should ask the team to developed a concurrent process to build software. For example, the architect defines an overall architecture of the software product, specifying features for each release and conducts an initial review where every team members should attend. This is the time where everybody should really learn about the technical aspects and ask questions if needed. After the initial review, a group of developers will start the design immediately when another group is working on the system tests. After the design, the team must conduct a design review with the entire team and the test group must make sure that their system tests will work well with the design. If everything is fine, then the team can start the detailed design and implementation, at the same time the test group will work on the development of functional tests. Every phase must have review attend by the entire team to make sure they coordinate their activities and their works are fully integrated. By the time the code was written and tested (unit tested), everyone will be ready for code reviews. All code must go through reviews before being placed in configuration management system. After the code is checked in, testers will start testing and any defects identified must be fixed according to a change process. Basically, everything in the project must follow a well-defined concurrent process and project manager must use metrics to verify everything. Project schedules should be tracked against original estimates, all requirements must be managed, as well as any defects. By having everybody participate early and help define the process, team members understand their works and major milestones. They know what they need to do each week and verify their works with each others. In this collaborative efforts, team members could notice when a problem happens and take corrective action rather than wait until later phase. If the team is following a well defined process, they can improve the way they deal with defects and schedule slippages, and eventually all projects will be improved.
My friend said: “So you think teamwork and process are critical factors for project improvement?”
I told him: “Yes, definitely. Software process may sound simple but they represent a dramatic change in the way people do their works. With teamwork, people recognized that their work is a collaboration efforts where everything must be integrated. This is the key to the success of all development works, no one works alone. With software engineering disciplines, they will know what to do and what to do next. Having discipline is the first step to grow your company. In addition to these technical processes, you can improve your management processes too. Until there is a well-defined development process, it is difficult to know who are doing what or who are good and who are not. The well-defined process allows project managers to understand development works and role, responsibility of each team members. This give managers the opportunity to work with people whose works are not acceptable, and reward people who do outstanding work.
